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.