dotnet run looks in the wrong bin/obj directories if targetting only one non-AnyCPU platform in <Platforms>, but works with <Platform> added

Describe the bug

If you only have a single platform, and that platform is not AnyCPU, dotnet build will place binaries in the path you’d expect, bin/$(Platform)/$(Configuration) but dotnet run seems to look in bin/$(Configuration), skipping platform entirely. When using dotnet run --no-build, this means failure… and without --no-build it means rebuilding pointlessly.

Also this appears to be the same problem that’s mentioned here, from DEC 2019 so clearly no progress has been made on this for years: https://developercommunity.visualstudio.com/t/dotnet-run-looks-in-the-wrong-location-for-project/462968

Last comment there, from “Ehsan Azarnasab [MSFT]”:

I had the same issue. There was already a `<Platforms>x64</Platforms>` that when I build in VS2019 is used to put binaries in bin/x64/Debug/netcoreapp2.2 but `dotnet run` needed `<Platform>x64</Platform>`. Otherwise `dotnet run` would instead use bin/Debug/netcoreapp2.2

I also added platform where there was a platforms! seems like a bug

And that’s exactly what I’m seeing too.

My guess for what’s going on

I believe this is to do with code needing to support Platforms (plural) not properly doing so… or perhaps an assumption was made that an empty/missing <Platform /> implies AnyCPU, and by having <Platforms> without <Platform> the logic gets confused because it seems to sometimes prefer omitting $(Platform) in the path for AnyCPU.

To Reproduce

I created a repository here: https://github.com/nacitar/dotnet-run-platforms-bug

As the readme says: The ‘main’ branch is just an unmodified VS2022 C# Console App from the template, targetting dotnet 6. https://github.com/nacitar/dotnet-run-platforms-bug shows the main branch’s code

The ‘x64-added-AnyCPU-removed’ branch adds x64 and removes AnyCPU, and reproduces the bug. https://github.com/nacitar/dotnet-run-platforms-bug/pull/1 is a pull request showing the changes that made it break

The ‘hackfixed-x64-added-AnyCPU-removed’ branch shows that adding <Platform> alongside <Platforms> works around the problem. I suspect the functionality of this workaround will make the nature of the problem clearer for those trying to fix it. https://github.com/nacitar/dotnet-run-platforms-bug/pull/2 is a pull request showing the change I did to hackishly workaround but in no way fix the problem

For all of these branches, reproduction is as follows:

dotnet build
dotnet run --no-build

It will work for the branches ‘main’ and for ‘hackfixed-x64-added-AnyCPU-removed’, but not for ‘x64-added-AnyCPU-removed’

Further technical details

dotnet info for 3 different contexts where i’ve seen this:

• dotnet --info on amazonlinux2

# dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.300
 Commit:    8473146e7d

Runtime Environment:
 OS Name:     amzn
 OS Version:  2
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/6.0.300/

Host (useful for support):
  Version: 6.0.5
  Commit:  70ae3df4a6

.NET SDKs installed:
  6.0.300 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

• dotnet --info on archlinux

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.102
 Commit:    49861cb924

Runtime Environment:
 OS Name:     arch
 OS Version:
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /usr/share/dotnet/sdk/6.0.102/

Host (useful for support):
  Version: 6.0.2
  Commit:  839cdfb0ec

.NET SDKs installed:
  6.0.102 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.NETCore.App 6.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

• dotnet --info on windows 10

.NET SDK (reflecting any global.json):
 Version:   6.0.202
 Commit:    f8a55617d2

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.202\

Host (useful for support):
  Version: 6.0.5
  Commit:  70ae3df4a6

.NET SDKs installed:
  3.1.419 [C:\Program Files\dotnet\sdk]
  5.0.408 [C:\Program Files\dotnet\sdk]
  6.0.202 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

[richlander]

We have discussed this a few times, but never closed this. This one definitely needs to be written down.

@baronfel – can you setup a call with @rainersigwald? I wonder if @drewnoakes wants to be included? Clearly, we haven’t cracked this nut yet.

[baronfel]

There’s a workaround by specifying a single platform for the run command with the -p:Platform=x64 MSbuild property.

This seems to be happening because we don’t ‘pivot’ builds on Platform like we do for TFM or RID - if you have multiples of those properties specified then we require you to disambiguate down to a specific ‘named’ build before running. We should do the same if Platforms are used.

At a surface level, this is happening because the run command uses the RunCommand and RunArguments MSBuild properties to determine which file to launch, and the calculation of that command takes the Platform into effect indirectly through the following chain: RunCommand => TargetPath => OutDir => OutputPath => PlatformName => Platform. run and watch commands likely have this same error, and we’ll want to fix it in a unified way.

@richlander One thing I’m thinking here - should RID impact the inference of Platform? because we could fairly easily tie a RID of linux-arm64 to also set Platform to arm64 today. Are Platforms even a recommended way of targeting like this in the SDK these days?