Consider running Publish target when `_IsPublishing` is true

[sbomer]

For folks who don't use dotnet publish, it's a common pattern to inject the Publish target so that they can run msbuild without specifying /t:Publish. See examples from #37872 (comment):

Lots of people do that, some of them even pass _IsPublishing but most of them just do some variation of "run the Publish target". Here is a popular pattern (note these are all pretty high profile).

This won't fully replicate the effects of dotnet publish unless they also pass -p:_IsPublishing=true. Would it make sense to run the Publish target after Build when _IsPublishing is set, so that folks using msbuild can at least do msbuild -p:_IsPublishing=true and get the same output as dotnet publish? (We wouldn't advertise that until it's made public, see #26324)

@MichalStrehovsky @rainersigwald @marcpopMSFT @dsplaisted @agocke

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[MichalStrehovsky]

This would allow someone to define Publish as a build configuration even without the SDK providing this as a built-in concept.

The only issue I see with that is that the output of a Build with this property set to true would still be in the publish output directory, not build output directory (so even though one is running Build, the output is in Publish).

If someone were to define such build configuration and try to use it in VS, they would find out that F5 launch still launches the results of Build, not Publish. This might be extra problematic for e.g. native AOT because Build is going to use the native AOT runtime pack because of the IsPublishing property (once #37872 merges), but that would mean that the result of Build is unusable (it will have native AOT corelib from the runtime pack, but CoreCLR JIT-based runtime).

There might be similar problems for other publish modes (e.g. do we choose a single file apphost based on PublishSingleFile+IsPublishing?)