Why bother with dotnet build before dotnet publish?

Question

Welp. This seems like the type of question where I'll facepalm seeing the answer.

So...

Why bother with dotnet build before doing a dotnet publish?

build automatically does a restore. Cool.

It seems publish does a build (unless you tell it not to). So... Why bother doing the build if you're going to publish right after? Why not just publish and everything happens in one step?

For further clarity...

I am asking in a basic scenario like:

• dotnet build -c Release MyProj
• dotnet publish -c Release -o /somedir MyProj

versus just

• dotnet publish -c Release -o /somedir MyProj

They seem to do the same thing.

Answer 1

You are right that dotnet publish automatically does everything dotnet build already does. In most cases - as in your scenario mentioned in the question - that means an additional dotnet build is not necessary.

Do note that you can dotnet build a solution, but should only dotnet publish individual project files. Publishing solutions likely leads to unexpected results (from overriding files of different versions to publishing library projects in configurations that should not be published to the same output directory as referencing applications etc.)

Over time there was a community ask to allow both publishing and testing without potentially rebuilding the app, because some users felt more comfortable only ever publishing an application with the same binaries that have been tested so their build scripts can look like:

1. dotnet build the.sln -c Release
2. dotnet test -c Release --no-build
3. dotnet publish the\app.csproj --no-build -c Release