dotnet build/publish uses the implicit SDK RID for RID-specific apps by default

[richlander]

dotnet build/publish uses the implicit SDK RID for RID-specific apps by default

Proposal: .NET SDK uses the implicit Runtime Identifier (RID) in each case when a RID is required but isn't specified by the user. It should affect (at least) the following dotnet commands:

• build
• publish
• run

We should validate where --self-contained is supported/valid. Wherever it is valid, this behavior change should be made.

Example: The following example (console app template) should not fail, but succeed (using the implicit SDK RID). This failure isn't useful (it doesn't protect the user from anything scary).

PS C:\Users\rich\app3> dotnet build --self-contained
Microsoft (R) Build Engine version 17.0.0+c9eb9dd64 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(150,5): error NETSDK1031: It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier. You must either specify a RuntimeIdentifier or set SelfContained to false. [C:\Users\rich\app3\app3.csproj]

Build FAILED.

Note: Part of this feature was implemented in #22314.

[imba-tjd]

What about

dotnet publish -p:PublishReadyToRun=true

and

dotnet publish --self-contained=false -p:PublishReadyToRun=true

Currently they must specify RID.

[naine]

PublishSingleFile too. The current proposal seems to cover them:

in each case when a RID is required but isn't specified by the user

[tmds]

This should use the portable rid, and not the rid the SDK/runtime was built for.

.NET 6 SDK added an option for this called --use-current-runtime to build/restore/publish but not run.

Adding the rid affects the restore behavior and causes more dependencies to be downloaded. Probably this is not desired.

[richlander]

Just saw this. This doesn't ring true for me. There is no such option today, opt-in or otherwise, other than perhaps -r any. Also, what would portable buy you since you have a rid-specific executable and no other way to launch the app than that executable?

By definition, (as a user) you've already opted into a RID-specific scenario. This is just about getting a default RID instead of always being forced to specify one. Seems virtuous w/no downside to me.

[tmds]

There is no such option today

There is --use-current-runtime.

other than perhaps -r any. Also, what would portable buy you since you have a rid-specific executable and no other way to launch the app than that executable?

By portable, I don't mean any. I mean the associated portable rid of the platform. For example, on a source-built SDK which has the non-portable rid fedora.35-x64, the associated portable rid is linux-x64.

The SDK already stores this rid in the Microsoft.NETCoreSdk.BundledVersions.props file as NETCoreSdkPortableRuntimeIdentifier.

in each case when a RID is required

#23545 is proposing: dotnet build/publish does not produce an exe/apphost for portable apps by default.

So, if I understand correctly:
When these commands are used without any arguments, they will no longer require a RID.
And, this issue applies when the user adds an argument that requires a RID, like: --self-contained.

[richlander]

Oh! I always forget this use of portable. Yes, we want portable.

The implicit RID and the --use-current-runtime one should be identical. Is that right @baronfel?

Right. This change would apply when you use --self-contained but don't explicitly specify a RID.

[baronfel]

Yeah, --use-current-runtime eventually resolves to the portable RID:

• it sets the UseCurrentRuntimeIdentifier=true msbuild property,
• in the runtime inference targets, the presence of that property sets the RuntimeIdentifier to NETCoreSdkPortableRuntimeIdentifier
• NETCoreSdkPortableRuntimeIdentifier is set in dotnet/installer to PortableProductMonikerRid
• PortableProductMonikerRid is also set in dotnet/installer to $(HostOSName)-$(Architecture), where HostOSName is one of win, osx, freebsd, or linux

So yes, I believe they should be identical.

[baronfel]

Right now we do this inference when --self-contained is specified (as of #21405), but that was done at the CLI level. we should probably push that down into the RuntimeInference targets proper.

We should set the RID for

• SelfContained=true,
• PublishReadyToRun=true,
• PublishSingleFile=true
• PublishAot=true

Do folks know of other scenarios that would fit? Otherwise we'll keep spelunking the publish-y targets.

If this list is too long/freeform we may want to consider a more extensible mechanism for opting in to this behavior.

[richlander]

Ya. I was mentioning this to @agocke. We should do all those things. Add PublishAot to the list.

[agocke]

I don't think anything except SelfContained probably needs anything.

If you have PublishAot in your project file, you don't want dotnet build to suddenly start producing self-contained builds. And the rest of them aren't even self-contained specific during publish, so I don't think there's anything to do there.

[richlander]

Oh my, did I just realize that we don't have a PublishSelfContained property? If not, that seems like an odd hole! Can we add that?

[agocke]

Is the goal to allow Publish to behave differently from build?

[richlander]

No. This is agnostic to build/publish. It's whatever argument requires a RID can use the implicit one. Most of the cases for that are in publish but not exclusively. Even if they were only on publish, the answer would still be no since the key difference would be those additional capabilities being only for publish. This feature doesn't change that.

[richlander]

I wrote a mini-spec for the Publish* properties at #26028

[richlander]

I wrote a mini-spec on FDD + (implicit) RID-specific apps at #26031

[nagilson]

This should be resolved in the release/7.0.1xx branch now. (#26143) I'd imagine it will flow into rc-2 within a week or two. Please let me know if you encounter any issues. Elsewise we can mark this as resolved! Thanks for working with us to improve the end user experience