Regression for custom AssemblyName in WPF apps

[maciej-izak]

Issue Description

The PropertyGroup item AssemblyName cannot use macros for WPF app. This is regression, all was fine for previous MSBuild version (16)

Steps to Reproduce

Add to *.csproj something like :

        <MainName>$(MSBuildProjectName.Replace('-NetCore', ''))</MainName>
        <AssemblyName>$(MainName)</AssemblyName>

Example project attached:

WpfApp1.zip

Expected Behavior

Should compile/build

Actual Behavior

Error occurs :

  MainWindow.xaml(10, 10): [MC3074] The tag 'DelayTextBox' does not exist in XML namespace 'clr-namespace:WpfApp1'. Line 10 Position 10.

When mentioned above part of *.csproj is deleted all compiles/build again...

Analysis

Important note : to reproduce, ensure that bin and obj directories are deleted.

Versions & Configurations

17.0.0.52104

[jrboom]

I have the same issue since upgrading to VS2022.

[benvillalobos]

Team Triage: What msbuild version did this succeed on? We can't reproduce this with 16.11.0.

[maciej-izak]

@benvillalobos It was 16.9.0, but .NET 5.0 SDK on my CI system was not up to date, so I guess that 16.11.0 is also ok. With msbuild 17.0.0 I am not able to build my WPF projects for net5-windows nor net6-windows :(

[jrboom]

I can confirm that custom assembly names with macros were still working with 16.11.0, but stopped working with 17.0.0.
Custom assembly names without macros do work correctly with 17.0.0.

[benvillalobos]

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)

[las-nsc]

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.

[maciej-izak]

@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.

[las-nsc]

I had to revert back to 16.9.x to get it to compile again, 16.10.x, 16.11.x and 17.x all have the issue.

[las-nsc]

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.

[loicmorvan]

FYI Little repository to reproduce the issue: https://github.com/loicmorvan-ansys/XamlBugReproduction

[vishalmsft]

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)

@benvillalobos The image that you shared, helps in identifying the root cause.
As per the user, the issue can be observed, after upgrading the VS version.
Few questions:

1. Were there any changes in msbuild or prop file, defining or restricting the scope of properties or inheritance of those in child project?
2. Looked up the changes in Microsoft.WinFX.targets, There are no changes in the tasks or parameters.

[las-nsc]

@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.

[lmorvan]

Do you have sort of a planning for the publication of a fix?

[ThomasGoulet73]

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.

[msedi]

@ThomasGoulet73: Did you have any progress on your experiments? My output directory gets bloated and I cannot see any real output anymore.

[nvmkpk]

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.

[Svarr]

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

[LeroyPakade]

Is there any feedback on this, using. Net7 i cant seems to render any of the properties to reflect on my project file, im expecting to see the assembly's name as per the application general settings

<AssemblyName>$(MSBuildProjectName)</AssemblyName>

[Kuldeep-MS]

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

[HermanEldering]

@Kuldeep-MS does this also fix #2930?

It was suggested by someone in this thread that both issues have the same cause.

[Kuldeep-MS]

@Kuldeep-MS does this also fix #2930?

It was suggested by someone in this thread that both issues have the same cause.

@HermanEldering - No it dosen't. The fix is intended to solve the problem originally reported in this issue i.e. AssemblyName cannot use $MSBuildProjectName.