Any CPU is treated as x86 even when it'll really be x64

In the following project:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net47</TargetFramework>
  </PropertyGroup>
</Project>

And also I believe in this one:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net47</TargetFramework>
    <PlatformTarget>AnyCPU</PlatformTarget>
  </PropertyGroup>
</Project>

The implicit RuntimeIdentifier is currently, rather surprisingly win7-x86 rather than just win7. That is likely fundamentally broken for an AnyCPU platform target. The purpose of Any CPU is that it will run on any CPU, including as 64-bit on a 64-bit CPU (unless Prefer32Bit is set to true). If we treat it as x86, we’ll be handling the other half of Any CPU cases incorrectly.

I can work up a repro if needed - I suspect when including a package with native references, we’d incorrectly pull in win7-x86 instead of win7 in this case, which will cause runtime breaks on an x64 OS.

Some additional details here: https://github.com/dotnet/project-system/issues/2744#issuecomment-325483773

[dsplaisted]

@zivkan The logic you’re looking at is complicated, and got more complicated over time. But basically if neither a RuntimeIdentifier nor a PlatformTarget is set for a .NET Framework project, then the SDK will guess that the RuntimeIdentifier is win7-x86 and see if it gets any native assets from NuGet packages. If it does, then it will set the PlatformTarget to x86. Otherwise, it will go back to AnyCPU.

I don’t think that’s the main thing @davidmatson is hitting though. It sounds like he wants guidance for how to create a NuGet package that correctly includes native assets, and in his case includes both x86 and x64 assets for AnyCPU, but otherwise includes only the matching assets.

It sounds like that only intersects with the original problem in this issue in that the guidance may need to include a recommendation to have packages with native assets in them depend on the Microsoft.NETCore.Platforms package.

[davidmatson]

@dsplaisted - could we reopen this issue to tracking providing package authors some way to write packages in this scenario? I understand we can’t make the code at the top of this issue just work, unfortunately, due to back-compat concerns, but could we still track providing some kind of solution?

Thanks!