.NET 5 SDK produces broken WPF 3.1 app when trimming and R2R are both enabled

[vitek-karas]

Create a WPF template app for netcoreapp3.1"

dotnet new wpf -f netcoreapp3.1
dotent publish -r win-x64 /p:PublishTrimmed=true /p:PublishReadyToRun=true
run the app

Running the app will not have any visible effect (no window appears). Checking event log shows that there was an exception in the process, but no details. Attaching a debugger shows that there was a failure to load one of the diag assemblies which eventually leads to the process crashing.

Enabling R2R warnings shows:

RUNREADYTORUNCOMPILER : warning : Could not load type 'System.Transactions.Transaction' from assembly 'System.Private.Uri, Version=4.0.6.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. while resolving 0x100016e - System.Transactions.Transaction. [F:\AppModel\repro\wpf3\wpf3.csproj]
RUNREADYTORUNCOMPILER : warning : Could not load type 'System.Threading.ThreadPriority' from assembly 'System.Threading.Thread, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. while resolving 0x1000161 - System.Printing.LocalPrintServer. [F:\AppModel\repro\wpf3\wpf3.csproj]
RUNREADYTORUNCOMPILER : warning : Could not load type 'System.Threading.ThreadPriority' from assembly 'System.Threading.Thread, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. while resolving 0x1000162 - System.Printing.PrintServer. [F:\AppModel\repro\wpf3\wpf3.csproj]
RUNREADYTORUNCOMPILER : warning : Could not load type 'System.Threading.ThreadPriority' from assembly 'System.Threading.Thread, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. while resolving 0xa00042c - System.Printing.LocalPrintServer..ctor. [F:\AppModel\repro\wpf3\wpf3.csproj]
RUNREADYTORUNCOMPILER : warning : Could not load type 'System.Threading.ThreadPriority' from assembly 'System.Threading.Thread, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. while resolving 0xa00042d - System.Printing.PrintServer.GetPrintQueues. [F:\AppModel\repro\wpf3\wpf3.csproj]
RUNREADYTORUNCOMPILER : warning : Could not load type 'System.Threading.ThreadPriority' from assembly 'System.Threading.Thread, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. while resolving 0xa002096 - System.Printing.LocalPrintServer.get_DefaultPrintQueue. [F:\AppModel\repro\wpf3\wpf3.csproj]

This was done with:

.NET SDK (reflecting any global.json):
 Version:   5.0.100-rtm.20515.8
 Commit:    d4436c7f87

Doing the same with 3.1.403 SDK works - the app will start just fine. Note though that R2R reports MANY more warnings.

Note:

• Using 5.0 SDK and using just trimming -> app works
• Using 5.0 SDK and using just R2R -> app works
• Seems to be a regression from 3.1

Doing the same for net5.0 also breaks but it seems to be for a slightly different reason - in the 5.0 case just trimming the app (without R2R) breaks the app.

[vitek-karas]

Created a separate issue for the net5.0 case: #14261

[agocke]

Dup of dotnet/wpf#3811

[vitek-karas]

I don't think this is a dupe of trimming issues alone. Note this in the original issue:

• Using 5.0 SDK and using just trimming -> app works
• Using 5.0 SDK and using just R2R -> app works
• Seems to be a regression from 3.1

The fact that just trimming or just R2R alone doesn't break the app means that it's only the combination of the two which is problematic - which is something we should try to understand I think.

[agocke]

If the app works when trimmed, then fails after R2R, that sounds like R2R would be the first place to look. Do you agree?

[vitek-karas]

Could be - granted this is on .NET 5 - not sure how much priority we want to give to it. (On 6 even the trimmed app breaks and now we actually produce a warning, so the experience is very different).

[agocke]

.NET 6 also uses crossgen2 instead, so this doesn't sound like a high priority.

[GF-Huang]

Still occurs at .NET 5 for me, if publish by enable ReadyToRun, app crash at being (no window show). This doesn't always appear, but it appears after I added the logging. Could it be a Microsoft.Extensions.Logging problem?