Add support for Arm64EC platform for COM based addins

[jozefizso]

The Microsoft Office on Windows 11 Arm is running in the Arm64EC mode.

We have COM addins written in .NET and they can be compiled for the x86 and x64 platform to run natively on respective Microsoft Office builds.

We are unable to target the Arm version of Microsoft Office because it is compiled in Arm64EC and the .NET arm64 platform is not compatible with it.

https://learn.microsoft.com/en-us/windows/arm/arm64ec#interoperability

Altough a COM addin built for x64 platform will load in Office Arm64EC, the performace is terrible and the product is terrible to use unless it is running as native Arm code.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The Microsoft Office on Windows 11 Arm is running in the Arm64EC mode.

We have COM addins written in .NET and they can be compiled for the x86 and x64 platform to run natively on respective Microsoft Office builds.

We are unable to target the Arm version of Microsoft Office because it is compiled in Arm64EC and the .NET arm64 platform is not compatible with it.

https://learn.microsoft.com/en-us/windows/arm/arm64ec#interoperability

Altough a COM addin built for x64 platform will load in Office Arm64EC, the performace is terrible and the product is terrible to use unless it is running as native Arm code.

Author:	jozefizso
Assignees:	-
Labels:	area-CodeGen-coreclr, untriaged
Milestone:	-

[filipnavara]

For reference, here are links to previous discussions about ARM64EC support:

• ARM64EC / ARM64X support for runtime and NativeAOT #78192
• Add plan for x64 emulation designs#217

[jozefizso]

Building a simple .NET Core based add-in for Microsoft Office on Windows 11 ARM64 requires the project to target the x64 platform, otherwise the comhost for the addin won't load:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8</TargetFramework>
    <EnableComHosting>true</EnableComHosting>
    <PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>
</Project>

Building the project will use the comhost.dll from [email protected] package which is a x64 library. The build will add the .clsidmap configuration in the JSON format to the comhost.dll in the _CreateComHost target. This map allows the native code to locate the correct assembly and class based on the CLSID.

Office applications in ARM64EC mode can load x64 libraries and the addin will run in x64 mode.

Native ARM add-in

It is not possible use the arm64 platform to make an Office add-in using .NET Core. The runtime and comhost are built for arm64 platform and the Office hosting applications are running in ARM64EC mode with cannot load arm64 libraries.

comhost for ARM64EC platform

The comhost project can be modified to target arm64ec platform. Modifying the [email protected] package by replacing the comhost.dll file with arm64ec version will allow the add-in project to be compiled with PlatformTarget=arm64.

Such add-in can be loaded in the Office app but the code will fail to load the hostfxr as it is native arm64 library and those cannot be loaded to ARM64EC process.

Tracing enabled @ Fri Dec 29 16:26:42 2023 GMT
Looking for architecture-specific registry value in 'HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\arm64\InstallLocation'.
Found registered install location 'C:\Program Files\dotnet\'.
Using global installation location [C:\Program Files\dotnet\] as runtime location.
Reading fx resolver directory=[C:\Program Files\dotnet\host\fxr]
Considering fxr version=[8.0.0]...
Detected latest fxr version=[C:\Program Files\dotnet\host\fxr\8.0.0]...
Resolved fxr [C:\Program Files\dotnet\host\fxr\8.0.0\hostfxr.dll]...
Failed to load the dll from [C:\Program Files\dotnet\host\fxr\8.0.0\hostfxr.dll], HRESULT: 0x800700C1
The library hostfxr.dll was found, but loading it from C:\Program Files\dotnet\host\fxr\8.0.0\hostfxr.dll failed
  - Installing .NET prerequisites might help resolve this problem.
     https://go.microsoft.com/fwlink/?linkid=798306

[AaronRobinsonMSFT]

This would require building the comhost in another form. It is possible but would mean creating another architecture build. I'm not sure there is a lot of interest in creating a suite of arm64EC hosts. I will place this in Future for consideration at a later time.

/cc @elinor-fung @richlander

[jozefizso]

When I think about it again, it may not make sense to have MS Office add-in in .NET built for ARM64EC as the host application can work with x64 libraries.

I don't have enough knowledge if ARM64EC based .NET runtime would increase the performance compared to x64 addins.

May be we need to wait for native ARM64 Office.

[jkotas]

I'm not sure there is a lot of interest in creating a suite of arm64EC hosts.

Arm64EC is x64 with perf optimizations for x64 emulation on Arm64..

The host is very small amount of code and there is very little time spent in it. Optimizing the emulation of the host by compiling it for Arm64EC would not move the needle.

It would have to be a complete runtime port to Arm64EC ABI. Multi-year project that we have said that we are not interested in pursuing.

[AaronRobinsonMSFT]

It would have to be a complete runtime port to Arm64EC ABI. Multi-year project that we have said that we are not interested in pursuing.

Oh right... I keep forgetting that it isn't just the entry point, but the whole stack that needs Arm64EC.

May be we need to wait for native ARM64 Office.

That is what I would assume at this point.

[AaronRobinsonMSFT]

See https://learn.microsoft.com/dotnet/standard/native-interop/abi-support#arm64ec.

[jozefizso]

How Microsoft thinks we will make apps for ARM platform when you will not support it?

[AaronRobinsonMSFT]

@jozefizso We do support ARM64, but not ARM64EC - which is a optimization that some applications take advantage of to avoid retargeting code. ARM64 itself is fully supported.

[AaronRobinsonMSFT]

Specifically for Office, VSTO is very limited with respect to .NET 5+. See the Note in the following VSTO link.