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

[nacitar]

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.
nacitar/dotnet-run-platforms-bug#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.
nacitar/dotnet-run-platforms-bug#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

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

[baronfel]

@nacitar what are you using the Platform for? Often times with .NET SDK project, we encourage the use of Runtime Idenfitifers to specify an combination of OS and Architecture, and all of the SDK is fairly oriented around these concepts. Platform works almost orthogonally to those concepts. Maybe there's another way we can get you set up with them instead, so you don't hit Platform foot-guns.

[nacitar]

@nacitar what are you using the Platform for? Often times with .NET SDK project, we encourage the use of Runtime Idenfitifers to specify an combination of OS and Architecture, and all of the SDK is fairly oriented around these concepts. Platform works almost orthogonally to those concepts. Maybe there's another way we can get you set up with them instead, so you don't hit Platform foot-guns.

In my case it's a dotnet 6 c# amazon CDK project, in a linux container that uses dotnet build to prepare the binaries and then using dotnet run to execute because that's how cdk rigs things up when you use it to initialize a new cdk project. I just noticed it was rebuilding unnecessarily when I ran it, hence this bug. I can easily edit it to set the platform like you mentioned as a workaround.

As far as what I'm using the platform for, I'm simply making the project x64 instead of any cpu just because it's only going to be running on that platform.

I'm not sure if that answers your question or not. If you have some particular set of arguments you'd suggest I pass on these command lines to specify things differently I'm all ears, too.

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

[nacitar]

I'm guessing that call never happened, but I'm still interested in seeing this resolved.

[cai-michael]

I came across this issue after trying to debug a change to a YAML pipeline where I added the --no-build flag to a DotNetCoreCLI@2 run task. It looks like <Platforms>x64</Platforms> is still ignored by dotnet run. My local machine and build agent are currently using .NET 6.0.403.

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

This workaround unfortunately did not work in my case, and the path was still missing x64.

Fortunately, after finding this post and specifying <Platform>x64</Platform> in my csproj file the task seems to be running fine. But this seems like a lesser-known fix compared to the MSbuild property suggestion.

Edit:
After updating the build agents to 7.0.100, I've also encountered this issue for dotnet test now.

[baronfel]

@rainersigwald we're thinking about making this an Analyzer (that the SDK team would author) that would warn if a .NET SDK project actually used Platform. We do not thing this property has value for .NET SDK projects. Do you see any problems with this? I will document this guidance either way.