New regression for AssemblyName in WPF apps

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work] [regression] [worked-in:17.11/net8]

History

This regression has similarities to #5711 and my own https://developercommunity.visualstudio.com/t/Some-build-properties-not-handled-correc/1612152. There is however a distinct new aspect to it.

I have a sln with several projects (class libraries, wpf libraries and winform libraries). To have consistent naming i defined AssemblyName in Directory.Build.props using macros. This worked fine but broke in wpf projects when updating from net6 to net7, as described in the linked issues.

Work around then

My work around was to keep the macro-based AssemblyName in Directory.Build.props, but to override it with a hard coded AssemblyName in the csproj-files of the wpf projects. This way i kept the dynamic naming for most projects, except for the wpf projects. This has worked fine through net7 and net8.

New issue

On update to net9 a similar problem appeared, regardless of updating projects themselves from net8 to net9 or not. It turns out, after some research, that it occurs when there is an AssemblyName element both in csproj and in Directory.Build.props, which is exactly what have as my previous workaround.

So maybe I can go back to only having AssemblyName in Directory.Build.props? Nope. Only thing that works is to have AssemblyName only in csproj in my wpf project. For all other projects it still works fine using Directory.Build.props. Catch-22!

Work around now

It turns out that AssemblyName in csproj now works with macros, also in wpf projects. So I can work around this problem by defining the desired assembly name in a temporary macro in Directory.Build.props and the define AssemblyName is csproj by referencing this temporary macro.

Example

I have attached a simple wpf project to illustrate the problem. Must be loaded on a computer with net9 installed. It comes with the problem in place. Comment out AssemblyName line in Directory.Build.props to make it work (ReBuild!)

Future

Investigation these issues has been quite time consuming and disrupting. First time it took quite long and I only stumbled across the pattern and the work around. This time I had a hunch from last time and was able nail it in a few hours, still with quite some luck.

Bt why are wpf project so special? Why don't they have the same build property resolution as other projects? This needs to be consolidated so we do not have more of these surprises in the future. I used to look forward to updates on .net and VS. I hope I can in the future as well.

---

Original Comments

Feedback Bot on 12/4/2024, 06:46 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

[miloush]

Sounds like duplicate of #10068

[imyrke]

Yes, seems to be the same issue. The information is slightly different and complementary to this one.