Runtime: Crossgen removes "Win32Manifest" native resource from System.Windows.Forms.dll

[dagood]

Running crossgen on System.Windows.Forms seems to remove the Win32Manifest, causing errors at runtime that look like this: https://github.com/dotnet/winforms/issues/116.

For 3.0 Preview 5, I merged a workaround that disables crossgen on System.Windows.Forms.dll: https://github.com/dotnet/core-setup/pull/6128. Benefits of crossgen are noticeable in the WindowsDesktop shared framework so disabling it is not ideal. I haven't ported the fix to master hoping for a fix. (If it doesn't seem like one will land for Preview 6, I'll port the workaround to keep it intact.)

DLL before and after crossgen that exhibits the error: System.Windows.Forms-compare.zip

I have a 80 MB zip "test rig" that has all the dependencies required to crossgen this assembly--let me know offline if you want this and I can send a link.

@ericstj have you looked into the DLLs? I tried an "ordinary" ildasm and compare, but not sure where this shows up and I didn't see anything.

/cc @brianrob @dreddy-work @fadimounir @sergiy-k @davidwrighton

[ericstj]

The win32 manifest is not visualized by ildasm, but it will emit it in a .res file when you run it with /out. You can visualize the difference in Visual Studio, using File -> Open on the DLLs.

This will impact all customer apps as well (winforms + WPF), if they wish to crossgen them.

Simply do the following to reproduce the issue (using a recent SDK):

1. Dotnet new WPF
2. dotnet publish -r win-x64 /p:PublishReadyToRun=true
3. Examine the difference in native resources between the built and published location.

[sergiy-k]

@davidwrighton, could you please take a look?

[davidwrighton]

Sigh, yes. It is known that crossgen destroys all resources other than the file resource. I believe Fadi made some changes in desktop crossgen to fix this, so we may wish to recreate those changes in Core.

[davidwrighton]

@dagood, do you know if any language specific resources are required, or if any of our toolchains support non-neutral resources in the PE file?

[dagood]

do you know if any language specific resources are required, or if any of our toolchains support non-neutral resources in the PE file?

I don't have any experience with resource files, maybe @dreddy-work or @ericstj can answer?

[jkoritzinsky]

Linking to the other issue about this: dotnet/runtime#11475

[dreddy-work]

I do not have enough information on non-neutral resources. @Tanya-Solyanik may have.

[ericstj]

do you know if any language specific resources are required

Presumably we only care to support the set of things that the VB/C#/F# compilers support. If our compilers don't support it then it would mean that someone is rewriting the binary and will be able to rewrite the binary after crossgen as well.

Here's some relevant code:
https://github.com/dotnet/roslyn/blob/f40b89234db51da1e1153c14af184e618504be41/src/Compilers/Core/Portable/Compilation/Compilation.cs#L1521

[davidwrighton]

Well, I'll start with an implementation that copies only the neutral resources. That should be sufficient to solve this problem, and won't be all that hard to generalize into handling other languages as well. That matches the work that was done for the desktop framework.

[AaronRobinsonMSFT]

@davidwrighton Can you please try this with normal app manifests as well - see the issue @jkoritzinsky linked (#21006). Not only does dotnet/runtime#11475 impact RegFree, but also High-DPI support in WPF because that is also defined in the application manifest. Application manifests need to be retained in many scenarios.

[dagood]

I confirmed that this has flowed through all the way to Core-SDK to fix the original issue I was facing: the latest SDK bundle contains a WindowsDesktop with a R2R System.Windows.Forms.dll including its manifest. This results in the correct visual styles in the demo WinForms app I snagged. 🎉

(I can't speak to WPF, I'm not familiar enough with the scenario to know how to test that quickly.)