.NET 5.0 self-contained .exe with embedded native libraries is not compatible with WPF

[gjaw]

Description

Simple repro steps in command line:

• dotnet new wpf
• dotnet publish -f net5.0 -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesInSingleFile=true
• launch the generated executable from the publish directory

Expected behavior:

• Application launches and shows the main window of the template WPF application

Actual behavior:

• Application launches and immediately closes due to exception

Configuration

• .NET SDK 5.0.100-preview.6.20318.15
• Windows 10, 64-bit

Other information

This appears to be caused by WPF DLL consistency check: it is not allowing loading of PresentationNative_cor3.dll from the TEMP folder where it is extracted as part of the current method of embedding native libraries into single file publishing. For me it is not clear whether this bug should be assigned to dotnet/runtime or dotnet/wpf.

Here's the start of the exception message from Windows Application event log:

Application: net5bug.exe
CoreCLR Version: 5.0.20.30506
.NET Version: 5.0.0-preview.6.20305.6
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Windows.Markup.XamlParseException: The type initializer for 'System.Windows.Window' threw an 
exception.
 ---> System.InvalidProgramException: Failed WPF DLL consistency checks. Expected location: 
D:\source\net5bug\bin\Debug\net5.0\win-x64\publish.
DLL Name: PresentationNative_cor3.dll DLL Location: C:\Users\live\AppData\Local\Temp\.net\net5bug\fbkdtnhd.ocd

   at System.Windows.WpfDllVerifier.VerifyWpfDllSet(String[] additionalDlls)
   at System.Windows.Window..cctor()
   --- End of inner exception stack trace ---

[ghost]

Tagging subscribers to this area: @swaroop-sridhar, @agocke
Notify danmosemsft if you want to be subscribed.

[agocke]

Confirmed this locally.

[agocke]

@fabiant3 It looks like WPF has a hardcoded check (VerifyWpfDllSet) that prevents self-contained apps from embedding in single-file. Could you take a look at this and see what the fix should be?

[fabiant3]

@ryalanms will take a look. Is this blocking current preview?

[agocke]

It would be really good if we could get it in before the next (last) preview. Since this is a blocker for embedding assemblies in WPF apps I'm worried we may miss more fundamental bugs if we don't have at least one working Preview.

[jkotas]

It would be great to get rid of the call to Process.GetCurrentProcess().Modules during startup as side-effect of fixing this. Process.GetCurrentProcess().Modules is very expensive API that is meant for diagnostic. Calling it during startup is not a good idea and it causes other corner-case problems (see #37129).

[agocke]

This has been fixed in RC2