Finalize ARM64 support (Installers, publishing-rid, revert winforms support)

[hoyosjs]

@wli3 @marcpopMSFT @sfoslund this is the PR I folded the other one into. It's still in draft as I'm testing but I wanted some feedback.

• Enable Win-ARM64 as a possible RID for ASP.NET core
• ARM64 bundled installer

I've excluded the following assets from the ARM64 installer. Are these ok?

• There are no alternate architecture hosts MSIs available. I've excluded those.
• There is no ARM64 targeting pack available for .NET standard. I'd have to do this from a servicing branch and it wasn't very straightforward. Would these get downloaded as NuGet packages if not available in-box?
• It was decided to revert WinForms Win-ARM64 support until WPF is ready.

[hoyosjs]

Also ignore the changes in Versions.props. These are to test while ASP flows an official version of the ARM64 assets (dotnet/aspnetcore#25579)

cc: @tommcdon

[hoyosjs]

Related to #7985

[hoyosjs]

Official test build with versions.props changed backed out to test shipping bits: https://dev.azure.com/dnceng/internal/_build/results?buildId=811915&view=results

[sfoslund]

LGTM but I don't have a deep understanding in this area. @joeloff do you mind reviewing too?

[joeloff]

@sfoslund I'm looking at it

[hoyosjs]

@richlander

[hoyosjs]

I've excluded the following assets from the ARM64 installer. Are these ok?

• There are no alternate architecture hosts MSIs available. I've excluded those.
• There is no ARM64 targeting pack available for .NET standard. I'd have to do this from a servicing branch and it wasn't very straightforward. Would these get downloaded as NuGet packages if not available in-box?
• It was decided to revert WinForms Win-ARM64 support until WPF is ready.

@richlander @wli3 @sfoslund Are these OK? Both from a product perspective as well as a technical perspective? I am still not familiar with when things get downloaded on the fly or not.

[sfoslund]

Are these OK? Both from a product perspective as well as a technical perspective? I am still not familiar with when things get downloaded on the fly or not.

I don't see a problem from the technical perspective.

[kelxshady]

Good ❤️

[hoyosjs]

@marcpopMSFT given this is for RC2, who'd be the right M2 to ask for this to be considered by tactics?

[marcpopMSFT]

@hoyosjs The sdk is on the VS schedule for approvals and so doesn't need M2 signoff yet. This is a significant enough change though that it's worth mentioning to tactics as an FYI.

[marcpopMSFT]

@hoyosjs @joeloff I gave tactics a heads up on this change. Is there anything left we need to cover before we can merge this and get testing on the official signed installer?

CC @jeffhandley who expressed interest in testing and @tommcdon who's been engaged with the arm64 work on the runtime side.

[jeffhandley]

@hoyosjs If you can provide a link to the signed installer, I'll relay it to my team and some folks will try it out. Several people on the Libraries team have ARM64 devices and have been dogfooding.

[hoyosjs]

Further testing done:

• Verified the official x64/x86 installer sets the same registry keys before and after the change. They also end up with the same tree structure.
• Spot checking a few assemblies, contents are properly signed and have been crossgened as arm64.
• Contents match x64 with these exceptions:
  • Only has Microsoft.NETCore.App.Host.win-arm64 (there's no other MSIs for alternate hosts on arm64)
  • No NETStandard or WindowsDesktop ref in-box. The first one has no arm64 msi, the latter is not supported yet.
  • No WindowsDesktop sharedfx, as WPF isn't ready.
  • UCRT dlls are missing - opened ARM64 Runtime Packs and shared FX missing UCRT binaries runtime#42287 to confirm if this is expected.
• Side by side x86/arm64 works.
• Built and published the following:
  • Simple console app.
  • Simple ASP.NET webapi and mvc apps.
  • WinForms/WPF apps - builds/publish rid agnostic by downloading the ref pack but won't publish for ARM64 (expected as it's decided as an unsupported scenario until WPF ships arm64 bits).
  • Simple netsandard2.0 lib builds by downloading the ref pack (We couldn't add it inbox as the infrastructure wasn't available in 5.0 anymore).

Bugs I noticed:

• It reports WinForms was installed. This is a localized resource so I'd need to change all the string resources or compile them conditionally.
• DOTNETHOME seems empty on arm64. Investigating this.

People who might care about this: @safern, I know you have the Surface X. @jeffhandley

https://dev.azure.com/dnceng/internal/_build/results?buildId=811915&view=results has builds that can be tested in the artifacts.

@richlander are these experiences, plus the ones describing what's available in-box acceptable for now?

[joeloff]

@hoyosjs The UI strings are static. And they're referenced from the theme.xml that defines the screens. You can condition the string by adding both strings to the UI, but then set the visibility property on a known property that would only be available if your arm64/x64.

You would effectively duplicate this line

installer/src/redist/targets/packaging/windows/clisdk/bundle.thm

Line 73 in df2d100

<Richedit Name="SuccessInstallHeader" X="160" Y="81" Width="-12" Height="-71" FontId="5" HideWhenDisabled="yes">#(loc.FirstTimeWelcomeMessage)</Richedit>

But give it different names: SuccessInstallHeader and SuccessInstallHeaderArm64 and define two strings

<Richedit Name="SuccessInstallHeader" X="160" Y="81" Width="-12" Height="-71" FontId="5" HideWhenDisabled="yes">#(loc.FirstTimeWelcomeMessage)</Richedit>
<Richedit Name="SuccessInstallHeaderArm64" X="160" Y="81" Width="-12" Height="-71" FontId="5" HideWhenDisabled="yes">#(loc.FirstTimeWelcomeMessageArm64)</Richedit>

And in the bundle, define the variables with the same name as the UI controls.

<?if $(var.Platform)=arm64?>
<Variable Name="SuccessInstallHeaderArm64" Value="1"/>
<?else?>
<Variable Name="SuccessInstallHeader" Value="1"/>
<?endif?>

This ensures that only one of the two controls is active in the UI.

[hoyosjs]

@joeloff the problem with that approach is we end up with the success message on uninstall overlayed with the uninstall header. (The success page always has SuccessInstallHeader`SuccessInstallHeaderArm64` set to enabled so it always renders them). This is the only thing left. I tried a that and conditionally compiling with the preprocessor, but neither worked. If I can't think of anything else, we should merge this to make sure we include it in RC2.

[kelxshady]

Ok

[joeloff]

@hoyosjs ideally you want to condition the variable on something like WixBundleAction, but bundles don't support conditionals, except if you set the variable, then override it through a registry search, which would complicate things significantly

A simpler approach is to create an ARM64 version of the theme file. It can be an exact copy and share the .wxl file, except we swap out the one string. Once WPF/WinForms are supported, we flip back to a shared theme file.

[hoyosjs]

@joeloff that worked nicely enough. Thanks!

[joeloff]

@hoyosjs glad to hear the theme change worked. I think if this build is green we should merge

[hoyosjs]

@hoyosjs glad to hear the theme change worked. I think if this build is green we should merge

Yeah, that's about as much manual testing as I can think of to catch potential issues here.