Setting BaseIntermediateOutputPath or IntermediateOutputPath MSBuild properties in WPF projects causes instrumentation to fail.

[hymccord]

I've debugged this quite a bit and the problem is simple. But I'm not sure if I need to take it up here or somewhere in the dotnet repos.

Minimal repro is simple.

1. New solution
2. New WPF (netcore) project
3. New Test project (added coverlet.msbuild too)
4. Create directory.build.props in the solution folder.

<Project>
  <PropertyGroup>
    <SolutionDir>$(MSBuildThisFileDirectory)</SolutionDir>
    <BaseIntermediateOutputPath>$(SolutionDir)bin\obj\$(Configuration)\$(MSBuildProjectName)\</BaseIntermediateOutputPath>
    <!-- or -->
    <!--<IntermediateOutputPath>$(SolutionDir)bin\obj\$(Configuration)\$(MSBuildProjectName)\</IntermediateOutputPath> -->
  </PropertyGroup>
</Project>

Commands and whether it instrumented correctly.
❌ > dotnet test /p:CollectCoverage=true
❌ > dotnet test --collect "XPlat Code Coverage" -> fails
✔️ > dotnet test --collect "Code Coverage" -> works

I built coverlet.msbuild and set my environment flag to let me debug.
The problem occurs in Instrumenter.cs:L151.
It fails when it tries to verify that App.xaml and MainWindow.xaml exist. (any .xaml file I think)
In builds where $([Base]IntermediateOutput) is not set, the PE metadata indicates the source document will be at:
....\<SolutionDir>\WpfApp1\App.xaml
In builds where it IS set, the metadata indicates (incorrectly) it will be here:
....\<SolutionDir>\bin\obj\Debug\WpfApp1\Debug\netcoreapp3.1\App.xaml

And it's not really y'alls fault, just trying to figure a solution for people who want to have a single bin and obj folder.

I have a plan to chase down the MSBuild side of this but maybe you'll have some insight since one of the collectors works and the other two do not. I only debugged the coverlet.msbuild portion.

[MarcoRossignoli]

In builds where it IS set, the metadata indicates (incorrectly) it will be here:

When you say metadata you mean data inside pdb?Or you mean this line

coverlet/src/coverlet.core/Helpers/InstrumentationHelper.cs

Line 167 in 59a3bdb

string docName = _sourceRootTranslator.ResolveFilePath(metadataReader.GetString(document.Name));

?

[hymccord]

I mean the data from the pdb. You get the document handle, then the doc, and then use the metadatareader to return the docs file path. The sourceroottranslator doesn’t contain any mapped paths so it doesn’t morph it. If I could exclude xaml files, then that would be a temporary workaround until the issue is really fixed by the msbuild team. I’ve seen other issues semi-related while researching.

…

Sent from my iPhone

On Oct 27, 2020, at 6:26 AM, Marco Rossignoli ***@***.***> wrote:  In builds where it IS set, the metadata indicates (incorrectly) it will be here: When you say metadata you mean data inside pdb?Or you mean this line https://github.com/coverlet-coverage/coverlet/blob/59a3bdbfc889cf969e0265c9dce37ecf095b143b/src/coverlet.core/Helpers/InstrumentationHelper.cs#L167? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[MarcoRossignoli]

fixed by the msbuild team

Can you link here external issues(msbuild team)?Usually if it's an external issue we link the issue and label as tracking-external-issue.

[hymccord]

Sorry, I should I clarified that I highly suspect it's msbuild system or roslyn compilation engine, but not 100% confirmed. I don't have an issue tracking it as of this moment.

I will find the correct repo to file an issue in.

Were you able to repro and see the document path metadata in the PDB?

[hymccord]

Here's a pic of the PDB metadata document table (program is dotPeek).

BaseIntermediateOutputPath not set.
So it defaults to $(RepoRoot)\$(MSBuildProjectName)\obj\$(Configuration)

BaseIntermediateOutputPath set.
Set to $(RepoRoot)\bin\obj\$(Configuration)\$(MSBuildProjectName)

[hymccord]

Okay, after digging into the Roslyn compiler and seeing the root issue was actually due to the pragma paths in the generated WPF .g.cs files; it seems like this has been filed in the appropriate places already.

See initial bug report: dotnet/wpf#1718
A fix was merged in here: dotnet/wpf#3120
But was reverted: dotnet/wpf#3637 😢
Comment here says it will be fixed in VS 16.9 Preview 2: dotnet/wpf#3637 (comment)
More conversation here: dotnet/wpf#3628

TLDR; This should be fixed in the .NET 5.0.2xx servicing release.

Workaround til then: don't use BaseIntermediateOutputPath.

[MarcoRossignoli]

Thanks a lot for the investigation!
I'm going to mark external issue.
Feel free to close when will be fixed on runtime.

[MarcoRossignoli]

Close as external issue.