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.

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)

@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?

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.

@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?

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.

Consolidated all required changes in #47290.

Thanks for additional details, @lextm. At this point we don't have enough signal to justify increasing our support matrix, as this will result in higher support cost. Hence, we're going to park this in the backlog and monitor to see how community reacts to this over time.
Having said that, I will close your PR for now. Thanks again for your effort and suggestions.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

@mkArtakMSFT Thanks for the transparency.

Before enough needs are revealed, any users can apply the workaround I found in https://github.com/lextm/ancm-arm64 instead.

This is very disappointing to hear... For anyone who is developing for .NET on a newer Macbook Pro instead of other inferior laptops, we have to run Windows 11 Preview for ARM in Parallels or VMWare. For simple setups some devs can get away with using IIS Express, but many of us require IIS and run into the dreaded "The current configuration only supports loading images built for a AMD64 processor architecture" error when running our ASP.NET Core applications. We were fortunate enough to find @lextm's github repo and apply his patches, but it would be great if Microsoft would reconsider supporting this scenario so that we can develop for .NET on Macbook Pro's without patching your ASP.NET Core dll's. And no, we can't develop directly on Mac, our applications use functionality that is only available on Windows such as SQL Server, Event log, Windows impersonation, and Windows Services.

It's 2024 and IIS is still not working correctly on ARM64. In the meantime, to unblock migration to ARM64 (some apps rely upon IIS), I've built an unofficial installer on top of @lextm fixes (thank you very much!!!) which you can find here. It is not suitable for production, but it makes it easier to deploy the workaround for the time being and it can be used for development and prototyping as a temporary replacement of the official Hosting Bundle.

@jimm98y ASP.NET Core module versions are associated with other ASP.NET Core bits in manifest files. Tools like JexusManager depend on such mappings to find potential issues in deployment.

Your own installers often got a different version number from the official one (timestamp related) and might break such detection. So overall I don't think that is a good idea to host your own installers.

@lextm That's why I only broke down the official bundle and re-used all the officially released bundle components, not trying to patch the MSI/EXEs inside the bundle and using scripting instead. I agree it has multiple drawbacks and in no way can it replace the official installers => I removed the released MSI.

We'll probably end up moving our ASP.NET Core app out of IIS to run on Kestrel and use Url Rewrite in emulation instead. However, we can't guarantee the user won't install any other ARM64 IIS integrated app alongside ours and at that point IIS will break.

Can https://github.com/lextudio/httpplatformhandlerv2/releases be used to install this patch on top of existing IIS Hosting Bundle installation?

@jimm98y The HttpPlatformHandler v2 repo was created for a completely irrelevant goal, so it cannot help.

@mkArtakMSFT I hope you reconsider. As a developer I purchased a new MacBook to create cross platform apps specifically with MAUI. Many developers are moving to new MAcBooks with Windows VM to develop. Frankly I would have used VS for MAC, but that is another disappointment and the reason for using a VM. Just looking for the tools I need to do my job.

This is a bit ridiculous. The amount of time spent commenting in this thread probably took longer than it would have taken just to implement the @lextm script fix.

I feel that this decision is more of a marketing strategy than anything developer-related. Currently I (and anyone else in this situation) have to run the @lextm patch every time asp modules get updated, which seems to be every VS Studio update and every other Windows Update.

Does MS just not value ARM development that much? It just seems odd that the effort has been put into creating ARM versions of Windows that then get hamstring'd by little issues like this.

Thanks for additional details, @lextm. At this point we don't have enough signal to justify increasing our support matrix, as this will result in higher support cost. Hence, we're going to park this in the backlog and monitor to see how community reacts to this over time. Having said that, I will close your PR for now. Thanks again for your effort and suggestions.

Good that you mention higher costs, because I really think the cost of Windows ARM failing again will be much higher than the cost of fixing and supporting this use case. No, I don’t think this is critical, but the more apps can run unchanged in Windows ARM the better!

Just reminding that Microsoft launched the first Windows on ARM in the Surface tablet in 2012 and it completely failed to gain traction as there was not really any app that would run on that besides the few ones available on the Windows store at that time.

I believe one of the lessons learned is you do need compatibility so more apps can run on Windows ARM unchanged until the platform gains enough traction for developers/isvs to feel compelled to adapt/recompile their apps for the new platform.

Finally, I know pure ASPNET core apps can potentially be targeted to ARM with ease but there are countless apps on the market that rely on unmanaged components that are x64 only so they do need to be executed as x64.