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

• .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.

See also https://github.com/cefsharp/CefSharp/issues/2944#issuecomment-937595542.

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!

[ThomasGoulet73]

.Net 6.0.6 was just released and contains the fix for this issue: https://github.com/dotnet/wpf/releases/tag/v6.0.6

[singhashish-wpf]

We are in process of pushing this to 6.0 servicing, earliest you can expect it to be in June servicing release. https://github.com/dotnet/wpf/pull/6496