IncludePackageReferencesDuringMarkupCompilation causes build errors with WPF projects

[las-nsc]

The reason for enabling this setting is to include code from a source generator (BoilerPlateZero), but that wasn't needed to cause the build to break.

Version Used:
.NET 5.0-windows with C#9 with VS2019 16.11.0 Enterprise

Steps to Reproduce:

1. Take a relatively complex solution using WPF which builds with no errors
2. Add in Directory.Build.props or *.csproj
   a. <AssemblyName>MyProductName.$(MSBuildProjectName)</AssemblyName>
   b. <IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
3. Build project

Expected Behavior:
Should build with no errors.

Actual Behavior:
Fails to builds with errors such as:

Severity	Code	Description
Error	CS0006	Metadata file '[ProjectDir]\bin\Debug\ref\[AssemblyName].dll' could not be found.
Error	CS0006	Metadata file '[ProjectDir]\bin\Debug\[AssemblyName].dll' could not be found.
Error	MC2000	Unknown build error, 'Could not find file '[ProjectDir]\obj\Debug\[AssemblyName].dll'.
Error	MC3050	Cannot find the type '[CustomClass]'. Note that type names are case sensitive.
Error	MC3074	The tag '[CustomClass]' does not exist in XML namespace 'clr-namespace:[Namespace]'.

NOTE: In all cases, the [ProjectDir]/[AssemblyName]is the same as the source of the error (I assume due to the iterative way WPF is built) and the [CustomClass]es which aren't found in the [Namespace]s are also within the same project.

This occurs in two separate solutions using $(MSBuildProjectName) in AssemblyName, and the only way I could get it to build was to override Directory.Build.props with an explicit AssemblyName tag in the *.csproj (not using $(MSBuildProjectName)).

I tried to make a sample solution without any private code, but for some reason it was lacking the complexity which causes it to fail, sorry.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[sharwell]

@dotnet/roslyn-compiler we weren't sure if this should be transferred to dotnet/sdk or dotnet/wpf; feel free to transfer if it's not a compiler problem.

[ryalanms]

@vishalmsft: There are changes in 6.0 that need to be backported to 5.0.

[vishalmsft]

@ryalanms please help with providing the reference to those PR, which fixed for .NET 6.
The issue seems to be reproducible in VS version higher than 16.11, as referenced in the issue #5711

[Nefarion]

I finally managed to find a relatively simple fix for this.
My projects all reference a "base" project with <Import Project="$(ProjectDir)..\<BaseProject>.csproj" /> that sets the AssemblyName based on $(MSBuildProjectName).

The problem is, that the WPF two stage compilation process adds <AssemblyName> overrides to the TOP of the csproj file, which gets overridden by the included BaseProject file, and since the MSBuildProjectName is a temporary project, the AssemblyName is wrong.

The simple fix, make the AssemblyName change conditional in the BaseProject file!

-<PropertyGroup>
+<PropertyGroup Condition="'$(_TargetAssemblyProjectName)' == ''">
  <AssemblyName>$(MSBuildProjectName)</AssemblyName>
</PropertyGroup>

Works like a charm for me!

[Kuldeep-MS]

@las-nsc - Whilst I examine this more closely, would you kindly review this PR that may have resolved this issue? The PR has already been merged and can be found in the latest code. Please test it out and inform us if it resolves the issue, so we can close it. If it does not resolve the issue, I will continue working on it.

[Kuldeep-MS]

@las-nsc - Can you verify whether this PR resolves the issue? If it does, we can close this issue.

[ghost]

This submission has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 14 days.

It will be closed if no further activity occurs within 7 days of this comment.