Feature Request - ARM64 support on .NET Framework 4.8.1

[simplejackcoder]

Bulk of the work to support Windows ARM64 is done. The only feature that will help is if CefSharp could also be compiled for .NET Framework ARM64 support.

It should merely be recompiling the managed components and the managed C++ components but leaving the rest of the native parts unchanged.

This will allow applications that are running on .NET Framework 4.8.1 on Windows 11 ARM64 to work flawlessly.

[kpreisser]

Note that using arm64 for C++/CLI projects targeting .NET Framework seems to require VS 2022 17.3 and using the v143 toolset, as that includes an ARM64 version of mscoree.lib. However, the actual .NET target framework of the project can be a lower one, e.g. .NET Framework 4.5.2.

For regular .NET Framework projects, using arm64 as PlatformType seems to already work with VS 2019 (16.11), even for Exe projects when using a lower target framework like 4.5.2.

I think that once we can use VS 2022 17.3 to build CefSharp (with AppVeyor), adding ARM64 support for .NET Framework would be possible in principle without changing the target framework of the projects (except for the C++/CLI projects which would need to use the C++ v143 toolset for arm64).

The only open points I can think of is where the process architecture needs to be determined. For example, DependencyChecker needs to check for arm64 to exclude D3DCompiler_47.dll from the files list (#3841), but RuntimeInformation.ProcessArchitecture is only available since .NET Framework 4.7.1.

Also, class CefRuntime uses Environment.Is64BitProcess() to distinguish between x86 and x64, which would incorrectly result in x64 when running as arm64, but that seems to only be used for support of AnyCPU applications which wouldn't run as arm64 anyway (AnyCPU apps run either as x86 (if Prefer32Bit is set) or as x64 on Windows 11 Version 22H2 ARM64, even when targeting .NET Framework 4.8.1).

[driver1998]

AnyCPU apps can be run as ARM64 (or any other architecture, excluding ARM32 since .NET Framework ARM32 is not available) with start /machine <arch> your-app.exe in Windows 11 22H2. Not sure about other ways of doing this.

One possible workaround might be just P/Invoke IsWow64Process2 (Note x64 on ARM64 is not considered as WOW64 process so pProcessMachine would be IMAGE_FILE_MACHINE_UNKNOWN), and GetProcessInformation with ProcessInformationClass = ProcessMachineTypeInfo (which detects x64 on ARM64 correctly but only available in Windows 11)

[kpreisser]

Hi,

AnyCPU apps can be run as ARM64 (or any other architecture, excluding ARM32 since .NET Framework ARM32 is not available) with start /machine your-app.exe in Windows 11 22H2.

Thank you for the info! You are right, with this command I was able to run an AnyCPU .NET Framework application (targeting 4.7.2) as ARM64 (when Prefer32Bit was false). So it seems we also need to consider the case in CefRuntime for ARM64.

One possible workaround might be just P/Invoke IsWow64Process2 (Note x64 on ARM64 is not considered as WOW64 process so pProcessMachine would be IMAGE_FILE_MACHINE_UNKNOWN), and GetProcessInformation with ProcessInformationClass = ProcessMachineTypeInfo (which detects x64 on ARM64 correctly but only available in Windows 11)

Alternatively, maybe we could also try to use reflection to get RuntimeInformation.ProcessArchitecture to determine the process architecture. If this is not available, it must be an older .NET Framework version (before 4.7.1) that cannot run as ARM64, where then Environment.Is64BitProcess can be used.

(For IsWow64Process2, note that it is only available starting with Windows 10 build 16299 (RS3).)

[driver1998]

The command should be start /machine arm64 your-app.exe but I guess you've already figured that out ;).

[amaitland]

Note that using arm64 for C++/CLI projects targeting .NET Framework seems to require VS 2022 17.3 and using the v143 toolset, as that includes an ARM64 version of mscoree.lib

Adding the required variants to the project files should be relatively easy. If someone wants to kick this off by creating a PR that only gets the basics building then by all means feel free. Avoid package changes for now.

The packaging will be a problem, upgrading to VS2022 will either require updating the minimum required VC++ runtime or building with the older v142 tools assuming we can find a build host with support.

I'd rather avoid upgrading the minimum VC++ version for x86 and x64, so that's something we'll need to look into.

Issue cefsharp/cef-binary#93 will also need to be resolved before any sort of package can be created.

For testing purposes the examples already use the chromiumembeddedframework.runtime packages.

The only open points I can think of is where the process architecture needs to be determined. For example, DependencyChecker needs to check for arm64 to exclude D3DCompiler_47.dll from the files list (#3841), but RuntimeInformation.ProcessArchitecture is only available since .NET Framework 4.7.1.

Seeing if we can use reflection seems like a reasonable first step for this and CefRuntime.

[amaitland]

As with ARM64 support for .Net 5.0+ I'll be relying on the community to contribute and test as I don't have an ARM64 device.

[amaitland]

The packaging will be a problem, upgrading to VS2022 will either require updating the minimum required VC++ runtime or building with the older v142 tools assuming we can find a build host with support.

Issue #4640 will track upgrading to VC++ 2022 (using VS2022 as the build version). If CEF starts using C++20 features then we will be forced to upgrade.

[stojy]

Has there been any movement towards building CefSharp that supports ARM64? It certainly would be a very nice feature!

Out of interest, is the blocker the VS22 upgrade, v143 toolset, or relying on .net 4.7.1 for RuntimeInformation.ProcessArchitecture?

[amaitland]

Has there been any movement towards building CefSharp that supports ARM64?

Not that I'm aware of. You can of course use .Net 5.0 or greater

This is currently blocked on #4640

[amaitland]

This is currently blocked on #4640

This issue has been resolved.

It should now be possible to implement this if someone wants to contribute a PR.

[stojy]

Hi @amaitland

I appreciate yours and @jamescharters effort in getting this one across the line.

Do you have an ETA when the new PR #5267 will be merged in and released?

Thanks.

[amaitland]

No ETA. The build is passing on CI. I have no means of testing it.

Once it's been tested it can be merged.