vstest: Could not load type

Description

IMPORTANT: if the defect is reproduced only in a workflow from within the Visual Studio IDE then do not report the issue here - instead, please report it using Visual Studio’s “Send Feedback” option that can be accessed from the Help menu OR using this link https://developercommunity.visualstudio.com.

For a defect reproducable from the vstest command line, describe the issue you’ve observed.

Today, I updated to the latest stable version (16.7.0) and, after that it isn’t collecting code coverage anymore.

Steps to reproduce

What steps can reproduce the defect? Please share the setup, commandline for vstest.console, sample project, target framework etc.

run the command: dotnet test --collect:"Code Coverage" --results-directory:"TestResults" --configuration Release --no-build -- RunConfiguration.DisableAppDomain=true

Expected behavior

Share the expected output

Collect and don’t show any error

Actual behavior

What is the behavior observed?

The following error is showing: Data collector ‘Code Coverage’ message: Failed to initialize code coverage datacollector with error: System.TypeLoadException: Could not load type ‘Microsoft.VisualStudio.TestPlatform.Utilities.CodeCoverageRunSettingsProcessor’ from assembly ‘Microsoft.TestPlatform.Utilities, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’.

Diagnostic logs

Please share test platform diagnostics logs. Instructions to collect logs are here.
The logs may contain test assembly paths, kindly review and mask those before sharing.

Environment

Please share additional details about the test environment. Operating system, Build version of vstest.console

I’m running in GH Actions, windows-latest environment

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 3
Comments: 21 (11 by maintainers)

Most upvoted comments

@nohwnd @jakubch1 @eddynaka @muiriswoulfe @Mobrockers @Phlow2001 we have just released the latest version of TestPlatform, 16.8.0-preview-20200812-03, available on nuget.org.

This version contains a fix for this issue in the Microsoft.CodeCoverage NuGet, so provided you are able to use the latest set of NuGets you won’t have to deal with the .NET SDK version bump requirement from the quick workaround above, instead you’ll be able to use whatever .NET SDK version you were using until now.

cvpoienaru on Aug 13, 2020

Sorry for the inconvenience. @cvpoienaru is working on finding out what the issue is and seeing if there is any workaround.

nohwnd on Aug 7, 2020

It was @cvpoienaru who ported the changes and did all the work, I am just a messenger trying to let everyone know 🙂

nohwnd on Aug 20, 2020

@muiriswoulfe , the new version got available! https://devblogs.microsoft.com/dotnet/net-core-august-2020/

eddynaka on Aug 13, 2020

@nohwnd @jakubch1 @eddynaka @muiriswoulfe @Mobrockers @Phlow2001 I was able to successfully replicate this issue on my machine and now I’m working on a fix for it.

I created a MSTest Test Project (.NET Core) project and used the latest Microsoft.NET.Test.Sdk NuGet package that has a dependency on the latest Microsoft.CodeCoverage NuGet. The issue replicates after running dotnet test --collect:"Code Coverage" --results-directory:"TestResults" --configuration Release --no-build -- RunConfiguration.DisableAppDomain=true using .NET SDK 3.1.300 but not using .NET SDK 3.1.400.

As a quick workaround, should it be possible for you, I recommend updating the .NET SDK version to at least 3.1.400. Let me know if you still see the issue after this please.

The reason this issue pops up in the first place is due to some change we did for Code Coverage (link here) that was causing the testhost process to crash under certain circumstances. On the way of fixing the issue in Microsoft.VisualStudio.TraceDataCollector.dll (part of Microsoft.CodeCoverage) we took a dependency on some functionality residing in Microsoft.TestPlatform.Utilities.dll (in this case part of .NET SDK) and as a consequence this incompatibility arose.

cvpoienaru on Aug 10, 2020

Can confirm, we have the same issue. Pipeline here:

https://dev.azure.com/stryker-mutator/Stryker/_build/results?buildId=5131&view=logs&j=bf94e6da-eeef-50d1-100b-0ed7f4d964f2&t=6d3eec8c-0b41-5503-31a1-551142db5688&l=141

Started by this pull request where we update the following packages to 16.7.0

Microsoft.TestPlatform.ObjectModel
Microsoft.TestPlatform.TestHost
Microsoft.TestPlatform
Microsoft.TestPlatform.Portable
Microsoft.TestPlatform.TranslationLayer
Microsoft.NET.Test.Sdk
Microsoft.CodeCoverage

rouke-broersma on Aug 7, 2020

@cvpoienaru thank you! 👍

eddynaka on Aug 20, 2020

@nohwnd thank you! that version is working fine! already tested!

eddynaka on Aug 20, 2020

16.7.1 was released that addresses this. If you face this problem please update.

nohwnd on Aug 20, 2020

We’re on .NET Core 2.1

Phlow2001 on Aug 10, 2020

@cvpoienaru Thanks for the update.

Where is .NET SDK 3.1.400 available from? The latest release listed at https://dotnet.microsoft.com/download/dotnet-core/3.1 that I can see is 3.1.302. If it’s a pre-release version, we’re unfortunately not able to use that due to compliance reasons, although I expect we would not have to wait too long before an official release, in which case upgrading won’t be a problem.

We’re not under great pressure to get a fix here as we monitor code coverage through a variety of tools and so the data isn’t entirely lost to us. But we would like to get it back via the build task eventually so that we can more quickly assess our project’s code coverage status. Holding off until the official release of 3.1.400 is fine for us.

muiriswoulfe on Aug 10, 2020

@cvpoienaru we cannot upgrade the dotnet core version as we build an open source dotnet cli tool so we have no control of where the tool is executed and which dotnet versions are available. But we have no need to upgrade right now so it’s not a problem to wait on a fix.

rouke-broersma on Aug 10, 2020