Default platform target in Properties window is incorrect

[davkean]

From @davidmatson on August 28, 2017 19:40

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

using System;
using System.Reflection;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(Environment.Is64BitProcess);
        ImageFileMachine b;
        typeof(Program).Assembly.ManifestModule.GetPEKind(out PortableExecutableKinds a, out b);
        Console.WriteLine($"{a}: {b}");
    }
}

Actual output:

True
ILOnly: I386

But, properties window shows:

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

[davkean]

From @davidmatson on August 28, 2017 19:42

Just to clarify, the output is fine an expected for AnyCPU without Prefer 32-bit, which apparently is actually the default for this kind of project. The only problem is what the properties window shows - if the default is actually AnyCPU without Prefer 32-bit, the UI should say so.

[davkean]

From @tannergooding on August 28, 2017 19:43

Could you please indicate which version of Visual Studio you are using and which versions of the SDK you have installed (both 64-bit and 32-bit versions).

[davkean]

From @davidmatson on August 28, 2017 19:44

Visual Studio Enterprise 2017 Version 15.3.2.

I didn't do anything special to install an SDK as far as I know - what SDK version would you like and were should I find that value?

[davkean]

From @tannergooding on August 28, 2017 20:5

If you didn't do anything specific to install the SDK it is probably 1.1.2.

You can see which versions you have installed (generally) by looking here: C:\Program Files\dotnet\sdk (for x64) and here: C:\Program Files (x86)\dotnet\sdk (for x86)

You should be able to look at your bin\*.deps.json file to see what version you are using (should have a line similar to "name": ".NETCoreApp,Version=v2.0".

Is this a project you can share the detailed or diagnostic verbosity 'build log' for (that will include all of the referenced paths which should explicitly indicate the full path of the SDK you are using)?

[davkean]

From @tannergooding on August 28, 2017 20:8

Actually, I seem to be able to repro this on the 2.0 SDK. It seems to occur whenever you single-target net* (net45, net46, net47, etc).

Going to keep looking

[davkean]

From @davidmatson on August 28, 2017 20:18

I have the following SDK folders:

• 1.0.0
• 1.0.2
• 1.0.3
• 1.0.4
• 1.1.0
• 2.0.0

I didn't find anything except the exe and pdb in my bin folder, but it sounds like you probably have what you need. Let me know if I can provide any more data though. Thanks!

[davkean]

From @tannergooding on August 28, 2017 20:46

It comes down to this line: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.RuntimeIdentifierInference.targets#L65

Going to see if I can find the relevant people to tag here.

[davkean]

From @tannergooding on August 28, 2017 21:0

Ok, talked to some of the members on @dotnet/dotnet-cli and they indicated that this is 'by design'.

From what I understood, when targeting AnyCPU for .NETFramework, they have to pick a default RuntimeIdentifier for NuGet and use that. They choose x86 if not specific since that is the most common target for .NET Framework. If they find any native dependencies they do a fixup of the properties later.

There is one bug here, on the project system, that we should detect this and display the correct value in the properties window.

There is potentially a separate bug on the SDK that they should just be using win7 if the Platform is AnyCPU and should just fail (either at restore, build time, or runtime) if the user is targeting AnyCPU and is not referencing native dependencies in a portable manner (such as dynamically choosing to load the 64-bit library on x64 and the x86 library on x86) as they are inherently broken otherwise (they target AnyCPU and are referencing a 32-bit specific DLL, which can potentially cause breaks at runtime if they happen to run as 64-bit).

[davkean]

From @tannergooding on August 28, 2017 21:1

You can workaround the issue for the time being by explicitly specifying <PlatformTarget>AnyCPU</PlatformTarget> in your project file.

[davkean]

From @tannergooding on August 28, 2017 21:1

FYI. @Pilchie

[davkean]

From @tannergooding on August 28, 2017 21:5

FYI. @natidea as well

[davkean]

From @davidmatson on August 28, 2017 21:10

Thanks - yeah, I figured some combination of properties would cover a workaround.

The project system bug is that it should display Any CPU as Platform target in the project properties window in this case, right?

And the potential SDK bug is to use win7 as the default RuntimeIdentifier (i.e. PlatformTarget is implicitly AnyCPU)? That sounds right to me - it's quite odd to have Any CPU be treated as x86. Do we need to file another issue on a SDK repo to track that part?

Thanks!

[davkean]

From @tannergooding on August 28, 2017 21:14

Do we need to file another issue on a SDK repo to track that part?

It couldn't hurt to log one. Worst case is they close it as 'by design' and say we can't change it due to back-compat now.

[davkean]

We're just showing what the build tells us is the PlatformTarget, we shouldn't do anything special here - the SDK should be giving us the correct value for it.

[davkean]

If you look at build, you can clearly see that PlatformTarget is being set to x86:

1>Platform                       = AnyCPU
1>PlatformName                   = AnyCPU
1>Platforms                      = AnyCPU
1>PlatformTarget                 = x86
1>PlatformTargetAsMSBuildArchitecture = x86

This is an SDK bug.