You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
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.
buildvspublish-- can they be friends?buildandpublishare 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:
DebugandReleaseas theConfigurationpivot points and don't seem to requirepublishas yet another dimension.dotnet publishdefaults to-c Debug. That doesn't make much sense for production builds.publishcan kinda-sorta-or-actually break if it is different in some dimension thanbuildorrestore.buildandpublishfunctionality. Somepublishfunctionality should be available viabuildas an option.dotnet build -c Releasecould replacepublish.That remains a fair point-of-view on
buildvspublish.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
publishMore recently, I've been working on improving the
publishexperience.ReleasewithPublishRelease#23551PublishProperties #26028RuntimeSpecific#26031That process has demonstrated four key points to me:
Configuration.Configurationis probably best left completely within the user domain, allowing customization beyond justDebugandRelease.Publish*properties and they provide a pretty good experience, particularly with the improvements coming with .NET 7.There are certainly improvements that we can still make across
buildandpublish. Model-wise, I think we've got a pretty good system.Apparently,
buildandpublishcan be friends.@baronfel @rainersigwald
The text was updated successfully, but these errors were encountered: