Net Core - Don't check for presence of "d3dcompiler_47.dll" on ARM64

[kpreisser]

Don't check for presence of d3dcompiler_47.dll when running as ARM64, because that file isn't present in the CEF redist for this architecture.
Currently, the .NET SDK copies a stub D3DCompiler_47.dll file to the application's directory (so the dependency check currently succeeds), but once that is fixed and that file is no longer deployed, the dependency check would fail on ARM64.

Issue #2944

Summary:

• Don't check for presence of d3dcompiler_47.dll when current architecture is arm64.

Changes:

• Changed field initializer of DependencyChecker.CefOptionalDependencies to not include d3dcompiler_47.dll in the array when running on .NET Core and RuntimeInformation.ProcessArchitecture is Architecture.Arm64.

How Has This Been Tested?

• Published CefSharp.MinimalExample.Wpf.netcore for win-arm64 (target framework net5.0-windows).
• Deleted file D3DCompiler_47.dll from the published files and removed the corresponding entry from CefSharp.MinimalExample.Wpf.netcore.deps.json.
• Copied the published files to a Windows 11 ARM64 Build 22000 machine and run the application.
• Verified that before the change, the app fails with exception Unable to locate required Cef/CefSharp dependencies: Missing:C:\..\d3dcompiler_47.dll, and after the change, the app starts successfully.
• Also verified that when performing the same steps for a x64 machine, after the change when deleting file d3dcompiler_47.dll, the exception is still thrown as expected.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Updated documentation

Checklist:

• Tested the code(if applicable)
• Commented my code
• Changed the documentation(if applicable)
• New files have a license disclaimer
• The formatting is consistent with the project (project supports .editorconfig)

[AppVeyorBot]

✅ Build CefSharp 94.4.20-CI4259 completed (commit 91d8510876 by @kpreisser)

[kpreisser]

I revised the PR to not change the public API, but instead make the contents of DependencyChecker.CefOptionalDependencies depend on the current architecture.

[AppVeyorBot]

✅ Build CefSharp 94.4.20-CI4260 completed (commit 1dc0b75f3a by @kpreisser)

[amaitland]

Thanks 👍

What about something like the following? I don't love the Concat directly in the static declaration, wouldn't be great trying to step through with the debugger.

private const string D3DCompilerDll = "d3dcompiler_47.dll";

#if NETCOREAPP
        static DependencyChecker()
        {
            //win-arm64 doesn't ship with a copy of the D3D Compiler, it's included with the OS.
            if (System.Runtime.InteropServices.RuntimeInformation.ProcessArchitecture is System.Runtime.InteropServices.Architecture.Arm64)
            {
                CefOptionalDependencies = CefOptionalDependencies.Where(x => x != D3DCompilerDll).ToArray();
            }            
        }
#endif

[kpreisser]

Thank you, I changed the code accordingly to remove the d3dcompiler_47.dll entry in the static constructor.

Do you prefer to avoid having the #if NETCOREAPP directives in the top using block? It would be possible, but (I think) make the code less readable, e.g.:

#if NETCOREAPP
        static DependencyChecker()
        {
            // win-arm64 doesn't ship with a copy of the D3D Compiler, it's included with the OS.
            if (System.Runtime.InteropServices.RuntimeInformation.ProcessArchitecture is System.Runtime.InteropServices.Architecture.Arm64)
            {
                CefOptionalDependencies = System.Linq.Enumerable.ToArray(System.Linq.Enumerable.Where(CefOptionalDependencies, x => x != D3DCompilerDll));
            }
        }
#endif

[AppVeyorBot]

❌ Build CefSharp 94.4.20-CI4262 failed (commit 0ab6b3ca32 by @kpreisser)

[amaitland]

Great, thanks 👍

I think the build errors are totally unrelated.

Do you prefer to avoid having the #if NETCOREAPP directives in the top using block? It would be possible, but (I think) make the code less readable, e.g.:

Either is fine really. If it's just a single entry then I just normally use the VS fixup and have to specify the full namespace.