[Question] How .Net application with dependencies works in Arm64 runtime/environment?

[oblomingo]

Hey, I would like to get more information on how arm64 runtime works and how .Net application should be configured to get the best performance.

There is a .NET 7 self-contained WPF application with Arm64 platform. It works in most cases in Arm64 OS. The app has a lot of dependencies and I’m worrying about application performance.

I’m aware that it is possible to run x86 or x64 applications on Arm64 computer, but it is not optimized, performance is poor and the app drains the device’s battery.

Here is a dependency diagram:

As you can see the app depends on:

1. Nuget .NET packages from an official Nuget server.
2. Nuget .NET packages that depend on some unmanaged native dll from an official Nuget server.
3. .NET frameworks/runtimes:
   1. Microsoft.AspNetCore.App
   2. Microsoft.NETCore.App
   3. Microsoft.WindowsDesktop.App
4. Nuget .NET packages from a private Nuget server.
5. Nuget .NET packages that depend on some unmanaged native dll from a private Nuget server.
6. Native dll build from C++ project.

How these dependencies should be updated to work well with Arm64 application on Arm64 computer?

1. I’m confused and not sure what to do with Nuget packages. If they build without only for x86/x64 platform, does it mean that library code in emulated non-optimized mode? How to understand that Nuget package supports Arm64? Should I find a replacement Nuget package build for Arm64?
2. I guess in this case it would not work if native dll is not build for Arm64 architecture, am I right? Should I replace Nuget with another library?
3. Do the .NET frameworks have native Arm64 support?
4. In this case I’m able to add adjust Nuget packages. Should I add Arm64 configuration for Nuget solution build? Or should I do something more?
5. It seems I should build Arm64 version of native dll and update Nuget package.
6. I should build Arm64 version of native dll as well.

Could you please confirm or adjust my assumptions?
P.S. I'm not sure that this repository is the best place to ask these questions. Please let me know if there is a better place and I will move the issue.

[huoyaoyuan]

The general answer is, working just like how it works on x86/x64.

0. Specifically on Windows, x64 emulation is a process-wide compatibility feature. A process can either work in pure ARM64 mode, or work in ARM64EC mode and potentially load x64 code.

1. I’m confused and not sure what to do with Nuget packages. If they build without only for x86/x64 platform, does it mean that library code in emulated non-optimized mode? How to understand that Nuget package supports Arm64? Should I find a replacement Nuget package build for Arm64?

Most managed code are built for AnyCPU, not a combination of x86 and x64. You don't need to take any action for AnyCPU.

2. I guess in this case it would not work if native dll is not build for Arm64 architecture, am I right? Should I replace Nuget with another library?

If the whole process is ARM64EC, CLR and x64 native dependency will both be emulated. Otherwise, it depends on how it's distributed. Modern NuGet model counts architecture together with OS for native assets. The native dependency will be considered missing for win-arm64.

3. Do the .NET frameworks have native Arm64 support?

Yes.

4. In this case I’m able to add adjust Nuget packages. Should I add Arm64 configuration for Nuget solution build? Or should I do something more?

The "Platform" option of VS solution isn't friendly with modern NuGet asset model.

The modern model of native dependency in NuGet looks like this:

- package root
- libs
| - netX.0
  | Managed.dll (managed, AnyCPU)
| - runtimes
  | - win-x86
    | - netX.0
      ManagedPlatformDependent.dll (managed, x86, not recommended)
    | - native
      native.dll (native, x86)
  | - win-x64
    | - native
      native.dll (native, x64)
  | - win-arm64
    | - native
      native.dll (native, arm64)

For modern .NET you should pack your NuGet package like this. During dotnet publish of entry application, correct platform (win-arm64) will be selected for assets.

[huoyaoyuan]

In short, ARM64 isn't special comparing to xarch platforms. If you don't want to shift the packaging model, you can just add a third entry for ARM64 for anywhere you are listing both x86 and x64.

[oblomingo]

0. Specifically on Windows, x64 emulation is a process-wide compatibility feature. A process can either work in pure ARM64 mode, or work in ARM64EC mode and potentially load x64 code.

It seems ARM64EC works only in Windows 11, does it mean that in Windows 10 can be problems with loading x64 code?

Most managed code are built for AnyCPU, not a combination of x86 and x64. You don't need to take any action for AnyCPU.

I would like to clarify how it works under the water. The compilation process generates IL code, which is low-level and platform-independent (should it work in x86/x64 and Arm64?). Then .Net Arm runtime uses JIT compiler to compile native machine code which is executed directly by the CPU. If it works as I described, why do we need to specify platforms in a project file and runtime identifiers? Why do we need to build separate versions for x64 and native arm64?

For modern .NET you should pack your NuGet package like this. During dotnet publish of entry application, correct platform (win-arm64) will be selected for assets.

Do you mean runtime identifier? If I would like to use the same Nuget for both (x64 and arm64) builds. Do I need a separate Nuget package for both architectures? Or I could just define multiple runtime identifiers in the same project?

[oblomingo]

In short, ARM64 isn't special comparing to xarch platforms. If you don't want to shift the packaging model, you can just add a third entry for ARM64 for anywhere you are listing both x86 and x64.

Do you mean just add Arm64 platform in all Nuget projects?

[huoyaoyuan]

It seems ARM64EC works only in Windows 11, does it mean that in Windows 10 can be problems with loading x64 code?

x64 emulation on ARM64 starts from 21xxx build. So only Windows 11 has the emulation feature.

I would like to clarify how it works under the water. The compilation process generates IL code, which is low-level and platform-independent (should it work in x86/x64 and Arm64?). Then .Net Arm runtime uses JIT compiler to compile native machine code which is executed directly by the CPU.

Correct.

If it works as I described, why do we need to specify platforms in a project file and runtime identifiers? Why do we need to build separate versions for x64 and native arm64?

Sometimes the native interop code can be different due to incompatible data structures. But generally, all managed code should be AnyCPU as possible and shouldn't be built for separated architectures.

Do you mean runtime identifier?

Yes, modern .NET picks native assets based on runtime identifier.

If I would like to use the same Nuget for both (x64 and arm64) builds. Do I need a separate Nuget package for both architectures? Or I could just define multiple runtime identifiers in the same project?

Both options work. There are patterns that package named runtime.win-x64.SomePackage only contains native asset for win-x64. Putting all native assets in one NuGet package can simplify your management. It can also be in the same package of managed dll.
But the csproj/vcxproj system doesn't have a good support for this. You may have to pack them manually like this:

    <None Include="runtimes\**\native\*">
      <Pack>true</Pack>
      <PackagePath>runtimes</PackagePath>
    </None>

Do you mean just add Arm64 platform in all Nuget projects?

Yeah, if you are already using x64 for all projects, add a new arm64 configuration may be an easy workaround for you. It needs separated package id for each package though.

[oblomingo]

@huoyaoyuan thank you for the detailed reply!
However, since I'm not sure how to validate the correct Nuget setup, I would like to show what I got after code update:
A have added am ARM64 platform to the solution and .Net Standart 2.0 project (no any unmanaged code):
Solution.sln

...
{354B6E46-B4EB-4CBE-95E2-FE3C30DA676D}.Release|Any CPU.ActiveCfg = Release|Any CPU
{354B6E46-B4EB-4CBE-95E2-FE3C30DA676D}.Release|Any CPU.Build.0 = Release|Any CPU
{354B6E46-B4EB-4CBE-95E2-FE3C30DA676D}.Release|ARM64.ActiveCfg = Release|ARM64
{354B6E46-B4EB-4CBE-95E2-FE3C30DA676D}.Release|ARM64.Build.0 = Release|ARM64
{354B6E46-B4EB-4CBE-95E2-FE3C30DA676D}.Release|x64.ActiveCfg = Release|x64
{354B6E46-B4EB-4CBE-95E2-FE3C30DA676D}.Release|x64.Build.0 = Release|x64
{354B6E46-B4EB-4CBE-95E2-FE3C30DA676D}.Release|x86.ActiveCfg = Release|x86
{354B6E46-B4EB-4CBE-95E2-FE3C30DA676D}.Release|x86.Build.0 = Release|x86
...

Project.csproj:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
        <OutputType>Library</OutputType>
        <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
	    <RuntimeIdentifiers>win-x86;win-x64;win-arm64;</RuntimeIdentifiers>
	    <Platforms>AnyCPU;x64;x86;ARM64</Platforms>
    </PropertyGroup>
   ...
</Project>

CI builds Nuget package and pushed to private Nuget server:

dotnet build Solution.sln --configuration Release
...
nuget pack "$project" -properties Configuration=Release
...
nuget push "package.nupkg" -ApiKey $apiKey -Source https://private.nuget.server

Nuget package has only one dll file, there are no separate versions for x86, x64 and arm64.
Could you please confirm that the provided solution and project configuration are correct and the Nuget package will work well with .Net Arm64 application from the performance perspective?

[huoyaoyuan]

You can verify the content of NuGet package with NuGetPackageExplorer and the characteristics of dlls with ILSpy. Basically:

• Since no $(Platform) is specified in build command, it will use the default value AnyCPU for the solution.
• The solution file maps AnyCPU of solution to AnyCPU of each project.
• The packed nupkg will only contain AnyCPU dlls.

A have added am ARM64 platform to the solution and .Net Standart 2.0 project (no any unmanaged code):

$(Platform) of managed project is more for handy integration with vcxproj. If you are managing unmanaged code in another solution and not using #if for different architectures, you can remove all the platforms and just use AnyCPU only.

nuget push "package.nupkg" -ApiKey $apiKey -Source https://private.nuget.server

You can test nuget with local folder without pushing to any server. See https://learn.microsoft.com/en-us/nuget/hosting-packages/local-feeds .