`build` vs `publish` -- can they be friends?

[richlander]

build vs publish -- can they be friends?

build and publish are the two key verbs at the base of the .NET build system. The former is for raw builds during development ("inner loop") and the latter is for producing polished builds that are ready to deploy to production. At least, that's the theory. I previously thought that this approach was flawed and have come to the conclusion that it is good.

Dissenting opinion

My basic premise has been the following:

• .NET Framework and other development platforms only offer Debug and Release as the Configuration pivot points and don't seem to require publish as yet another dimension.
• dotnet publish defaults to -c Debug. That doesn't make much sense for production builds.
• publish can kinda-sorta-or-actually break if it is different in some dimension than build or restore.
• There isn't a good split between build and publish functionality. Some publish functionality should be available via build as an option.
• Instead dotnet build -c Release could replace publish.

That remains a fair point-of-view on build vs publish.

I've written a fair bit to try and convince my colleagues that we should abandon the current scheme and instead focus on just build. Most of it has remained unpublished. In any case, I've been unsuccessful changing anyone's mind.

The value of publish

More recently, I've been working on improving the publish experience.

• Enable publishing as Release with PublishRelease #23551
• Use implicit RID for Publish Properties #26028
• Enable FDD + (implicit) RID-specific apps with RuntimeSpecific #26031

That process has demonstrated four key points to me:

• MSBuild tasks are a stronger pivot point than Configuration.
• Configuration is probably best left completely within the user domain, allowing customization beyond just Debug and Release.
• We've invested a lot into these Publish* properties and they provide a pretty good experience, particularly with the improvements coming with .NET 7.
• It would be an enormous effort (on the part of multiple parties) to change all of this, and without commensurate benefit.

There are certainly improvements that we can still make across build and publish. Model-wise, I think we've got a pretty good system.

Apparently,build and publish can be friends.

@baronfel @rainersigwald

[richlander]

This is more of a discussion. If we had that, I'd have posted there.

I think the only question is if folks agree with my assessment. We can close it once we get there.

[marcospgp]

Here's a somewhat neutral opinion from someone that isn't too deep in the .NET environment - I spent a few hours debugging why my project built with dotnet build wasn't working due to missing dependencies.

Coming into the CLI, I wasn't even aware there was more than one command that builds the project.

So there is some value in the simplicity of a single dotnet build command. Personally I'd design it as dotnet build being equivalent to the current dotnet publish, and a dotnet build --skip-dependencies as equivalent to the current dotnet build.

[richlander]

That's a good point. There are actually four different build types:

• build + Debug
• build + Release
• publish + Debug
• publish + Release

To make things simple, we have these two handy defaults (starting with .NET 8):

• build + Debug
• publish + Release

Also, we have a bunch of Publish* properties, like PublishAot and PublishTrimmed that only run with publish. That makes build a lot faster and (in some cases) make build assets easier to debug.