Proposal: cleaning up `publish` UX
See original GitHub issueIn 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:
bin/Debug/net5.0/*
for build files when no RID is setbin/Debug/net5.0/RID/*
for build files when a RID is setbin/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
Issue Analytics
- State:
- Created 3 years ago
- Reactions:7
- Comments:6 (5 by maintainers)
Can the “publish” type option default to
Release
mode also; rather thanDebug
as currently? https://github.com/dotnet/sdk/issues/10357Since this was logged we’ve done a few aspects of this discussion:
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.