Use implicit RID for `Publish` Properties

[richlander]

Use implicit RID for Publish Properties

Based on #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

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

[richlander]

I was thinking about --use-current-runtime in relationship to the Visual Studio guidance at #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?

[nagilson]

We haven't forgotten this proposal! There have been some brief discussions on which choice, but nothing confirmed yet. I think some folks will reach out to discuss this with you offline when there's bandwidth.

I'm lacking experience to give a good enough final answer. But I lean towards 1. This is under the assumption that if I specify a runtime with -r, -a, or -os, I would not expect that choice to be overridden later because it's been specified very explicitly. But the property appears to more 'hint at a desired behavior' (wanting the published app to decide on a specific RID by itself if one isn't provided) It seems more intuitive if, providing --runtime osx.10.11-x64 overrides the project property, than to provide an osx runtime and then get something not published for osx.10.11-x64.

[richlander]

I also lean towards 1 so seems like we have a deal. I think it has the most intuitive behavior.

We'd need to decide what RuntimeSpecific=false means with -r present. I'd suggest that RuntimeSpecific solely sets defaults, that can be overrriden, which would allow for that case.

I'm trying to remember the case where --use-current-runtime would still be needed. Oh, I remember now. It's this case.

A project file has this:

<RuntimeIdentifier>linux-x64</RuntimeIdentifier>

Whether it also specified RuntimeSpecific doesn't matter.

Via the CLI, you want to override that to linux-arm64 and you are building within an linux-arm64 container image. In that case, docker publish -r linux-arm64 works, but you are forced to write that and have a separate Dockerfile for Linux Arm64. Instead you say, docker publish --use-current-runtime and it works perfectly. You can use that Dockerfile in whatever you environment you want.

Ideally, we could have a shorter alias for that like --ucr. That would be very nice.

Thinking more about this, RuntimeSpecific=true should be a wrapper over this:

<SelfContained>false</SelfContained>
<RuntimeIdentifier>$CurrentRuntime</RuntimeIdentifier>

That means if you specify -r linux-x64 via the CLI, you still have an FDD app, unless you specifically add --self-contained true.

Good?