System.CodeDom.dll is copied to the output/build directory when referencing System.Management v9

[EatonZ]

The issue I reported last year with .NET 8 is now happening again with .NET 9.

The same repro steps and details as described in that original issue apply to .NET 9.

@lonitra Can you help with this again?

[lonitra]

We had attempted to mitigate this issue from occurring again by applying same resolution for 9.0 via #4782. I double checked again just now that PlatformManifest in release/9.0 branch contains the same information as the PlatformManifest that is provided with .NET 9 GA at C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\9.0.0\data\PlatformManifest.txt
@EatonZ Could you provide the dotnet 9 version you are using?
@ericstj do you have any ideas what else could be causing this issue?
@dotnet/dotnet-winforms FYI

[EatonZ]

I am using .NET 9.0.3.

[ericstj]

TL;DR - stop checking in PlatformManifest.txt and generate it.

Related to this -- #4904

Right now 9.0 contains the 9.0 GA versions, so if a CodeDom newer than GA is used, it will be copied app local.

What we've done for both Asp.NET and NetCore.App is stop pinning the data files to GA. We've found that folks prefer to float the conflict-resolution information because they typically update both their SDKs and runtime installations. Mentioned in the linked issue:

Per dotnet/sdk#44566 this file (and other conflict resolution data) should track the latest versions rather than GA.

Also in 10.0 the package pruning feature will handle this during restore.

So I'd say it's by-design that a version of System.CodeDom newer than GA becomes app-local for WindowsDesktop apps, but after the changes described it will not. I'd say this is a safe change to take in servicing and consider it reactive to the increased frequency of dotnet/runtime package updates.

cc @ViktorHofer

[EatonZ]

If there is a way to stop this from happening until the next servicing release, please let me know.