Microsoft.WindowsDesktop.App.Runtime.win-arm64 contains a stub "D3DCompiler_47.dll", causing issues with 3rd party libraries

kpreisser commented 3 years ago

.NET Core Version: .NET SDK 5.0.401
Windows version: Windows 11 Pro Version 21H2 (Build 22000.194) ARM64
Does the bug reproduce also in WPF for .NET Framework 4.8?: No

Problem description:

When publishing a WPF app targeting .NET 5.0/6.0 for win-arm64 (self-contained), a D3DCompiler_47.dll file is deployed in the application directory. However, in contrast to the file from the Windows System32 directory which has ~7 MB and has exports like D3DCompile, the file deployed by the .NET SDK has only ~23 KB and doesn't seem to have exports (it comes from the Microsoft.WindowsDesktop.App.Runtime.win-arm64 package).

Apparently, the presence of this stub DLL can cause issues with 3rd party libraries like CefSharp (embedded Chromium browser), because CEF also depends on D3DCompiler_47.dll. In some cases when starting the application, the chromium browser hangs, and the log file contains an error that it cannot find the D3DCompile entry point:

[1007/102117.812:WARNING:angle_platform_impl.cc(49)] Debug.cpp:180 (insertMessage): GL error: HIGH: Internal D3D11 error: HRESULT: 0x8007000E: Error finding D3DCompile entry point.
[1007/102117.813:ERROR:shared_context_state.cc(73)] Skia shader compilation error

Note: This doesn't occur when publishing the application for win-x86 and win-x64, because there, a file with a different name D3DCompiler_47_cor3.dll is deployed instead of D3DCompiler_47.dll (https://github.com/dotnet/wpf/issues/37#issuecomment-494984585), and that file seems to be a copy from the Windows SDK redist files with all the necessary exports.

Minimal repro:

Clone https://github.com/kpreisser/TestCefSharpWpf (commit 72171ce6dd) and publish the app using dotnet publish -f net5.0-windows -r win-arm64.
Run the published app on a Windows 11 Build 22000 ARM64 machine that has hardware-accelerated graphics (e.g. a Parallels Desktop VM running on a Apple M1 mac).
Notice that the embedded chromium browser sometimes only shows a white page (this doesn't always occur, sometimes you have to restart the app a few times). When this happens, errors as shown above (regarding the D3DCompile entry point) are logged to TestCefSharpChromiumLog.txt.
Now delete the file D3DCompiler_47.dll from the app's directory and also remove the corresponding entry in the TestCefSharpWpf.deps.json file, and start the app again.
Notice that the app now works without problems and shows the Google website (as it can now load D3DCompiler_47.dll from the Windows system32 directory).

Is this stub D3DCompiler_47.dll file for win-arm64 really needed?

Actual behavior: A stub D3DCompiler_47.dll is deployed when publishing the application, which can cause an issue in CEF as it may load that stub file instead of the one from the Windows system32 directory.

Expected behavior: No D3DCompiler_47.dll file is deployed, so that CEF can load the file from the Windows system32 directory (or, a file with a different name like D3DCompiler_47_cor3.dll like in the win-x86 and win-arm64 packages is deployed; although that file would probably be superfluous for win-arm64).

Thank you!

lindexi commented 3 years ago

I think we should rename it to D3DCompiler_47_cor3.dll in arm64

ryalanms commented 3 years ago

Thank you for the report, @kpreisser. Does the failure only occur when publishing as a self-contained application?

ryalanms commented 3 years ago

Because ARM64 WPF support doesn't include operating system versions that don't contain inbox d3dcompiler_47.dll (the shader compiler), d3dcompiler_47.dll can be excluded from the ARM64 WindowsDesktop SDK. It will always be in system32 on Windows10+.

It looks this property was meant to exclude d3dcompiler_47.dll from being copied and included in the package: https://github.com/dotnet/wpf/blob/main/src/Microsoft.DotNet.Wpf/redist/D3DCompiler/D3DCompiler.vcxproj#L52

Setting IsRedistProject to false will exclude files from CopyRedistFile but not CopyPackageAssets.

kpreisser commented 3 years ago

Hi @ryalanms, Yes, it seems the failure only occurs when publishing as self-contained app (when D3DCompiler_47.dll is copied to the application directory). When I set SelfContained as false, I can't reproduce the issue.

d3dcompiler_47.dll can be excluded from the ARM64 WindowsDesktop SDK. It will always be in system32 on Windows10+.

👍

Additionally, the current Windows 11 SDK (22000) seems to only include redistributables of D3DCompiler_47.dll for x64 and x86 but not arm64, so it seems to be intended to not redistribute this DLL for ARM64 and instead always use the system32 one.

Thank you!

ryalanms commented 3 years ago

This commit successfully removes the dll from the transport package for ARM64.

https://github.com/dotnet/wpf/commit/438d70ed139badb8400a2414db660858ae268b1f

hamarb123 commented 2 years ago

(originally commented in #5747) I'm having issues with this on my app. Can this be back-ported to .NET 6.0.4? I'm going to wait until next LTS for upgrade so I would be stuck not being able to support arm64 users until .NET 8 (~1.5 years).