[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.

[halter73]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[halter73]

I ran a non-PR build against this branch, so I could test the updated hosting bundle on an arm64 machine myself. Unfortunately, I got a build error due to this file missing. And there's a similar error for aspnetcorev2_outofprocess.dll below.

##[error]src\Installers\Windows\AspNetCoreModule-Setup\ANCMIISExpressV2\ancm_iis_expressv2.wxs(171,0): error LGHT0103: (NETCORE_ENGINEERING_TELEMETRY=Build) The system cannot find the file 'D:\a_work\1\s\artifacts\bin\AspNetCoreModuleForwarders\aspnetcorev2.dll'.

https://dev.azure.com/dnceng-public/public/_build/results?buildId=908627&view=results

I started a new build at https://dev.azure.com/dnceng-public/public/_build/results?buildId=909937&view=results with the binlog enabled. I can look more into this tomorrow, but I posting this now in case @wtgodbe or @lextm has any insights that could save me time.

[lextm]

I left a comment in AncmV2.wixproj to indicate how such dll files (pure forwarders) are generated in the workflow, so you might take a look there.

[lextm]

@halter73 The forwarder dll files are generated by this target. You might review MSBuild binlog to see why it wasn't triggered when you built the artifacts. I guess it was caused by condition mismatch.

[halter73]

Could it be that this BeforeBuild target is simply missing from AncmIISExpressV2.wixproj? I tried pushing to the lextm-47290 branch at [email protected]:lextudio/httpplatformhandlerv2.git to update this PR and test it, but I got a permission error.

[lextm]

En, I didn't add this target to AncmIISExpressV2.wixproj because not necessary if building everything out. But like you found out, if just building a few projects (not the entire solution) then that missing target can be a problem and lead to missing files during ANCM IIS Express installer builds.

I just pushed a new commit as you suggested addressing this.

[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.

[halter73]

Suggested change

	hRequestHandlerDll = LoadLibraryEx(handlerDllPath.c_str(), nullptr, LOAD_LIBRARY_SEARCH_DEFAULT_DIRS | LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR);
	hRequestHandlerDll = LoadLibrary(handlerDllPath.c_str());

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)

...

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.

I've tried to reproduce the file not found error after reverting this change to HandlerResolver, but I'm unable to.

I've tried various combinations of out-of-process publish targets including portable, win-arm64, win-x64 and win-x86 with and without setting both "Enable 32-Bit Applications" and "Enable Emulation on ARM64" on the app pool. In every case, it appears to load just aspnetcorev2_outofprocess.dll and work just fine. It never loads aspnetcorev2_outofprocess_x64.dll or aspnetcorev2_outofprocess_arm64.dll after the revert, but it makes sense to me that for out-of-process scenarios, the handler and webapp bitness don't need to match.

DLLs loaded with LoadLibraryEx change

DLLs loaded without LoadLibraryEx change (reverted)

As you can see from these procmon screenshots of dlls loaded by w3wp, if I revert the LoadLibraryEx change, only aspnetcorev2_outofprocess.dll gets loaded and not aspnetcorev2_outofprocess_x64.dll even when "Enable Emulation on ARM64" is set for the running app pool. Fortunately, this doesn't make a difference even for apps that are published targeting win-64.

You can try it yourself by grabbing the "Windows_HostingBundle" from https://dev.azure.com/dnceng-public/public/_build/results?buildId=925824&view=artifacts&pathAsName=false&type=publishedArtifacts

Am I missing any steps necessary to reproduce the file not found error?

If we cannot reproduce it, I think we should revert to the old LoadLibrary that only searches the default dirs. It's usually best not to change more than we have to. I think this also means we can get rid of both aspnetcorev2_outofprocess_x64.dll and aspnetcorev2_outofprocess_arm64.dll.