Consider removing the `win-arm` RID from the RID graph

[baronfel]

Today we expose the win-arm RID in the portable RID graph, which allows users to target that RID, as well as author and distribute assets for that RID. However, we don't ship an AppHost (and likely other critical assets) for this RID, so users that attempt to target it have a poor experience. Here's an example:

E:\..\..\win-arm-demo> dotnet new console
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring E:\Code\Scratch\win-arm-demo\win-arm-demo.csproj:
Restore succeeded.

E:\..\..\win-arm-demo> dotnet build --arch arm --os win
C:\Program Files\dotnet\sdk\9.0.200-preview.0.24575.35\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'win-arm'.
C:\Program Files\dotnet\sdk\9.0.200-preview.0.24575.35\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'win-arm'.
C:\Program Files\dotnet\sdk\9.0.200-preview.0.24575.35\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'win-arm'.
C:\Program Files\dotnet\sdk\9.0.200-preview.0.24575.35\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'win-arm'.

Restore failed with 4 error(s) in 0.4s

E:\..\..\win-arm-demo> dotnet build --arch arm --os win -p:UseAppHost=false
Restore complete (0.3s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  win-arm-demo succeeded (2.1s) → bin\Debug\net9.0\win-arm\win-arm-demo.dll

Build succeeded in 2.8s

Do we want to allow targeting this old RID? A while back we said that we dropped support for it.

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

Agreed, NETSDK1083 would be a much better experience if a developer tries to target win-arm. I think we can just remove it from:

runtime/src/libraries/Microsoft.NETCore.Platforms/src/PortableRuntimeIdentifierGraph.json

Lines 460 to 463 in 696c8b0

	"win-arm": {
	"#import": [
	"win"
	]

Would need to make sure NETSDK1206 won't end up unintentionally triggered for packages. I think we only check OS, not architecture, so it should be okay.

[elinor-fung]

Manually validated that removing win-arm from PortableRuntimeIdentifierGraph.json in a downloaded SDK:

• results in NETSDK1083 when building for win-arm
• does not result in NETSDK1206 when referencing a package with win-arm assets

[xtqqczze]

Do we want to allow targeting this old RID? A while back we said that we dropped support for it.

We are NOT dropping Linux Arm32 with .NET 9. It will be supported. There are no plans to revisit this decision.

Originally posted by @richlander in #71042 (comment)

[elinor-fung]

Do we want to allow targeting this old RID? A while back we said that we dropped support for it.

We are NOT dropping Linux Arm32 with .NET 9. It will be supported. There are no plans to revisit this decision.

Originally posted by @richlander in #71042 (comment)

Yes, this is only about Windows arm32 (win-arm). Linux arm32 support remains.

I think that sentence was referring to this from the description in that discussion:

We dropped support for Windows Arm32 some time ago.

[richlander]

Agreed. This proposal is specfic to Windows. I also think that removing this entry from the RID graph is a good idea, for the reasons given.