Add support for Windows ARM64 to CefSharp.NETCore packages

[kpreisser]

Fixes #2944
Relates to #3284

Summary:

• Added support for runtime identifier win-arm64 to the CefSharp.NETCore packages, so that they can be used to publish apps for win-arm64 on .NET 5.0 and higher.

Changes:

• Added platform arm64 to the platform-specific .NET Core projects (CefSharp.Core.Runtime.netcore, CefSharp.BrowserSubprocess.Core.netcore, CefSharp.BrowserSubprocess.netcore, CefSharp.Test.netcore, CefSharp.WinForms.Example.netcore, CefSharp.WPF.Example.netcore, CefSharp.OffScreen.Example.netcore).
  • Note: For .NET Core projects that now specify <Platforms>x86;x64;arm64</Platforms>, it seems we explicitly need to set <PlatformTarget> to arm64 when Platform is arm64. Without this, the PlatformTarget seems to be AnyCPU and e.g. the CefSharp.BrowserSubprocess.exe would be an x64 EXE. See: PlatformTarget is not set when Platform is "arm64" (MSBuild) dotnet/sdk#15434
• In CefSharp.BrowseSubprocess.netcore, added net5.0 as target framework, so that we can use the net5.0 EXE for win-arm64 (as .NET 5.0 officially supports creating Windows ARM64 apps).
• Updated Initializer.ModuleInitializer to use RuntimeInformation.ProcessArchitecture for building the platform-specific folder path.
• Switched the CefSharp.*.Example.netcore and CefSharp.Test.netcore projects from cef.redist.* to chromiumembeddedframework.runtime.
• Added the win-arm64 artifacts to the NuGet packages.
• Changed build.netcore.ps1 to also build for platform arm64.

How Has This Been Tested?

• Installed .NET SDK 6.0.100-preview.2.21155.3 (x64), switched CefSharp.MinimalExample.[WinForms|Wpf|OffScreen].netcore to net6.0-windows, switched to self-hosting the subprocess, referenced the built NuGet packages, and published the projects for win-arm64.
• Run the published apps on Windows 10 Pro (ARM64) Build 21337 on a Raspberry Pi 4 Model B (4 GB).
• Additionally, installed .NET SDK 6.0.100-preview.2.21155.3 (arm64) on the target machine and run the non-published version of CefSharp.MinimalExample.Winforms using the default CefSharp.BrowserSubprocess.exe.

Screenshots:

You can see in Architecture column of the task manager that the application is running natively as ARM64.
(Windows 10 on ARM also supports running x86 apps (and x64 in insider builds) using emulation, but they would run significantly slower than native ARM64 apps.)

CefSharp.MinimalExample.WinForms.netcore:

I changed the form title to output RuntimeInformation.FrameworkDescription and RuntimeInformation.ProcessArchitecture:

Self-hosting subprocess:

Default subprocess:

CefSharp.MinimalExample.Wpf.netcore:

CefSharp.MinimalExample.OffScreen.netcore:

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 88.1.2-CI3872 completed (commit bdc9e57f33 by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 88.1.2-CI3873 completed (commit 7d6897f57c by @kpreisser)

[amaitland]

• Upgrade to 88.1.2+gac8e5f0+chromium-88.0.4324.27 / Chromium 88.0.4324.27

Thanks for keeping this as it's own commit, I've cherry picked and have just pushed an update to 88.1.3. Hopefully it should be easy enough to rebase this on master.

• Note: For .NET Core projects that now specify <Platforms>x86;x64;arm64</Platforms>, it seems we explicitly need to set <PlatformTarget> to arm64 when Platform is arm64. Without this, the PlatformTarget seems to be AnyCPU and e.g. the CefSharp.BrowserSubprocess.exe would be an x64 EXE.

Seems like a bug, were you able to find an open issue?

Additionally, the current Windows ARM64 installer for .NET 5.0 doesn't include the Desktop Runtime (WinForms/WPF).

I was under the impression the WinForms ARM64 implementation was complete for .Net 5.0, how does one install WinForms on ARM64?

I'd like to remove the dependency on cef.redist.arm64 as it's only used in development. Switching the Net Core projects to using the chromiumembeddedframework.runtime package and specifying a RuntimeIdentifier should be feasible now as the packages are now on the verge of an official release.

I'll install the ARM64 cross compiler and build this locally when I get a chance.

Overall looks very promising, thanks for your efforts 👍

[kpreisser]

Thanks a lot for your feedback!

Hopefully it should be easy enough to rebase this on master.

I will look at rebasing it at current master when I have some time.

Seems like a bug, were you able to find an open issue?

I didn't find one in dotnet/sdk. I created a new issue here: dotnet/sdk#15434

I'd like to remove the dependency on cef.redist.arm64 as it's only used in development. Switching the Net Core projects to using the chromiumembeddedframework.runtime package and specifying a RuntimeIdentifier should be feasible now as the packages are now on the verge of an official release.

OK, I will look at switching the projects to the chromiumembeddedframework package.

Thank you!

[amaitland]

OK, I will look at switching the projects to the chromiumembeddedframework package

I can do that tomorrow.

[kpreisser]

I was under the impression the WinForms ARM64 implementation was complete for .Net 5.0, how does one install WinForms on ARM64?

The current .NET 5.0 installers for Windows ARM64 don't include the Windows Desktop components (WinForms+WPF) because WPF isn't yet ready for ARM64. See the 5.0-preview-8 blog post:

We added support for Windows ARM64 as part of this release. We’ve made the relatively late decision to delay the Windows Desktop component (Windows Forms, WPF). Windows Forms is near ready, but WPF is not, and we don’t want to release only half the Windows Desktop component, in part because we don’t test it in a split configuration. We hope to add the Windows Desktop component back as part of a 5.0 servicing update.

Sorry, I previously thought that publishing a WinForms app using RID win-arm64 already works with .NET 5.0.2, but apparently I had used a daily build of .NET 6.0 SDK (or a NuGet feed with daily builds). It doesn't yet seem work with the .NET 5.0 SDK.

[AppVeyorBot]

✅ Build CefSharp 88.1.3-CI3876 completed (commit 90860a4eb9 by @kpreisser)

[AppVeyorBot]

❌ Build CefSharp 88.1.3-CI3877 failed (commit cd21f96b25 by @kpreisser)

[kpreisser]

I rebased the PR on master branch. (Note: File CefSharp.Common.NETCore.targets still referenced version 87.1.13 of chromiumembeddedframework.runtime, I updated it also to 88.1.3.)

I have also updated the CefSharp.*.Example.netcore and CefSharp.Test.netcore projects to use chromiumembeddedframework.runtime instead of cef.redist and to specify a RuntimeIdentifier, so I think the cef.redist.arm64 package is now no longer needed.

However, I had to exclude these projects for build in the solution file for platform arm64, as otherwise it fails because WinForms and WPF are not yet available for ARM64 in .NET 5.0 SDK (and because they currently target netcoreapp3.1 only).
Once a .NET 5.0 release with full Windows ARM64 support is available, we can increase the TargetFramework to net5.0-windows and can include these projects again (and add win-arm64 to RuntimeIdentifiers).

Thank you!

[AppVeyorBot]

❌ Build CefSharp 88.1.3-CI3878 failed (commit c09603c02e by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 88.1.3-CI3879 completed (commit 4a32c20410 by @kpreisser)

[amaitland]

The current .NET 5.0 installers for Windows ARM64 don't include the Windows Desktop components (WinForms+WPF) because WPF isn't yet ready for ARM64. See the 5.0-preview-8 blog post:

Thanks for the clarification. Makes sense they want to ship them together.

I rebased the PR on master branch.

Great, thanks 👍

(Note: File CefSharp.Common.NETCore.targets still referenced version 87.1.13 of chromiumembeddedframework.runtime, I updated it also to 88.1.3.)

The build script should take care of updating this. https://github.com/cefsharp/CefSharp/blob/master/build.netcore.ps1#L293

I have also updated the CefSharp.*.Example.netcore and CefSharp.Test.netcore projects to use chromiumembeddedframework.runtime instead of cef.redist and to specify a RuntimeIdentifier, so I think the cef.redist.arm64 package is now no longer needed.

Excellent, thank you.

However, I had to exclude these projects for build in the solution file for platform arm64, as otherwise it fails because WinForms and WPF are not yet available for ARM64 in .NET 5.0 SDK (and because they currently target netcoreapp3.1 only).
Once a .NET 5.0 release with full Windows ARM64 support is available, we can increase the TargetFramework to net5.0-windows and can include these projects again (and add win-arm64 to RuntimeIdentifiers).

As it's not clear when the final release will happen I might try and merge this and comment out the minimum to keep things ticking along.

We should also look at updating our .vsconfig file. Adding Microsoft.VisualStudio.Component.VC.Tools.ARM64 should hopefully do the trick.

[amaitland]

The CefSharp.AfterBuild.targets likely needs to be updated now the switch to using the chromiumembeddedframework.runtime packages.

[amaitland]

After installing the ARM64 build tools I was able to successfully build using Visual Studio 👍 (I have no means of actually testing the resulting binaries)

[kpreisser]

I updated the .vsconfig to include the VC ARM64 tools, and updated CefSharp.AfterBuild.targets to remove the targets for copying the cef.redist files, which should no longer be needed after switching to chromiumembeddedframework.runtime.

Thank you!

[AppVeyorBot]

✅ Build CefSharp 88.1.3-CI3881 completed (commit dd89a62095 by @kpreisser)

[AppVeyorBot]

❌ Build CefSharp 88.1.6-CI3887 failed (commit a8b4cd803a by @kpreisser)

[kpreisser]

❌ Build CefSharp 88.1.6-CI3887 failed (commit a8b4cd8 by @kpreisser)

I think the build failure is unrelated to the changes in this PR.

[kpreisser]

Publishing WPF apps for win-arm64 seems to work now with .NET SDK 6.0.100-preview.1.21078.9 (daily build). I updated the first post to include a screenshot of CefSharp.MinimalExample.Wpf.netcore.

[AppVeyorBot]

❌ Build CefSharp 88.2.10-CI3897 failed (commit f3f61696f3 by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 88.2.10-CI3901 completed (commit b84d4eecf3 by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 89.0.50-CI3928 completed (commit 31faa243fd by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 89.0.60-CI3948 completed (commit a61f73e35d by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 90.1.10-CI3978 completed (commit 7fc4bf07e9 by @kpreisser)

[kpreisser]

I checked that the CefSharp.BrowserSubprocess.exe also works when building CefSharp.MinimalExample.WinForms.netcore for win-arm64 (see screenshot in first post). It seems the CefSharp.BrowserSubprocess.exe now also works when publishing the application as self-contained (thanks to 7c45907) 👍

@amaitland Is there anything still left to be done before this can be merged? Thanks!

[amaitland]

Thanks for the hard work on this 👍 I was hoping to find a way to runup a virtual machine to test this, wasn't clear that was possible currently on an Intel CPU.

I'll merge into master now, might be a few tweaks that I'll make later, probably switch the examples to always being SelfContained = false.

[kpreisser]

Great, thanks a lot! 👍

FYI, there is an unofficial/unsupported way to install a Windows 10 ARM64 build on a Raspberry Pi 3/4 (that has an ARM64 processor), which is what I was using to test the builds. You can search for "Windows on Raspberry" to find the tool that can be used for deploying the Windows image (I'd recommend to use a Raspberry Pi 4, which is much faster than a Pi 3).

As for VMs, it seems be possible to use QEMU on Windows to emulate an ARM64 processor on x64 hardware, but I haven't tried that yet (and according to the comments it seems to be very slow).