Fix ASP.NET Core module installer upgrade issues

[lextm]

Fix ASP.NET Core module installer upgrade issues

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

Summary of the changes (Less than 80 chars)

• Add version numbers to ARM64X pure forwarder compilation.
• Revise WiX installer component/file relationship to ensure upgrade is possible.

Description

Initial PR #59483 left a few issues unresolved and led to #60764.

Changes in ancm_iis_expressv2.wxs and aspnetcoremodulev2.wxs

The previously introduced new components AspNetCoreModuleV2.forwarder and AspNetCoreModuleHandler.forwarder can confuse Windows Installer, and caused files like aspnetcorev2.dll to be mistakenly removed during upgrades from .NET 7/8/9.

Here they have been removed and the new files are conditionally included in previously existing components AspNetCoreModuleV2 and AspNetCoreModuleHandler.

Changes in all.cmd/build.cmd and build.proj

Previously the pure forwarder dlls were not built with version information. That confused Windows Installer when it tried to compare files like aspnetcorev2.dll with previous installed versions.

Here we ask the linker to use .res files that were used to build the x64 builds of related .dll files. This ensures that pure forwarders have the same version information as well as other metadata.

Fixes #60764

[Copilot]

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

[lextm]

Tested with IIS Express and IIS. This pull request is now ready for further review.

[joeloff]

File@DiskId="1" and File@Vital="yes" are the defaults, there are probably more of these to clean up

[joeloff]

The general rule for components is one file/reg key per component. When performing repairs, the keypath of the component is used to determine its state and whether it needs to be reinstalled during a repair. If non-keypath items are missing or damaged, repairs my not necessarily work. It's likely repair will write the registry keys again since WiX by default will set the reinstall mode to include registry keys. Just calling it out in case this is an issue.

[joeloff]

You should consider setting the File@KeyPath="yes". If child elements of a component do not have a keypath set, and the parent directory of the component is not a key path, then the first child is selected. In this case, it would be the file. However, if you modify the order, the key path will change. Setting it explicitly will avoid issues in the future.

This might be a good read: https://learn.microsoft.com/en-us/windows/win32/msi/what-happens-if-the-component-rules-are-broken

[joeloff]

@wtgodbe once this is merged, I'd suggest doing a full setup test pass on multiple scenarios including

• Clean install
• Upgrade (8+10+9)
• Include Repair/Uninstall tests for the scenarios above
• Double check what happens with success blockers. In this case, install 10.0.0-preview.2 and then install 10.0.0-preview.1 Success blockers bypass the downgrade check at the bundle level, allowing it to run. The MSI though should not get executed.

[halter73]

@joeloff Since you approved the PR and your suggestions seem like style improvements, I'm going to merge it as-is to make it easier to get started manually testing upgrade scenarios.

Let me know if any of these suggestions are important enough to warrant a quick follow up PR or tracking issue to look at more holistically across all our .wxs files.

[joeloff]

They're not style suggestions.