Add ARM64 as a supported architecture

[tommcdon]

Visual Studio Version: 16.8

Summary: .NET 5 is adding support for Windows ARM64. Visual Studio .NET Core projects should allow you target ARM64 in addition to x86/x64/arm32.

Steps to Reproduce:

1. Create a .NET Core Console / Unit Test / ASP.NET Core project

2. Under Project properties, Build, you should be able to select "ARM64" as a target architecture

[jjmew]

The project system get this information directly from the SDK

[davkean]

This is controlled by <AvailablePlatforms> property which is provided by us from the build.

[jjmew]

@davkean I thought you said it came from the SDK. I am confused now, on what it will take to show x64. Should the template automatically add ARM64 to the and burn it to the project file?

[davkean]

The SDK is the build, I was just adding context to the bug.

[tommcdon]

@hoyosjs

[hoyosjs]

Is it this one?

msbuild/src/Tasks/Microsoft.Common.CurrentVersion.targets

Line 63 in f2c4bfd

<AvailablePlatforms Condition="'$(VisualStudioVersion)' != '' and '$(VisualStudioVersion)' > '10.0'">Any CPU,x86,x64</AvailablePlatforms>

I'd set it locally to verify directly on the SDK, but I still don't get a configuration available.

[dsplaisted]

I think the configuration manager is something else. This bug is referring to the Platform Target in the project properties:

I can confirm that modifying the AvailablePlatforms property does add items to this dropdown (though it's not easy to do so because it is set in the common targets).

[ryalanms]

/cc @dotnet/wpf-developers

[predavid]

@dotnet/sdk - when will the ARM64 option be made available in the Platform Target drop-down?

[tommcdon]

@tmeschter

[marcpopMSFT]

@benvillalobos check with Daniel on what are the risks of us updating the AvailablePlatforms in common targets. @tommcdon , are there any restrictions on when to show ARM64 and ARM32? I think the risk here is that MSBuild may not be aware of projects that don't support those targets.

[tommcdon]

@tommcdon , are there any restrictions on when to show ARM64 and ARM32? I think the risk here is that MSBuild may not be aware of projects that don't support those targets.

Version	Windows	Linux	macOS
.NET Core 2.1	x86, x64	x86, x64, arm32	x64
.NET Core 3.1	x86, x64, arm32	x86, x64, arm32, arm64	x64
.NET 5	x86, x64, arm64 (console only)	x86, x64, arm32, arm64	x64

[marcpopMSFT]

@benvillalobos I went ahead and put this in 16.10 as I think we have what we need from Tom.

[benvillalobos]

@dsplaisted how do we go about checking if we're specifically a console app?

The only reference to a console app check I've found is line 5647 on Microsoft.Common.CurrentVersion.Targets:
<Error Condition="'$(OutputType)'!='winexe' and '$(OutputType)'!='exe' and '$(OutputType)'!='appcontainerexe'" Text="Publish is only valid for 'Windows Application' or 'Console Application' project types."/>

[benvillalobos]

I'm not seeing any changes adding ARM64 to AvailablePlatforms:

[davkean]

@drewnoakes How are you populating above?

[dsplaisted]

@dsplaisted how do we go about checking if we're specifically a console app?

The only reference to a console app check I've found is line 5647 on Microsoft.Common.CurrentVersion.Targets:
<Error Condition="'$(OutputType)'!='winexe' and '$(OutputType)'!='exe' and '$(OutputType)'!='appcontainerexe'" Text="Publish is only valid for 'Windows Application' or 'Console Application' project types."/>

Non-console apps would have a FrameworkReference to the WindowsDesktop or AspNetCore framework. There wouldn't be a RuntimePack for the ARM RuntimeIdentifiers that aren't supported, so you'd get an error building a self-contained app targeting ARM. I don't think we have a block that would prevent you from building a shared framework app using an ARM RuntimeIdentifier.

[drewnoakes]

How are you populating above?

Those options are currently hard coded here:

https://github.com/dotnet/project-system/blob/20d7f46f0f492dfabcd61b7462e532b8229ca005/src/Microsoft.VisualStudio.ProjectSystem.Managed/ProjectSystem/Rules/PropertyPages/BuildPropertyPage.xaml#L39-L50

If they can be sourced from somewhere, we can add a dynamic enum value provider that surfaces them.

[davkean]

They are already provided by the <AvailablePlatforms> property.

[tmeschter]

Surfacing it in the new property pages is now tracked via dotnet/project-system#7081. The current plan is to read the allowable values from <AvailablePlatforms> and we will depend on the SDK to populate that correctly.

[davkean]

Note that the property pages have always read it (indirectly) from AvailablePlatforms. This was a regression from the prior pages.

[austinkinross]

Until this is fixed, what's the best way (if any) to make MSBuild pass /platform:ARM64 to CSC?

[benvillalobos]

@austinkinross At first glance, it looks like MSBuild calls csc and includes the platform like so: Platform="$(PlatformTarget)". Setting platformtarget affects PlatformTargetAsMSBuildArchitecture and ProcessorArchitecture properties (and likely others I'm not aware of), which will likely have adverse side effects.