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

[davkean]

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?

[davidmatson]

Should we prohibit setting PlatformTarget for .NET Core projects and instead have RuntimeIdentifier be the sole way of setting this kind of value? That could help remove a discrepancy between whether this is a build-time vs. deployment-time decision.

[clairernovotny]

There's another related issue.. the current build targets don't multi-target per RID. If you need to do different things in the impl per RID, then you're stuck.

I've implemented per-RID builds (and packaging under runtimes) in my Extras:
https://github.com/onovotny/MSBuildSdkExtras#rids

I piggy-back on the DispatchToInnerBuilds by adding the RID to it (and setting a define).

Should this be built-in:
https://github.com/onovotny/MSBuildSdkExtras/blob/master/Source/MSBuild.Sdk.Extras/Build/RIDs.targets#L7-L41

[StefanOssendorf]

Any news to this?
I'm trying to figure out which of these properties (or all?) I need to set to get the right bits compiled.

[kirsan31]

Most of my previous post was related to VS 16.2, In VS 16.3 preview this was fixed.
For now to all confusing stuff above, I can add that it's really confusing that in AnyCpu (default template) build you can't get AnyCpu exe :( Hi #1906.
With .core 3.0 coming (WinForms and WPF), it's completely unclear to any one who will start migrate their win gui app to core, that AnyCpu not a choice here! :(((

[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.

[wldevries]

It seems the problem I'm having is dotnet/project-system#5901