Improve RID and `publish` UX

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.

• #23551
• #26445
• #26444
• #26028
• #26031
• #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.

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

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.