wpf: Regression for custom AssemblyName in WPF apps

Can we expect a fix soon? This bug completely blocks development.

I have a potential fix that I’m experimenting with right now. It’s working but I have to do more tests to make sure that I’m not breaking anything. My other comment here gives a bit more explanation. Both issues are caused by the same bug.

Just to clarify - the fix for this has been merged for .NET9. Hence it will be available starting .NET9 Preview1.

@vishalmsft The issue is in src\Microsoft.DotNet.Wpf\src\PresentationBuildTasks\Microsoft\Build\Tasks\Windows\GenerateTemporaryTargetAssembly.cs

There are 2 methods which handle generating the project in this step, and which one is determined by IncludePackageReferencesDuringMarkupCompilation. Both are similar, but some build properties are set via MSBuild params and some are set by writing them to the temporary project file. Either way it doesn’t work properly, but using the workaround I mentioned before does fix the issue when IncludePackageReferencesDuringMarkupCompilation is false (the old mechanism).

Ultimately, the properties need to resolve to the same value for this temporary build as they do for the final build. In my example, that is because MSBuildProjectName is wrong because the Project name is derived from the file name, which has been changed by adding _random_wpftmp.

I believe I have found a workaround, which might reveal the answer to whomever fixes this.

By adding:

<AssemblyName Condition="$(_TargetAssemblyProjectName) != ''">$(Product).$(_TargetAssemblyProjectName)</AssemblyName>

It corrects the assembly name from being the Temporary one generated by the WPF compilation.

Note: this only works when IncludePackageReferencesDuringMarkupCompilation is false.

This sounds very similar to an issue (#5576) I’ve been having with both VS 2019 and VS 2022, it was only affecting .net 5 on 2019 before but it’s affecting .net 4x on 2022 now, and somehow having both installed as made the problem spread to 2019.

My setup is slightly different, I have a Directory.Build.props file which sets <AssemblyName>$(Product).$(MSBuildProjectName)</AssemblyName> (this can be in the csproj too, makes no difference) But I think the end result is the same, the 2-stage compilation process isn’t using the same assembly name for both stages, so when it tries to resolve types it can’t find them.

I urgently need a fix for this, because now my software won’t compile without adding explicit AssemblyName overrides to all of my projects.

I found that the issue here is the generated temporary project contains copy of everything defined in the original project resulting into the AssemblyName getting overridden by what is defined in the original project. The fix would be to not copy the AssemblyName property from the original project.

@las-nsc the root of the problem probably is the same. For this issue I’ve made minimal/simplified example. Originally I have *.props too. #5576 is for sure related, for my project I have some of mentioned errors too.

MSBuild Team Triage: We think this a WPF issue. It looks like the property AssemblyName is no longer being passed as a global property. See the picture below:

left side is a failed build (SDK 6.0.100), right side is a successful build (SDK 5.0.403)