[Reopen] Fix ANCM installer on ARM64

[lextm]

Revised ASP.NET Core module installers for Windows ARM64

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

• Switch to LoadLibraryEx with LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR flag set, so that the pure forwarder works as desired.
• Add ARM64X pure forwarders.
• Revise WiX installers to use ARM64X pure forwarders

Fixes #47115.

Description

About the change in HandlerResolver.cpp

To implement all proposed installer changes in #47115, then in the out-of-process folder three files present,

1. aspnetcorev2_outofprocess.dll, an ARM64X pure forwarder.
2. aspnetcorev2_outofprocess_arm64.dll, the pure ARM64 handler.
3. aspnetcorev2_outofprocess_x64.dll, the x64 handler.

Before this change, LoadLibrary only loads the pure forwarder, but then scans the default folders (the dll folder is not included) to load the actual handler which obviously fails.

After this change, LoadLibraryEx can pick up the correct handler as the dll folder is added in the search folder list.

About files in Forwarders folder

Source code for the two ARM64X pure forwarders.

About changes in ANCMV2 folder

Before this change, only ARM64 web apps can run on IIS.

After this change, the new file structure enables ARM64/x64/x86 side by side execution on IIS.

About changes in ANCMIISEXpressV2 folder

Before this change, only ARM64 web apps can run on IIS Express.

After this change, the new file structure enables ARM64/x64/x86 side by side execution on IIS Express.

[wtgodbe]

@halter73, can you confirm your local testing showed that this patch worked as expected?

[halter73]

Thanks for reopening your PR @lextm! Your work has been very helpful.

can you confirm your local testing showed that this patch worked as expected?

Yes. I can verify that the patch worked as expected at least for the in-process handler when publishing apps targeting ARM64 (already worked), x64 and x86. More importantly, it didn't crash on app pool startup. I plan on verifying out-of-process scenarios as soon as we get a build.

I was a little surprised to see the PR included the runtime change to call LoadLibraryEx considering the patch seemed to work well in my testing without any runtime changes. As far as I can tell the patch only copies dlls from the msi to the correct install location, but maybe I didn't test the scenario that is fixed by this part of the change. @lextm Can you explain exactly what is fixed by expanding the handler library search path to include the current dll folder? Do I need to test out-of-process hosting to see the difference it makes?

@BrennanConroy Can you also take a quick look to verify this makes sense?

[lextm]

@halter73

Question 1: Can you explain exactly what is fixed by expanding the handler library search path to include the current dll folder?

Let's review the actual folder structure to see why:

Windows x64

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

  • aspnetcorev2.dll (x64 main extension dll)

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

  • aspnetcorev2_outofprocess.dll (x64 out-of-process dll)

In this case, if we use LoadLibrary in aspnetcorev2.dll to load aspnetcorev2_outofprocess.dll with its full path, everything works fine.

Windows ARM64

Like I proposed in this pull request, the folder structure is changed as follows

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

  • aspnetcorev2.dll (pure forwarder)
  • aspnetcorev2_x64.dll (x64 main extension dll)
  • aspnetcorev2_arm64.dll (ARM64 main extension dll)

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

  • aspnetcorev2_outofprocess.dll (pure forwarder)
  • aspnetcorev2_outofprocess_x64.dll (x64 out-of-process dll)
  • aspnetcorev2_outofprocess_arm64.dll (ARM64 out-of-process dll)

If we keep using LoadLibrary in aspnetcorev2_x64.dll or aspnetcorev2_arm64.dll to load aspnetcorev2_outofprocess.dll, then this API only loads the pure forwarder. When the bitness specific dll is being searched by LoadLibrary, it goes through the default paths, but those don't include C:\Program Files\IIS\Asp.Net Core Module\V2\17.0.23030.

Question 2: Do I need to test out-of-process hosting to see the difference it makes?

Yes, you need to test out-of-process hosting in order to see the difference LoadLibraryEx makes. With LoadLibrary you should get a file not found error, while with LoadLibraryEx the bitness specific dll is properly loaded.

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.