Support publishing for a RuntimeIdentifier without building for that RuntimeIdentifier

This is similar to #2839, but also involves using the “No Build” option on publish.

So you have a project with:

<RuntimeIdentifiers>A;B;C</RuntimeIdentifiers>

And you do:

dotnet build
dotnet publish -r A --no-restore --no-build

After fixing #2839, the --no-build scenario is still failing. It looks like this is because the RID-specific app-host isn’t in the intermediate directory and it fails when trying to copy it to the publish directory.

[dsplaisted]

@peterhuene I think you’re right, it doesn’t really make sense for this to work. I thought that it was a scenario we supported or tried to support in earlier releases, but maybe I’m getting no-build confused with no-restore.

[peterhuene]

@dsplaisted @livarcocc I originally left a question to this issue which I later deleted because perhaps I wasn’t seeing things correctly.

However, I now would like to ask that question again. How is this supposed to work if we never build for the RID we’re publishing for?

Currently RuntimeIdentifiers controls which RIDs we’re restoring for, but not which we’re targeting the build, which can currently only be a single RID specified via RuntimeIdentifier. Thus, in the repro steps above, dotnet build builds RID-agnostic.

When we publish --no-build for a specified RID from a previous build being RID-agnostic, we have no RID-specific build outputs (either in bin/ or obj/) to copy to the publish directory.

Are we proposing that the presence of RuntimeIdentifiers fans out the build the same way TargetFrameworks does? That is a requested change from the community (I would have to dig up the issue), albeit a breaking change.

If that’s not the case, then I don’t see how the above repro is expected to work.