Proposal: cleaning up publish UX

[agocke]

In using and helping others use dotnet publish I've found a few behaviors confusing and thought of a few minor changes that could help improve the experience. I'll list some thoughts below: I think many of them are independently useful and we can pick and choose what is most effective.

First, I think there's a fair bit of confusion about what the purpose of build is (or should be) and the purpose of publish. An informal survey suggests that most users think of build as a development command -- something which produces a runnable local asset, but not something that would be deployed to another environment. Publish is the command which produces deployable (copyable) assets.

If we lean into this distinction, I think there are a number of UX simplifications that we can make:

build should not use the "runtime identifier" option

If building is meant to create local assets, there is only one runtime identifier which matters: the runtime identifier of the currently executing dotnet command. The focus of build should be to produce a local asset as quickly and easily as possible. It should be able to assume that the current dotnet runtime identifier is sufficient for running the asset, and even share as many runtime components as possible with the dotnet installation.

build should not have a "self-contained" option

Like runtime identifer, this is meaningless because we already know we have a dotnet installation -- the one being used to build the application. Self-contained is important only in copying to other environments, where a dotnet installation may not be present.

one publish directory

Right now when you build/publish a standard app you end up with a layout something like:

1. bin/Debug/net5.0/* for build files when no RID is set
2. bin/Debug/net5.0/RID/* for build files when a RID is set
3. bin/Debug/net5.0/RID/publish/* for publish files (also creates the above during implicit build)

If we accept the above, (1) and (2) look pretty strange. If build is not affected by RID, only (1) should exist. In addition, (3) seems to have a redundant publish subdirectory.

If we get rid of the current behavior, we can have a universal build directory, (1), and (2) can become the new publish directory. We should never need the redundant subdirectory (3).

Overall this would result in a simpler experience for users:

• builds are always local and always go in the same subdirectory
• publishes are for deployment to a different environment. The target RID is the publish directory, and we can use a moniker like portable for RID-independent publishes

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[agocke]

@richlander @samsp-msft @KathleenDollard I'd appreciate any feedback you have on this!

[benaadams]

Can the "publish" type option default to Release mode also; rather than Debug as currently? #10357

[richlander]

I like the general idea of this proposal. I don't think "no RID for build" works, at least not for mobile and wasm.

[agocke]

In the case of mobile/wasm, isn't the TF itself a RID?

[baronfel]

Since this was logged we've done a few aspects of this discussion:

• publish defaults to Release
• Artifacts output path flattens output directory structures and separates publish outputs from build outputs entirely
• SelfContained can impact publish only through PublishSelfContained

and we're collectively investigating build making RID-specific (but not self-contained) assets in one of the other explorations. Since the majority of these are covered in other sub-discussions, I'm going to close this old request.