dotnet build /t:Publish -p:_IsPublishing=true should use Release config

[sbomer]

Folks who invoke the publish target directly will get different behavior from dotnet publish.

dotnet publish does a release build by default:

> dotnet publish
Restore complete (0.3s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  publishRelease succeeded (0.2s) → bin/Release/net10.0/publish/

Build succeeded in 0.8s

dotnet build /t:Publish does a debug build:

> dotnet build /t:Publish
Restore complete (0.4s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  publishRelease succeeded (0.2s) → bin/Debug/net10.0/publish/

Build succeeded in 0.9s

Passing -p:_IsPublishing=true doesn't change this:

> dotnet build /t:Publish -p:_IsPublishing=true
Restore complete (0.4s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  publishRelease succeeded (0.2s) → bin/Debug/net10.0/publish/

Build succeeded in 0.9s

Should we add logic early in the SDK that sets Configuration to Release (maybe depending on the value of PublishRelease), when _IsPublishing is true? This would help ensure that the default publishing output paths are different from the default build output paths: #26324 (comment).

@rainersigwald @nagilson @marcpopMSFT @dsplaisted @agocke

[nagilson]

We could, though it feels redundant to have to type IsPublishing twice and technically it's supposed to be a hidden property; having this pattern propagated around wouldn't be ideal. Also, PublishRelease is gated on the TargetFramework which the logic for happens after Configuration, so we can't respect the value of PublishRelease with this approach if it was false (say, CI machine decided to opt out to the breaking change) -- by the time we knew publish release was false, configuration would be set to release already when doing a basic dotnet publish in this case. We would have to do another breaking change to support this which we could but I dont think this issue is about that.

I think this is a smart consideration but sadly it doesn't really work this way and I dont think we want to support a scenario like this half the way. Maybe @rainersigwald would have more to say.

[rainersigwald]

I find that very convincing @nagilson.

[sbomer]

though it feels redundant to have to type IsPublishing twice and technically it's supposed to be a hidden property; having this pattern propagated around wouldn't be ideal.

I agree - this proposal is aimed at fixing the behavior of _IsPublishing so that it could be made public. #46279 would address the redundancy.

Also, PublishRelease is gated on the TargetFramework which the logic for happens after Configuration, so we can't respect the value of PublishRelease with this approach if it was false

You're pointing out that setting PublishRelease in the project file would be too late to affect the Configuration, when running dotnet msbuild, right? That's already the case today and I'm not suggesting to change that.