Vstest: Code coverage requires DebugType full

[codito]

For projects using the roslyn based project system, coverage requires DebugType = Full as shown below:

  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework> 
    <DebugType>Full</DebugType>
  </PropertyGroup>

This issue tracks the requirement to support portable symbols in coverage infrastructure.

[smadala]

Making DebugType to Full for netcore breaks source navigation and context "Run Tests" option. related bug:https://github.com/Microsoft/vstest/issues/373

[cvs79]

When is this expected to be fixed out of the box. We cant advise clients to manually add Full to their projects to get this working. Also adding that setting shows a very strange code coverage list. See screenshots

[singhsarab]

There is a lot of feedback coming in around this.

[tmat]

Is this being worked on? What component needs to be updated to support Portable PDBs?

[smadala]

For timeline https://github.com/Microsoft/vstest/pull/1301#discussion_r151942331, Code coverage profiler need to support portable PDBs.

[Mohammed-Swillam]

is there any update regarding this issue?
or is it still the fix that we need to in order to enable code coverage reports on TFS?

[max-buecker]

I am also genuinely interested in the status of this issue. For my netcore2.0 projects, I've added the debugtype full setting without any side-effects as far as I am aware. Is this still the way to go? Will there be a solution in the future, where this won't be required anymore?

[smadala]

@max-buecker Sorry for delay in fixing this issue.

CodeCoverage profiler has dependency on msdia.dll library, Currently msdia won't support for portable PDB.

Luckily @VCZYK Implemented to support portable pdb with msdia. I have tested private bits on vstest repo, Code coverage works without any workaround. We are planning to ship it in VS 15.8.

[stephenegriffin]

The above workaround is correct for .net. For C++ and v141, full symbols is handled differently:
<GenerateDebugInformation>DebugFull</GenerateDebugInformation>
See https://developercommunity.visualstudio.com/content/problem/17575/c-unit-testing-code-coverage-not-working.html for further details. This is a regression from v140, where the following is sufficient:
<GenerateDebugInformation>true</GenerateDebugInformation>

[HenrikFrystykNielsen]

FWIW, it seems that using pdbonly also does the trick:

<DebugType>pdbonly</DebugType>

Hope this helps,

Henrik

[smadala]

Yesterday VS 15.8 preview 3 released. It has fix for this issue.

Please try it and let us know if you find any issue(Please create separate issue with details repro steps), we will try to fix it ASAP.

[clairernovotny]

@smadala does that support pdb type of embedded?

[clairernovotny]

I just tried with 15.8p3 and it doesn't return any data for emedded pdb's, so this issue cannot be resolved yet.

[smadala]

@onovotny No, embedded pdb not supported. Currently plan is support it in VS 16.

[clairernovotny]

Is there a global MSBuild Property set when using VS's "Analyze Code Coverage command"? At the very least, it would let us set a conditional property on that so we can use portable for those builds.

[smadala]

Is there a global MSBuild Property set when using VS's "Analyze Code Coverage command"?

@onovotny Sorry, No such property available.

[clairernovotny]

@smadala Can that be added for 15.8? It would seem to be useful to know if a build is happening in the context of prepping to run code coverage that way. One property that users can use, the system itself doesn't use it.

[smadala]

@onovotny AFAIK There is no infra/way to add the MSBuild property. Test explorer Analyze Code Coverage command comes into the picture only after build completed.

@ManishJayaswal @AbhitejJohn better persons to answer it?

[clairernovotny]

It does a compile/up-to-date check first though. I would imagine it could pass an MSBuild property, which would trigger a rebuild.

Alternatively, given that normal CI builds are done from msbuild or dotnet build, is there another property we can use to detect if we're inside of visual studio? (isn't there a "BuildingInVS" property already? forget the name).

Goal here is a workaround so that we can use the VS tooling while in VS and in CI the packages use the embedded pdbs.

[AbhitejJohn]

@onovotny : There is the DesignMode switch that the platform sets in the runsettings when running from IDE. Would that work?

[smadala]

Tracking embedded pdb https://github.com/Microsoft/vstest/issues/1748

[alastairtree]

From the looks of things this is not really closed, just bumped off to another issue, and still not fixed. Version 2.1 of .net core and would really expect dotnet test --collect:"Code Coverage" to just work out of the box. Please can we get some clear comms on how/when code coverage will work?

[smadala]

Install dotnet core sdk >= 2.1.400 from here and update Microsoft.NET.Test.Sdk to 15.8.0.

Example: https://github.com/pvlakshm/Samples/tree/master/NetCoreSampleForCC