ASP.NET Core module installer should be improved further for Windows ARM64

[lextm]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

The current installer (.NET 7 for example) does the following on Windows 11 ARM64,

1. Install pure ARM64 build of the files to Program Files.
2. Install pure ARM64 build of the files to Program Files (x86).

So, if people try to create three application pools on IIS for ARM64, x64, and x86, they can only get things running in the ARM64 pool (enableEmulationOnWinArm64 set to false and enable32BitAppOnWin64 set to false). All other pools will crash.

Describe the solution you'd like

The changes should be made are,

1. Install x86 build to Program Files (x86), which resolves x86 application pools.
2. Compile pure forwarders aspnetcorev2.dll and aspnetcorev2_outofprocess.dll and install them along with arm64/x64 bits to Program Files. This resolves both in-process and out-of-process modes for arm64/x64 application pools.

Note that an alternative way is to compile ARM64X builds of both aspnetcorev2.dll and aspnetcorev2_outofprocess.dll and install to Program Files. However, it raised many challenges and needs further investigation.

This should allow all three kinds of application pools to run properly and maximize compatibility.

A all-in-one pull request is currently opened, #47290.

Note that #47124 is no longer needed.

Additional context

I tried to build ASP.NET Core module with a ARM64X profile, but found quite a few hurdles (changes to compiler settings, extra defines and missing files to include). I guess that's why this hasn't been finished in .NET 7 timeline.

Hope it can be done in .NET 8 to complete Windows ARM64 support.

[lextm]

Building ASP.NET Core module with a ARM64X profile seems to be unnecessary. ARM64X has the concept of "pure forwarder DLL" so that two forwarder DLLs (one for in-process and the other for out-of-process) should be enough to integrate the existing ARM64/x64 binaries with IIS on Windows 11 ARM64.

[lextm]

The proposed new folder structure is as below,

• Under C:\Program Files\IIS\Asp.Net Core Module\V2

  • aspnetcorev2.dll (pure forwarder)
  • aspnetcorev2_x64.dll (from x64 machine C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll)
  • aspnetcorev2_arm64.dll (original aspnetcorev2.dll from ARM64 installation)

• Under C:\Program Files\IIS\Asp.Net Core Module\V2\17.0.23030

  • aspnetcorev2_outofprocess.dll (pure forwarder)
  • aspnetcorev2_outofprocess_x64.dll (from x64 machine C:\Program Files\IIS\Asp.Net Core Module\V2\17.0.23030\aspnetcorev2_outofprocess.dll)
  • aspnetcorev2_outofprocess_arm64.dll (original aspnetcorev2_outofprocess.dll from ARM64 installation)

[mkArtakMSFT]

@joeloff do you know what were the historical reasons for the current approach?
Are these limitations expected and do you think there is anything we can do about them?

[joeloff]

Historically, the hosting bundle carried both x86/x64 bits and by default installed both on an x64 machine, unless the user passed additional options to select what was installed. The idea was to support multiple hosting scenarios where servers either supported dedicated pools for x64/x86 on separate machines or on the same machine. Additionally you could opt out of installing the runtime and only install ANCM. This was to support hosting environments for self-contained .NET applications.

The bundle can carry x86, x64, and arm64 content. .NET supports installing both x64/arm64 SxS, but I don't know whether ANCM currently supports that. You would need to make changes to the MSI to avoid the x64/arm64 copies stomping on each other since both would share the same location. In .NET we do this by modifying the install location so that x64 on arm64 installs to Program Files\dotnet\x64. You'd need something similar if you wanted to support 3 application pools.

It all depends on what you want your supported scenarios to be and what IIS supports as well.

[wtgodbe]

@HaoK I believe you did the work to support arm64 - do you remember what the goal/design was for ANCM x64/arm64 side by side?

[lextm]

With some help from ARM64 Process Monitor, I successfully resolved the out-of-process crash.

So, by patching the current installer, it is possible to get ARM64/x64/x86 application pools working on Windows 11 ARM64 side by side properly. I created a separate repo to show the exact steps to patch the default installation,

https://github.com/lextm/ancm-arm64

In short, the steps are,

1. Prepare AMR64X pure forwarders with build.cmd.
2. Extract the actual ANCM x64 MSI package with WiX Toolset dark.exe.
3. Copy forwarders to the right locations.
4. Copy/rename ARM64/x64 files to the right locations (main files (aspnetcorev2_*.dll) in Program Files, out-of-process files (aspnetcorev2_outofprocess_*.dll) to IIS installation folder).
5. Override the broken x86 files (not needed once Fix x86 folder contents in ARM64 Windows Server Hosting Bundle installer #47124 is accepted and merged).

Note that I have to copy out-of-process files to IIS installation folder right now, as LoadLibrary in HandlerResolver.cpp does not work very well with out-of-process pure forwarder. The function call does not load the actual ARM64/x64 library from the forwarder folder, but from system paths.

If #47290 can be accepted and merged, then the out-of-process files can be moved back to Program Files.

I tested the patch.ps1 and restore.ps1 scripts with .NET 7.0.4 and they work for me with an ASP.NET Core 7 MVC test app published as self-contained.

It is up to you how to incorporate the findings into the hosting bundle installer.