RuntimeIdentifiers doesn't set PlatformTarget

From @davidmatson on March 21, 2017 2:47

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net452</TargetFramework>
    <RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
    <AssemblyName>Testx64</AssemblyName>
  </PropertyGroup>
</Project>

Expected: 64-bit assembly

Actual: AnyCPU assembly

Current workaround is to add:

<PlatformTarget>x64</PlatformTarget>

Copied from original issue: dotnet/roslyn-project-system#1804

[nguerrera]

For example, if the runtime identifier is win-x64, could that be understood as requiring a platform of x64

It already does set $(PlatformTarget) for you to x64 in this case if you haven’t set it yourself.

Similarly, if you build on Windows and set $(PlatformTarget), it will pick the win7-x64 $(RuntimeIdentifier) for you. When we pick for you, we do not add path segments. This is safe because the build invocation with something unset is different from when it’s set and the goal is different build gestures that change these parameters go to different directories.

There’s a good subset of common cases where you can stick to either the traditional Platform/PlatformTarget or RuntimeIdentifier/RuntimeIdentifiers, but not mix them, and you won’t get any project file content or path duplication.

If platform is x64 but runtimeidentifier is win-x86, something is wrong, and the build should error out with a clear message - is that correct?

The variables that can never mismatch are $(PlatformTarget) (used to stamp exe) and $(RuntimeIdentifier) (used to resolve native nuget assets). With that said, we do not issue a warning or error in this case today.

$(Platform) is a little different. It is just an extra dimension to the configuration. It does not necessarily affect other things. By default Platform=x64 implies PlatformTarget=x64, but you can change in fact change them independently. It is not uncommon to just use empty default $(Platform)=AnyCPU but still emit platform-specific binaries. It has also always been possible (for classic csproj too) to have Platform=x86 (set by configuration manager), but PlatformTarget=x64 (set by build property page).

If the system understood that relationship, it could be used to remove the extra path segment in this case, right?

It’s not that easy. We certainly can’t remove an explicit RuntimeIdentifier=win7-x64 because there can be a separate build invocation with win10-x64 and that needs to go to a distinct directory. Removing the x64 part is more promising as it’s the only part that is actually redundant, but it would make it overly complicated to predict the output path of any given project and build invocation. Platform being much like Configuration (as explained above) means that it is part of the output path in the same way (with the long-standing convention that AnyCPU gets an empty segment). While bizarre, it is possible to have conditions based on $(Platform) such that $(Platform)=x64/$(PlatformTarget)=x64 builds something different than $(Platform)=AnyCPU, $(PlatformTarget)=x64.

In the fully general case, this can get very complex.

I see two follow-ups here:

• Document exactly how default paths are constructed and the relationships between $(Platform), $(PlatformTarget), and $(RuntimeIdentifier), etc.
• Add build diagnostic for PlatformTarget/RuntimeIdentifier mismatch

[dsplaisted]

I think this is by design. I believe the plural RuntimeIdentifiers property only affects what runtime-specific packages NuGet restores (allowing you to do a rid-specific publish for example later). If you want to build for x64, then I think you would set the singular RuntimeIdentifier property instead.

@nguerrera or @eerhardt may be able to provide more insight.