wpf application crashes immediately (System.Windows.Threading.DispatcherObject, WindowsBase)

[consysPM]

• .NET Core Version: 3.1.416
• Windows version: Version 20H2 (OS Build 19042.1415)
• Does the bug reproduce also in WPF for .NET Framework 4.8?: n/a

Problem description:
when publishing the project the wrong WindowsBase.dll gets copied.

Actual behavior:
Application: sds.master.exe
CoreCLR Version: 4.700.21.56803
.NET Core Version: 3.1.22
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeLoadException: Could not load type 'System.Windows.Threading.DispatcherObject' from assembly 'WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

Expected behavior:
The wpf application should not crash.

Minimal repro:

1. create new solution
2. add wpf project
3. add asp.net core project or class library
4. publish project: dotnet publish -o <OUTPUT_DIR> --self-contained true -r win10-x64 --force
5. start the wpf application -> crash
   

NOTE
With NET Core Version 3.0.100 everything is working as expected.

WpfApp2.zip

JSON ZIP:
json.zip

[lindexi]

@consysPM Do you use any assembly that reference dotnet framework?

The 'WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' is the dotnet framework version, not the dotnet core version.

[gurpreet-wpf]

@consysPM Can you please attach a sample project?

[consysPM]

@consysPM Can you please attach a sample project?

i have attached the solution -> WpfApp2.zip

to reproduce the behavior open the terminal and execute:
dotnet publish -o <OUTPUT_FOLDER> --self-contained true -r win10-x64 --force

the created WindowsBase.dll file will only have 15kb and the executable will crash immediately

thanks

[consysPM]

i have found a workaround for everyone who is interested:

every net core 3.1 project must use the flag UseWPF: true within the propertygroup of the csproj file. this will "fix" the issue.

however this should not be the final solution.

[vishalmsft]

@consysPM I tried the application that you have shared. Not able to reproduce the issue.
Can you help with attaching following files from failed output folder:
<OUTPUT_FOLDER>*.json

What is the output of
dotnet --list-runtimes
dotnet --list-sdks

[consysPM]

@consysPM I tried the application that you have shared. Not able to reproduce the issue. Can you help with attaching following files from failed output folder: <OUTPUT_FOLDER>*.json

What is the output of dotnet --list-runtimes dotnet --list-sdks

u will find the json files above. -> json.zip

dotnet --list-runtimes:

Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

dotnet --list-sdks

2.1.818 [C:\Program Files\dotnet\sdk]
2.2.207 [C:\Program Files\dotnet\sdk]
3.0.100 [C:\Program Files\dotnet\sdk]
3.1.100 [C:\Program Files\dotnet\sdk]
3.1.416 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
5.0.210 [C:\Program Files\dotnet\sdk]
5.0.303 [C:\Program Files\dotnet\sdk]
5.0.404 [C:\Program Files\dotnet\sdk]

[consysPM]

@consysPM I tried the application that you have shared. Not able to reproduce the issue. Can you help with attaching following files from failed output folder: <OUTPUT_FOLDER>*.json

What is the output of dotnet --list-runtimes dotnet --list-sdks

here is a video proof that the app is crashing :)

wpf.mp4

[vishalmsft]

as proof you can watch the video file :)

Need that information just to be able to understand the build environment. Thank you for video, appreciate your efforts to explain the problem.

[vishalmsft]

One more question, what happens, if you have NET 6.0 or NET 7.0 installed on the machine. I am not able to reproduce the problem at all, but, I have these two installed. I am using the sample application provided in the original bug.

[consysPM]

One more question, what happens, if you have NET 6.0 or NET 7.0 installed on the machine. I am not able to reproduce the problem at all, but, I have these two installed. I am using the sample application provided in the original bug.

i dont have net 6.0 or 7.0 installed (are this versions only available for visual studio 2022? i have vs 2019 community installed)
but if i use net core 3.0(instead of 3.1) everything works as expected and the app dont crash

[vishalmsft]

You can download the installers from here
Do not change the framework version in csproj. Hence, target framework version will still remain 3.1. Checking, why problem isn't reproducible.

[consysPM]

You can download the installers from here Do not change the framework version in csproj. Hence, target framework version will still remain 3.1. Checking, why problem isn't reproducible.

the installer will not work (according to microsoft) for visual studio 2019

[vishalmsft]

Yes, .NET 6.0 and up, will need to try with VS2022. May be trying on a separate VM will help?

[consysPM]

Yes, .NET 6.0 and up, will need to try with VS2022. May be trying on a separate VM will help?

i have tried it with .NET 5 and it works. (i have changed every referenced project to .NET 5)
However, this is not an acceptable solution because we need to stay with VS2019 and need LTS.

can u try to set up a VM with only .net core 3.1 and VS2019 installed? :)

thanks

[vishalmsft]

The issue is reproducible, as soon as, I upgraded the VS2019. The observations were similar, as we had in the issue #5711
This may be due to some the properties are not getting passed in msbuild.

Will this thread updated.

[czdietrich]

If I'm not mistaken the cause of the issue comes from mixing two different FrameworkReferences when publishing self contained. Simplified spoken the class library and ASP.NET projects will use the runtime DLLs from Microsoft.NetCore.App, while the WPF project will use the DLLs from Microsoft.Windowsdesktop.App.

You can easily check this if you compare the content of the related NuGet-Packages that are used when publishing an application.

The default location for runtime DLLs for .NET Core apps is:
%UserProfile%\.nuget\packages\microsoft.netcore.app.runtime.<RID>\<SDK>\runtimes\<RID>\lib\<Framework>

And the default location for runtime DLLs for .NET Desktop apps is:
%UserProfile%\.nuget\packages\microsoft.windowsdesktop.app.runtime.<RID>\<SDK>\runtimes\<RID>\lib\<Framework>

You'll see that there are a hand full of DLLs with identical name and base version but different in e.g. size.

For example for win-x64 in .NET 6.0.1 the WindowsBase.dll is 15.6 KB (v6.0.121.56705) for .NET Core and 2.15 MB (v6.0.121.56707) for .NET Core Desktop.

That is probably the reason why the "wrong" WindowsBase.dll is published into your output-directory.
I guess you could try setting UseWpf=true in all projects to workaround this issue. (not tested)

[pchaurasia14]

@consysPM - Does the above suggestion work for you?. If yes, could you please close this issue.

[consysPM]

yes, but this is not a solution, but a workaround

[pchaurasia14]

@consysPM - Does it reproduce for .NET 6 as well ?

[consysPM]

Its only .NET 3.1. However we can not switch to VS 2022 until end of the year.