dotnet-publish-kit

Publish a .NET web app from the terminal without retyping paths. Pick a project, pick a destination, ship it. Zero dependencies.

npm i -g dotnet-publish-kit   # then, inside any .NET repo:
dpub

That is the whole thing. Run it anywhere inside a repo that has a .sln (or a .csproj); it walks up to find one, and refuses to guess if there is none.

Why

dotnet publish is fine until the repo has fourteen web projects and each one goes somewhere different. Then every deploy becomes a hunt for the right --project and the right -o, and the Visual Studio publish profiles have long since drifted apart. This tool asks instead of guessing, and remembers the answer.

Install

Needs Node 16+ and the dotnet CLI on PATH. Works on Windows, macOS and Linux — except dpub iis, which is Windows-only by nature.

Global — the normal choice

npm i -g dotnet-publish-kit

Gives you dpub in every terminal, in every repo. Use this if you deploy more than once in a blue moon.

dpub                                  # in any .NET repo
npm i -g dotnet-publish-kit@latest    # update
npm rm -g dotnet-publish-kit          # remove

npx — no install

npx dotnet-publish-kit@latest

Downloads into npm's shared cache (~/.npm/_npx/…, or %LOCALAPPDATA%\npm-cache\_npx\… on Windows), runs, and leaves your project alone. Nothing is added to the repo and nothing appears in npm ls -g.

Keep the @latest: npx caches by version, so plain npx dotnet-publish-kit can keep re-running whatever version it fetched the first time.

Do not install it into the .NET project

npm i -D dotnet-publish-kit   # don't

That drops node_modules/, package.json and package-lock.json into a C# repository — noise in the tree, and noise in every commit. This is a developer tool, not a project dependency. Install it globally, or use npx.

Which one

| | Command | Use when | |---|---|---| | Global | npm i -g dotnet-publish-kit → dpub | you publish regularly, across several repos | | npx | npx dotnet-publish-kit@latest | trying it out, or a one-shot CI step | | In-project | — | never |

Use

dpub            # same as: dpub publish
dpub list       # which web projects are in here?
dpub publish    # choose a project, choose a destination, publish
dpub iis        # run under IIS Express (Windows)

With more than one web project it asks — arrow keys, or press the number:

 Co 3 project web trong Shop.sln:

 ❯ 1. Shop.Api        src\Shop.Api\Shop.Api.csproj  (lan truoc)
   2. Shop.Admin      src\Shop.Admin\Shop.Admin.csproj
   3. Shop.Web        src\Shop.Web\Shop.Web.csproj

 ❯ mũitên/j/k di chuyen • Enter chon • so 1-3 • Esc huy

then where to put it, then a summary before anything runs:

╭──────────────────────────────────────────╮
│ Project   src\Shop.Api\Shop.Api.csproj   │
│ Cau hinh  Release                        │
│ Dich      D:\deploy\Shop.Api             │
╰──────────────────────────────────────────╯

╭──────────────────────────────────────────╮
│ ✔ Publish xong  8.4s                     │
│ File      1,204   Dung luong  62.3 MB    │
│ Dich      D:\deploy\Shop.Api             │
╰──────────────────────────────────────────╯

Terminals that cannot enter raw mode fall back to typing a number. Colours respect NO_COLOR; box-drawing falls back to ASCII on legacy Windows consoles, or set DPUB_ASCII=1 to force it.

Destination candidates come from three places: what you chose last time, <repo>/publish/<project>, and every <PublishUrl> in the project's Properties/PublishProfiles/*.pubxml. Profiles are offered, never applied silently — they drift, and a wrong destination is an expensive mistake.

The choice is written to .dpub.json at the repo root, so the next publish is dpub then Enter, twice. Add it to .gitignore; it is a per-developer convenience, not project configuration.

Options

| Flag | | |---|---| | --project <csproj> | skip the project question | | --target <dir> | skip the destination question | | -c, --configuration <name> | default Release | | --no-build | skip building the solution first | | --clean | empty the destination before publishing | | --dry-run | print what would happen, change nothing | | -y, --yes | never ask; fail instead | | --root <dir> | act on another repo |

In CI

Prompting is skipped whenever stdin is not a TTY, or --yes is passed. An ambiguous choice then fails loudly rather than hanging:

dpub publish --project src/Shop.Api/Shop.Api.csproj --target ./out --yes

Three things it refuses to do quietly

Running outside a .NET repo. It walks up from the current directory looking for a .sln, then a .csproj. Finding neither is an error, not a licence to search: pointed at a home directory it would otherwise scan the whole profile and publish whatever project it dug up.

Publishing without showing you where. The destination is always displayed and confirmed, even when there is only one candidate — publishing runs a build and writes files, so it is worth one Enter.

Overwriting a different appsettings.json. dotnet publish overwrites the one at the destination, exactly as the Visual Studio publish button does. When the destination copy differs from the repo copy — which is what a server-specific config looks like — it shows the path and asks first. Identical files pass without a word.

dpub iis

Runs the app under IIS Express, the terminal equivalent of Ctrl+F5 with the "IIS Express" profile. Site name, port and project folder are read from .vs\<solution>\config\applicationhost.config, so nothing is hard-coded. The solution must have been opened in Visual Studio at least once for that file to exist. When it holds several sites, you pick from a list.

dotnet run --launch-profile "IIS Express" is not an alternative: dotnet run only honours profiles whose commandName is Project.

License

MIT