Design/Doc issue: PlatformTarget vs Platforms vs RuntimeIdentifier handled inconsistently

From @davidmatson on August 28, 2017 20:11

I’ve stumbled across a number of cases where it isn’t clear if I should use PlatformTarget, Platforms or RuntimeIdentifier. The tooling seems to get confused a bit between these properties as well - sometimes one UI (project properties) will reflect one property but another UI (Configuration Manager) will reflect a different property.

Could we document when to use which property? Or, perhaps even better, could we reduce the concept count here and would that lead to fewer bugs/ambiguities/possible conflicts?

For example, what’s the right way to say the project is x64?

<RuntimeIdentifier>win-x64</RuntimeIdentifier>

and/or

<PlatformTarget>x64</PlatformTarget>

and/or

<Platforms>x64</Platforms>

Is there any way to reduce the number of ways to say “I’m x64”?

Copied from original issue: dotnet/project-system#2748

[davkean]

I agree, we should simplify this, @dsplaisted @nguerrera Thoughts?

[wldevries]

I ran into this problem on one of our products. Visual Studio seems uses Platforms to determine what the build output should be, while our build script that uses the MSBuild task internally requires PlatformTarget to be set. This was very confusing and none of these properties seem to be documented anywhere.

Note that our build.csproj is run by msbuild.exe included with VS2019. The reason we don’t use dotnet msbuild is that it hangs and does not work, probably due to having a mix of old school csproj files and new Microsoft.NET.Sdk projects.