Enable running in ARM64-native mode on .NET Framework.

[teo-tsirpanis]

Fixes dotnet/runtime#104548.

This PR updates app.manifest to add the newly introduced supportedArchitectures element. This enables Roslyn to run in native ARM64 architecture when running on .NET Framework (for example in builds inside Visual Studio), and on Windows 11 24H2+.

[ViktorHofer]

cc @jaredpar as we talked about this on Teams

[jaredpar]

on Windows 11 24H2+.

Do we have any data on what happens when this is run on a lower version of Windows?

[jaredpar]

Need to resolve:

• What happens on x86 architectures?
• What happens on older OS when this entry is added to the manifest.

[teo-tsirpanis]

• What happens on x86 architectures?

  • Windows 11 does not support x86, if that's what you mean.

• What happens on older OS when this entry is added to the manifest.

  • Just compiled a simple C++ program with a custom manifest that has this entry and it runs fine on Windows 11 23H2.

[jaredpar]

Windows 11 does not support x86, if that's what you mean.

The compiler runs on many different OS. Pretty much any OS still in support.

[akoeplinger]

@jaredpar I tested on Windows 10 and the entry is ignored there.

[jaredpar]

@jasonmalinowski PTAL. This would be injected into pretty much any .NET Framework EXE in our repo which includes msbuild host and guessing other IDE items. This is safe as long as the EXE are ARM64 compatible (not relying on emulation to AMD64 to execute). That should be the case unless it is doing any PInvoke or arch specific interop code. I can vouch for the compiler exes but need IDE to take a look for theirs.

[jaredpar]

@dotnet/roslyn-compiler PTAL

[jasonmalinowski]

@jaredpar I can't think of an obvious problem here. Going through various processes we ship:

1. ServiceHub (our OOP process): you changing the manifest won't impact that, but we already run this on arm64.
2. LSP language server: we already run on arm64.
3. MSBuildWorkspace's build host process: one or two P/Invokes for the Linux/Mac case only. And we already are running that on macOS arm64 so architectural screwups (like some code assuming certain endianness) won't be a problem.
4. LSIF indexer: all managed code, and not currently being ran anywhere on arm64 no matter what.

If the following scenario is also legal I could imagine this might break:

1. Windows arm64 device.
2. .NET runtime (NOT SDK) installed for arm64 and x64.
3. .NET SDK installed only for x64
4. VS Code installed with an x64 flavor, which was running under emulation.
5. The x64 C# extension.

If the build host and LSP server were running under x64 runtimes, then this might all work. But if the build host then now runs as native arm64, the lack of SDK for that platform might break it. The user of course should just install the arm64 SDK too. 😄

[jasonmalinowski]

Tagging @dibarbet if he has any other ideas.

[jasonmalinowski]

@jaredpar pointed out I was forgetting this change only applies to .NET Framework, so my concern about say VS Code doesn't matter since that's all .NET Core and doesn't care. So we're probably fine.

[huoyaoyuan]

I see PreferNativeArm64 in SDK: https://github.com/dotnet/sdk/blob/f5b2382c2953925917efaf7bde8821d6d4501aab/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.props#L116
maybe we can use this property in the future.