Add arm64 as a possible WinForms arch

[hoyosjs]

Makes it possible to build/publish ARM64 WinForms apps.

• If an app tries anything requiring UseWPF it will fail as a build time scenario as there's no available runtime pack.
• Anything using UsingWindowsForms will correctly compile and run natively as long as all the references are in the assemblies produced by winforms.

cc: @merriemcgaw, @tommcdon

[tommcdon]

FYI @richlander

[dsplaisted]

Do we have a runtime pack for this yet?

Ideally I'd like to also add a basic test that this works.

[richlander]

There are at least three pieces we need:

• Ref pack for Windows Desktop. This is required to build, and should be in-box.
• Runtime for Windows desktop @ C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App. This is required for fx-dependent apps to run and should be in-box.
• Runtime pack for Windows desktop. This is required for self-contained publishing and should be referenced as a URL (not in box).

Will we have all of these after this PR merges?

[hoyosjs]

Do we have a runtime pack for this yet?

https://dnceng.visualstudio.com/public/_packaging?_a=package&feed=dotnet5&package=Microsoft.WindowsDesktop.App.Runtime.win-arm64&protocolType=NuGet&version=5.0.0-preview.6.20261.2

Ideally I'd like to also add a basic test that this works.

Yes, this I have to look how to do. Tom and I confirmed manually it worked but it would be good to actually confirm it works as expected. I'll take a look at the tree tomorrow to see where they are.

Ideally I could test these two:

• Winforms works on arm64
• Wpf errors as expected

Should I also open an issue to track the cleanup?

[wli3]

Are you blocked by this change? If not, I think we should checkin until the feature can work.

Yes, you should open an issue to track everything that is required for this feature to function.

[hoyosjs]

There's some loose ends here:

• Cleanup WindowsDesktop KnownFrameworkReferences once WPF adds ARM64 support #7466 tracking the cleanup for KnownFrameworkReference consolidation once WPF bits are in.
• Error out properly when building WPF on ARM64 app until support is added. #7467 tracking runtime failures with less than helpful messages for RID agnostic WPF builds running on an ARM64 machine.
• ARM64 WindowsDesktop Runtime pack's PlatformManifest is a superset of shipped assets windowsdesktop#770 tracking the incoherent manifests in the runtime pack.

• Ref pack for Windows Desktop. This is required to build, and should be in-box.
• Runtime for Windows desktop @ C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App. This is required for fx-dependent apps to run and should be in-box.
• Runtime pack for Windows desktop. This is required for self-contained publishing and should be referenced as a URL (not in box).
  Will we have all of these after this PR merges?

All three are done to some extent:

• The ARM64 zipped SDK has the WD ref pack under DOTNET_ROOT\packs\Microsoft.WindowsDesktop.App.Ref\<VERSION>\ref. @dsplaisted, is there a way to solve or warn about Error out properly when building WPF on ARM64 app until support is added. #7467 is targeting refs in the Wpf profile?
• The ARM64 zipped SDK has DOTNET_ROOT\shared\Microsoft.WindowsDesktop.App\<VERSION> after this. The assets contained are only the winforms ones. This causes one of the issues above.
• The runtime pack, albeit with the issues mentioned, is up in the dotnet5 feed. A win-arm64 publish on x64 pulls that package and I can marshal the self contained app and use it on a cobalt device and it runs as an ARM64 app and not under emulation.

[dsplaisted]

I would like to see a simple test case that we can build a self-contained Windows Forms app for ARM64 before merging this.

I don't think we need to address #7467 before merging this though.

[richlander]

I validated installing and using PowerShell today with this build: https://gist.github.com/richlander/d3521d2f8798405e1b5eb1d8e5805fbd

I did more than what is demonstrated there, but it still makes the point.

[vatsan-madhavan]

@fabiant3 please review.

[vatsan-madhavan]

/cc @dotnet/wpf-developers

[vatsan-madhavan]

• Ref pack for Windows Desktop. This is required to build, and should be in-box.

This should be easy enough to construct today in dotnet/windowsdeskop.

WPF produces ref-assemblies from x86 legs for both x86 and x64. In a future arm64 scenario, I would expect that WPF would continue shipping ref-assemblies from its x86 build-leg (ref-assemblies are built from special projects built as AnyCPU). The Microsoft.DotNet.Wpf.GitHub transport package contains everything needed for this already today (on .NET 5 only).

[vatsan-madhavan]

change itself lgtm 👍

[vatsan-madhavan]

#7467 (comment)

That gave me an an idea about another potential missing piece for completing #7457 - an arm64 compatible version of Microsoft.NET.Sdk.WindowsDesktop - which is needed to even build WinForms apps.

Here by "compatible" I mean two different things - (i) can target arm64 successfully and (ii) can run on arm64 successfully. When scoped to UseWindowsForms==true && UseWpf==false No. (i) might be free, but needs validation/testing. No. (ii) may also be free (i.e., the SDK might just work though I'm less sure of it). When UseWpf==true=, no. (i) might just work for free, but (ii) would need some work (PresentationBuildTasks.dll` may or may not need arch-specific work).

[hoyosjs]

Added a test doing rid specific publishes, where WinForms succeeds but WPF fails

[hoyosjs]

Also tested a simple WinForms app from the samples repo as self-contained and framework dependent on a win-arm64 device:

[richlander]

[merriemcgaw]

lgtm

[wli3]

Although we need a separate change in dotnet/SDK to generate a better error message. This current error message is cryptic for the customer. And they should know it is a restriction from the platform, and there is nothing they can do to make it work.

[wli3]

Let me know if you don't have the access to merge this PR. I can merge it

[hoyosjs]

I don't have access to it. However someone from @dotnet/wpf-developers (I think Vatsan said @fabiant3) should make sure they know how this can impact. Once this is done, I'm happy to merge. Thanks @wli3

[richlander]

My ask: Can you merge this PR by EOD Monday, if at all possible? That would help me a lot.

[hoyosjs]

@msftbot please merge this in an hour.

Talked with @richlander and this has been acknowledged by the WPF team. Giving some time in case anyone in their team wants to add a review.