Use implicit RID for `Publish` Properties

Use implicit RID for Publish Properties

Based on https://github.com/dotnet/sdk/issues/23539, we have the opportunities to make additional improvements fit-and-finish improvements. The referenced change enables an implicit RID to be used when a RID is needed, specifically via the CLI like with --self-contained. There several properties where that is equally valuable.

We should extend the same change to:

• SelfContained
• PublishAot
• PublishReadyToRun
• PublishSingleFile
• PublishTrimmed

These proposed changes make it obvious that we’re missing PublishSelfContained as an option. It’s odd that this has never come up. It would enable producing self contained apps, but only for the publish verb, just like the other Publish* properties.

We should add:

• PublishSelfContained

In retrospect, I’ve struggled with the lack of PublishSelfContained, but it never occurred to me that we could have such a straightforward and symmetric solution to solve that.

–use-current-runtime

The new implicit RID feature replaces --use-current-runtime. The following two lines are now equivalent.

dotnet build --self-contained
dotnet build --self-contained --use-current-runtime

We should deprecate (and undocument) --use-current-runtime going foward. It no longer has a purpose.

@baronfel @agocke @nagilson @marcpopMSFT

[richlander]

I was thinking about --use-current-runtime in relationship to the Visual Studio guidance at https://github.com/dotnet/sdk/issues/26031. Sadly, I think we may need to keep --use-current-runtime.

That guidance suggests setting RuntimeSpecific and SelfContained properties to false. That’s fine.

After talking to @bradygaster, I learned that there were some scenarios that would benefit to RuntimeSpecific = true and SelfContained = false. I believe that. However, there is only one way that I know how to do that, like the following:

dotnet publish -c Release --use-current-runtime --self-contained false

That forced set of settings would be necessary to coerce a project into “Brady mode” if it was configured like this:

<PropertyGroup>
   <SelfContained>true</SelfContained>
   <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
</PropertyGroup>

The key point here is whether RuntimeSpecific should overwrite a RID if one is specified.

Here are some choices:

1. RuntimeSpecific only specifies a RID when RuntimeIdentifier isn’t specified.
2. RuntimeSpecific always overwrites RuntimeIdentifier.
3. Specifying RuntimeSpecific and RuntimeIdentifier together is an error.

If we go with the first one, then it seems like we need to keep --use-current-runtime. If we go with the second one, we don’t. The last one seems like it would cause problems w/o a lot of value.

If we go with the first one, the property would basically be RuntimeSpecificCurrentRidHighlander. Bad movie reference (“there can only be one”).

Anyone have a preference for which of these we should go with?

[baronfel]

We should do this! The RuntimeInference part especially should be pushed down into the RuntimeInference targets and removed from the CLI’s handling - right now the CLI can sometimes implicitly assign the RID via the RuntimeIdentifier property based on user gestures (see #25062 for an example of this) and this mismatch between the CLI and the targets leads to unclear ordering.