A blank .NET Core 3.1 WinForms app, published as self-contained and trimmed, still bundles all WPF DLLs

[noseratio]

• .NET Core Version:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.401
 Commit:    39d17847db

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19041
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.401\

Host (useful for support):
  Version: 3.1.7
  Commit:  fcfdef8d6b

• Have you experienced this same bug with .NET Framework?: N/A

Problem description: A blank 3.1 WinForms app, published as self-contained and trimmed, still bundles all WPF assemblies, which adds at least extra 12MB.

Expected behavior: WPF assemblies (Presentation*.dll etc) should not be included if the are not used.

Minimal repro:

dotnet new winforms 
dotnet publish -r win-x64 -c Release --self-contained true /p:PublishTrimmed=true 
cd .\MyFormsAppCore\bin\Release\netcoreapp3.1\win-x64\publish 
dir Presentation*.dll

Note all Presentation*.dll

[RussKie]

@danmosemsft can you help route this one?

[danmoseley]

@joperezr thoughts about where this should go?

[joperezr]

A couple of thoughts here:

• First is that at least with the latest linker, we by default only trim System.*.dlland Microsoft.*.dll so all other assemblies will by default be copied as-is. A TL;DR explanation of why, is that the linker is very smart but there are still ways of writing code where the linker won't be able to detect that some code needs to be kept, so if not annotated correctly it could by mistake remove that and cause an exception when the code tries to load at runtime. In System.*.dll and Microsoft.*.dll we are able to do this because we have been annotating appropriately all of these places in order to make them linker friendly, so that is why the linker will trim all of those but not others (including Presentation*.dll). @eerhardt can share more details and his opinion here, but I would probably move this issue over to the SDK to track the fact of also trimming Presentation*.dlland also log a bug into this repo in order to make the dlls linker friendly.
• One last thing to add is that there has been a lot of progress in both self-contained and trimming for 5.0 so a lot of the behaviour you are seeing in the 3.1 SDK will change significantly if you use a preview for 5.0, so my suggestion for @noseratio would be to download the latest preview SDK https://dotnet.microsoft.com/download/dotnet/5.0 and try the same experiment as I'm sure that you'll notice some difference in the way the linker behaves and what it outputs.

[noseratio]

@joperezr, thanks for your thoughts. I've just tried it with the .NET SDK 5.0.100-preview.7 and it still bundles the WPF assemblies. That was very easy to do under Windows Sandbox, using the same two commands from the "Minimal repro" section in my report.

Also, for the sake of trying, I deleted Presentation*.dll and edited them out of the generated MyFormsAppCore.deps.json. The app wouldn't start then. I can speculate that WinForms and WPF assemblies may have some mutual dependencies. This can also be easily repro'ed with the placeholder blank app as above.

I suppose I'll have to move on and package it as is for my otherwise lightweight WinForms app. One other option I considered was to back-port it to NET 4.8 to keep the download size to a minimum, but I really like using the modern .NET and C# 8+.

[eerhardt]

To follow up on what @joperezr said above -

The reason all the Presentation*.dll files still exist is because the SDK is explicitly marking them as copy, which means they won't be trimmed. The reason the SDK is marking them as copy is because by default the only assemblies that can be trimmed come from the Microsoft.NETCore.App runtimepack.

You can see that by the IsTrimmable="true" property here:

https://github.com/dotnet/installer/blob/ceb129f3455383f01d78052999b8a6d6201be261/src/redist/targets/GenerateBundledVersions.targets#L217

    <KnownFrameworkReference Include="Microsoft.NETCore.App"
                              TargetFramework="netcoreapp5.0"
                              RuntimeFrameworkName="Microsoft.NETCore.App"
                              DefaultRuntimeFrameworkVersion="$(MicrosoftNETCoreAppDefaultRuntimeFrameworkVersion)"
                              LatestRuntimeFrameworkVersion="$(MicrosoftNETCoreAppRuntimePackageVersion)"
                              TargetingPackName="Microsoft.NETCore.App.Ref"
                              TargetingPackVersion="$(MicrosoftNETCoreAppRefPackageVersion)"
                              RuntimePackNamePatterns="Microsoft.NETCore.App.Runtime.**RID**"
                              RuntimePackRuntimeIdentifiers="@(NetCoreRuntimePackRids, '%3B')"
                              IsTrimmable="true"
                              />

The Microsoft.WindowsDesktop.App entry doesn't have IsTrimmable="true", so the SDK/linker won't trim any assembly coming from that package. The same is true for the Microsoft.AspNetCore.App.

    <KnownFrameworkReference Include="Microsoft.WindowsDesktop.App"
                              TargetFramework="netcoreapp5.0"
                              RuntimeFrameworkName="Microsoft.WindowsDesktop.App"
                              DefaultRuntimeFrameworkVersion="$(MicrosoftWindowsDesktopAppDefaultRuntimeFrameworkVersion)"
                              LatestRuntimeFrameworkVersion="$(MicrosoftWindowsDesktopAppRuntimePackageVersion)"
                              TargetingPackName="Microsoft.WindowsDesktop.App.Ref"
                              TargetingPackVersion="$(MicrosoftWindowsDesktopAppRefPackageVersion)"
                              RuntimePackNamePatterns="Microsoft.WindowsDesktop.App.Runtime.**RID**"
                              RuntimePackRuntimeIdentifiers="@(WindowsDesktopRuntimePackRids, '%3B')"
                              IsWindowsOnly="true"
                              />

So if we wanted to allow WPF apps to trim WinForms assemblies, and vice-versa, we would need to set IsTrimmable for the <KnownFrameworkReference Include="Microsoft.WindowsDesktop.App". And then of course test it and make sure it works correctly.

cc @sbomer

[AraHaan]

Cant people who consume these do <KnownFrameworkReference Update="Microsoft.WindowsDesktop.App" IsTrimmable="true" /> from within an ItemGroup on their project files in the mean time?

[darkguy2008]

Is this a possible thing we can look forward for .NET 7.0? :) most WinForms libraries don't seem to be trimmable, although there seem to be some progress in the NativeAOT department with the ComWrappers repo going mainline someday soon.

[agocke]

@LakshanF Is this fixed now?

[LakshanF]

Yes, https://github.com/dotnet/sdk/pull/39402 and https://github.com/dotnet/windowsdesktop/pull/4227 should have addressed this.

[elachlan]

@Olina-Zhang can your team please test this so we can resolve it?

[MelonWang1]

@elachlan @agocke @LakshanF Verified it in the latest .NET 9.0 SDK build: 9.0.100-preview.6.24318.4, screenshot as below, is this expected?

.NET 3.1 app screenshot:

[elachlan]

@LakshanF we are still including PresentationNative_cor3.dll, should it be included?

[LakshanF]

@LakshanF we are still including PresentationNative_cor3.dll, should it be included?

Removed the WinForms profile in the PR, https://github.com/dotnet/windowsdesktop/pull/4462

[LakshanF]

@elachlan @agocke @LakshanF Verified it in the latest .NET 9.0 SDK build: 9.0.100-preview.6.24318.4, screenshot as below, is this expected?

It will be good to validate that both WPF and WinForms published SelfContained applications run without problems

[agocke]

I want to note that any change made here will be .NET 9 only -- we don't make product feature changes in servicing.

Also, 3.1 is out of support, you shouldn't be using it at all, under any circumstances.

[MelonWang1]

@LakshanF Verified this issue with WPF application, screenshot as below, but cannot run .exe file using both cmd and double click in file explore. Event Viewer has the application error.

Winforms application can run successfully.

[LakshanF]

@LakshanF Verified this issue with WPF application, screenshot as below, but cannot run .exe file using both cmd and double click in file explore.

WPF and WinForms applications are not supported in trimmed mode. This change impacts default WinForms and WPF applications in self-contained mode, and published SelfContained applications should run without problems (without the PublishTrimmed property)

[elachlan]

@MelonWang1 maybe raise an issue in the WPF repo to let them know?

Once windows desktop propagates, we can retest and close this. @LakshanF should it be included in the next nightly update?

[MelonWang1]

@LakshanF If using cmd "dotnet publish -r win-x64 -c Release --self-contained true" to publish wpf application, the .exe file can run successfully. @elachlan Filed wpf issue: 9274.