Improve RID and `publish` UX

[richlander]

I've been defining several experiences that are intended to improve Runtime Identifier (RID) and/or publish experiences. It makes sense to catalog those all in one place since its easy (including for me) to lose track of them.

• Enable publishing as Release with PublishRelease #23551
• Enable publishing a self-contained app with PublishSelfContained #26445
• Enable publishing for a RID with PublishRuntimeIdentifier #26444
• Use implicit RID for Publish Properties #26028
• Enable FDD + (implicit) RID-specific apps with RuntimeSpecific #26031
• dotnet build/publish uses the implicit SDK RID for RID-specific apps by default #23539

Where is this all heading? There are two primary goals:

• Better differentiate build and publish and use them to better support common developer workflows. There are properties that you cannot put in project files today because they won't do the right thing with either build or publish since there is no good way to conditionalize them.
• Reduce the degree to which developers have to use the RID syntax and the -r argument while at the same time runtime-specific apps are the best option in many cases.

[nagilson]

Will be investigating these now; I've created a thread where you can track my status on implementing all of these improvements: #26503

[agocke]

I'd suggest a few more items for this:

1. Add some sort of portable RID. I think this could map to the any RID. This should also disable the apphost (UseAppHost=false).
2. Hook this setting into the VS publish dialog. Right now "portable" is selected by default, but it creates an AppHost and sets <Platform>Any CPU</Platform>, which is meaningless.

[agocke]

fyi @richlander

[richlander]

I was thinking that maybe RuntimeSpecific=false could be the answer to point 1. Or put another way, I don't think a RID should be the gesture. One of my underlying goals (across multiple features I've been working on) is to make specifying RIDs directly less common. They are confusing, even for folks that define them.

Separately, any doesn't quite do the right thing, at least per my experiments with it. I did that because @vitek-karas told that "any doesn't do what you think" and the experiments seemed to prove that out. My observation was that any resulted in less not more RID-specific NuGet assets restored/in my bin folder. I didn't pursue why. Vitek would have more insight into why.

I've already started talking to the VS Publish folks. I'll setup a meeting for that so we can make some good decisions.

[DamianEdwards]

Any timeline goals for this? Based on my experiments so far, these changes would be hugely beneficial to the UX.

[richlander]

Some combination of 7.0.100 and 7.0.200.

I feel your pain.

[nagilson]

@DamianEdwards The implicit RID stuff is about to be under wraps once I fix the fact that it's breaking RID agnostic projects. It might require changes to MSBuild as well and I'm new to that, so it's been a bottleneck. I agree it's very important!

[richlander]

@DamianEdwards If you've got a preferred ordering of what's left, we'd be very interested in that.

[DamianEdwards]

My preferred ordering:

1. Implicit RID (default to current platform RID)
2. PublishSelfContained
3. The rest

That would put us in a place where a project can default its publish behavior to practically any combination of configuration=Release, self-contained (for current RID), trimmed, single-file, etc.