Upgrade from MSTest from 3.7.3> has 'Code Coverage' issues

With MSTest package versions above 3.7.3 (Current version is 3.10.0), I’m unable to collect code coverage data using dotnet test in Azure DevOps pipelines with a Windows container image.

I receive the following message from the Dotnet test task: "Data collector 'Code Coverage' message: No code coverage data available. Profiler was not initialized."

I also tried using coverlet, but that didn’t work either and still shows 0% coverage.

Could you advise on a solution or suggest next steps?

Expected behavior

Code coverage tab should show the details as it was showing with MSTest 3.7.3

Actual behavior

Code coverage shows blank.

Additional context

Prashanth Narasimha Murthy (@prashanthnmurthy)

Thanks for reporting this Prashanth Narasimha Murthy (@prashanthnmurthy)
I'm moving to microsoft/codecoverage for further investigation on CC side.

Prashanth Narasimha Murthy (@prashanthnmurthy)

Prashanth Narasimha Murthy (@prashanthnmurthy) I would suggest to run dotnet test locally and see if you observe the same results or not. Can you check that Microsoft.CodeCoverage is part of the test project?

fhnaseer

fhnaseer Yes, I had the Microsoft.CodeCoverage as part of the test project, I also verified again locally with the same error.

Commands I used:
dotnet test dirs.proj --no-restore --no-build

Where do you specify collect code coverage? Any runsettings?

Also, can you please try dotnet test --no-build --collect "Code Coverage" --diag log.dotnet.txt? And share these logs?

We use a runsettings file. Below is the run settings file.

CodeCoverage.zip

I executed the command above, and the log files can be found here.

log.dotnet.zip

I also added another assembly, Microsoft.Testing.Extensions.CodeCoverage, Microsoft.Testing.Extensions.TrxReport but it isn't functioning as expected.

The packages Microsoft.Testing.Extensions.CodeCoverage and Microsoft.Testing.Extensions.TrxReport are only relevant for Microsoft.Testing.Platform. It seems that you are using VSTest and didn't migrate to Microsoft.Testing.Platform, so it's expected that Microsoft.Testing.Extensions.CodeCoverage, Microsoft.Testing.Extensions.TrxReport don't work.

Youssef Fahmy (@Youssef1313)

Youssef Fahmy (@Youssef1313) Is it necessary to migrate to Microsoft.Testing.Platform, or are there alternative ways to obtain code coverage with MSTest/VSTest?

While the migration is generally recommended, it should still be possible to obtain code coverage using MSTest with VSTest.

I see that you have 4 test projects, however no tests were executed for 3 projects.

Code coverage collector will give this warning when no clients are connected, and hence it will generate an empty report => "No code coverage data available. Profiler was not initialized"

2 tests were executed, and a coverage report is generated at the end. Can you please check if the coverage report contains the right data? Or is it empty?

Youssef Fahmy (@Youssef1313)

Youssef Fahmy (@Youssef1313) We tried running the following workflows

MSTest Version 3.10.0
1.2. dotnet test => coverage is not generated
1.2. vstest.console.exe (17.14) => coverage is generated correctly
MSTest Version 3.7.3
2.1. dotnet test => coverage is generated correctly
2.2. vstest.console.exe (17.14) => coverage is generated correctly

Both versions of MSTest uses the same MS.CC 17.14.1 reference. I believe that there are some changes on MSTest side that does not work with dotnet test. Running the same project with vstest.console.exe generated correct coverage report.

I cannot imagine how MSTest itself can have an impact on this and why dotnet test is different from vstest.console.exe.

Is there anything specific you can point out to? VSTest simply just calls MSTest to run tests via ITestExecutor. I don't see any interactions with CC 😕

Is there a different behavior with regards to running the tests with the MSTest upgrade?

Jakub Jareš (@nohwnd)

I cannot imagine how MSTest itself can have an impact on this and why dotnet test is different from vstest.console.exe.

Is there anything specific you can point out to? VSTest simply just calls MSTest to run tests via ITestExecutor. I don't see any interactions with CC 😕

Is there a different behavior with regards to running the tests with the MSTest upgrade?

Maybe Jakub Jareš (@nohwnd) can help in figuring this out.

<!-- file mstest268.csproj -->
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <LangVersion>latest</LangVersion>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="MSTest.TestAdapter" Version="3.10.0" />
    <PackageReference Include="MSTest.TestFramework" Version="3.10.0" />
    <PackageReference Include="Microsoft.CodeCoverage" Version="17.14.1" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.14.1" />
  </ItemGroup>

  <ItemGroup>
    <Using Include="Microsoft.VisualStudio.TestTools.UnitTesting" />
  </ItemGroup>

</Project>

# file mstest268.sln
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.5.2.0
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "mstest268", "mstest268.csproj", "{F07FD354-CE88-7D9F-CDCC-D9950624BB7C}"
EndProject
Global
	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|Any CPU = Debug|Any CPU
		Release|Any CPU = Release|Any CPU
	EndGlobalSection
	GlobalSection(ProjectConfigurationPlatforms) = postSolution
		{F07FD354-CE88-7D9F-CDCC-D9950624BB7C}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
		{F07FD354-CE88-7D9F-CDCC-D9950624BB7C}.Debug|Any CPU.Build.0 = Debug|Any CPU
		{F07FD354-CE88-7D9F-CDCC-D9950624BB7C}.Release|Any CPU.ActiveCfg = Release|Any CPU
		{F07FD354-CE88-7D9F-CDCC-D9950624BB7C}.Release|Any CPU.Build.0 = Release|Any CPU
	EndGlobalSection
	GlobalSection(SolutionProperties) = preSolution
		HideSolutionNode = FALSE
	EndGlobalSection
	GlobalSection(ExtensibilityGlobals) = postSolution
		SolutionGuid = {0569BCE6-BA2A-4CFE-B38A-E2F1A90BDDFA}
	EndGlobalSection
EndGlobal

// file MSTestSettings.cs
[assembly: Parallelize(Scope = ExecutionScope.MethodLevel)]

// file Test1.cs
namespace mstest268;

[TestClass]
public sealed class Test1
{
    [TestMethod]
    public void TestMethod1()
    {
    }
}

This works for me:

dotnet build
dotnet test --no-build --collect "Code Coverage" 

Test Parallelization enabled for S:\t\mstest268\bin\Debug\net10.0\mstest268.dll (Workers: 12, Scope: MethodLevel)
  mstest268 test succeeded (1.5s)

Test summary: total: 1, failed: 0, succeeded: 1, skipped: 0, duration: 1.5s
Build succeeded in 1.9s

Attachments:
  S:\t\mstest268\TestResults\0064bb74-f901-4ef7-8530-610235fb0207\jajares_RDESKTOP_2025-08-07.13_12_28.coverage

Prashanth Narasimha Murthy (@prashanthnmurthy)

Prashanth Narasimha Murthy (@prashanthnmurthy) will need a repro for this one. Reach out to me on internal teams if you cannot share more stuff publicly.

Jakub Jareš (@nohwnd)

Jakub Jareš (@nohwnd) The solution is not working for me, and as you have suggested I need to discuss with my FTE to provide the source project access and package sources access.

Workaround: User is using dotnet test and vstest. In this case Microsoft.Testing.Extensions.CodeCoverage libs are not required in the test bin folder. These can be adding the following reference in the test project.

<PackageReference Include="Microsoft.Testing.Extensions.CodeCoverage" Version="17.14.2" ExcludeAssets="all" />

Jakub Jareš (@nohwnd)

Jakub Jareš (@nohwnd) Youssef Fahmy (@Youssef1313) The issue happens when using dotnet test and test bin folder has a file with *Collector.dll in it. vstest considers this folder for loading data collectors because of *Collector.dll in it. datacollector loads Microsoft.CodeCoverage.Core.dll from the bin folder instead of the original location (Microsoft.CodeCoverage package?). Microsoft.CodeCoverage.Core.dll sets env var according to its location on the disk and this does not work as MTP.Extension.CC has a different folder structure than MS.CC.

I was working on the solution that Microsoft.CodeCoverage.Core.dll sets env var if it is in the bin folder. This has some issues.

MTP.Extension.CC doesnt ship all the files that are shipped with MS.CC. We can add these missing files in MTP.Extension.CC but it doesn't make sense as these are never used by MTP itself.

Microsoft.NET.Test.Sdk/Microsoft.TestPlatform/MS.CC are built using the same source code. While MTP.Extension.CC could target to a different source code which are not compatible with TestSDK/MS.CC. In that case, we need to create some compatibility matrix, and user has to ensure that correct versions are used.

I think the simplest solution is that datacollector loads code coverage libraries from MS.CC package and not test bin folder. This will ensure that dotnet test / vstest loads correct code coverage libraries with the right version. Thoughts?

MTP.Extension.CC doesnt ship all the files that are shipped with MS.CC.

What necessary files are missing?

CodeCoverage.exe, Microsoft.DisSymReader.dll.

There is another scenario. Test project is using MSTest 3.7.3 (no MTP.CC stuff in the test bin folder). But has a reference of Microsoft.CodeCoverage.Core package. And because of this now test bin folder has Microsoft.CodeCoverage.Core.dll and no other code coverage stuff. Datacollector will load it from the bin folder again. And we have no way of providing right env vars in this case.

(I got here by searching for No code coverage data available. Profiler was not initialized.)

I ran across this issue after consolidating some packages in a test project and found that switching to the meta package MSTest, i.e.

<PackageReference Include="MSTest" Version="x.y.z" />

caused code coverage under Azure DevOps to suddenly go missing.

After reading the comments I guessed that I needed to revert to specifying these two packages explicitly again:

<PackageReference Include="MSTest.TestAdapter" Version="x.y.z" />
<PackageReference Include="MSTest.TestFramework" Version="x.y.z" />

(I had already worked that out by reverting my changes one-by-one but I wanted to see if this was a known issue or a red herring.)

Navigation Menu

Repository navigation

Upgrade from MSTest from 3.7.3> has 'Code Coverage' issues #185

Expected behavior

Actual behavior

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Upgrade from MSTest from 3.7.3> has 'Code Coverage' issues #185

Description

Expected behavior

Actual behavior

Additional context

Activity

Youssef1313 commented on Aug 1, 2025

fhnaseer commented on Aug 1, 2025

prashanthnmurthy commented on Aug 1, 2025

fhnaseer commented on Aug 4, 2025

prashanthnmurthy commented on Aug 4, 2025

Youssef1313 commented on Aug 5, 2025

prashanthnmurthy commented on Aug 5, 2025

Youssef1313 commented on Aug 5, 2025

fhnaseer commented on Aug 5, 2025

fhnaseer commented on Aug 5, 2025

Youssef1313 commented on Aug 5, 2025

fhnaseer commented on Aug 5, 2025

nohwnd commented on Aug 7, 2025

nohwnd commented on Aug 7, 2025

prashanthnmurthy commented on Aug 7, 2025

fhnaseer commented on Aug 25, 2025

fhnaseer commented on Aug 25, 2025

Youssef1313 commented on Aug 25, 2025

fhnaseer commented on Aug 25, 2025

chrisoldwood commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions