Enable publishing as `Release` with `PublishRelease`

[richlander]

Enable publishing as Release with PublishRelease

The following proposal has been replaced with this new (non-breaking) plan: #23551 (comment)

[breaking] dotnet publish/pack produce Release assets by default

Proposal: Default to Release builds for CLI commands that are strongly aligned with production deployment. Release builds are faster, and debug builds are not supported in production.

That means:

• Fewer Debug artifacts would be deployed into production. Developers would not have specify as much via the CLI to do the right thing.
• Some developers would be surprised during debugging (builds would be optimized and less debuggable) but there would be an easy workaround to resolve that (opt into debug mode).

Context

Our basic guidance to developers since .NET Core 1.0 has been "use build for development and publish for prod". Given that, it would make a lot more sense if publish defaulted to a release build. Debug builds run observably slow (sometimes you can see this with just your eyes; no stopwatch required). It is near certain that plenty of .NET apps are deployed as debug due to the current defaults. The CLI would be much better if it offered more differentiated options. There should probably be a more broad re-assessment of build and publish but I'm not digging into that here. I'm proposing a much simpler change (that doesn't preclude broader changes later; in fact, this change would encourage them).

pack is a bit more nuanced since there is no duality set of commands for it, no build and publish analogues. There is just pack. In fact, the same could be said of libraries in general. I assert that most developers go through their debug cycle with their NuGet library as just a library, then pack it and upload it to their NuGet server/feed of choice. In that workflow, pack defaulting to Release would be preferred. I haven't done the exercise, but it would interesting to see the split between Release and Debug libraries on NuGet.org. There should be none (except for some very specific scenarios).

There absolutely is a Debug scenario with NuGet packages and with pack. I'm guessing that it is <10% case. The scenario would be that developers build their package as Debug, deploy to a feed (which could just be a disk location), then run tests (in one form or another), and use the debugger in library code to determine library behavior. For that to work really well, they may have to use SourceLink. I haven't tested the non-SourceLink flow for a Debug NuGet package (where I have matching source) in quite some time. That's a detail to explore. The primary point is that debugging NuGet packages is a bit more involved than debugging ProjectReference libraries, so it probably happens a lot less often.

Zooming out, we should ensure that we have good gestures and good guidance for:

• Do this simple thing for the best local debug experience.
• Do this simple thing for the best prod experience.

I assert that our system is too biased to debugging and insufficiently focused on building optimized prod artifacts. At the end of the day, it's all about a great prod experience, so we should focus more on prod ergonomics. This concern isn't novel. I've heard developers complain about this exact issue for years, but no one (AFAIK) has ever written it up to resolve that.

[JonDouglas]

/cc @dotnet/nuget-team

[dasMulli]

Suggest explictily using uppercasing in text - Release / Debug - to avoid confusion and people running into breaking scenarios with case-sensitive filesstems such as in hosted linux-based CI or container scenarios. (#375, #9230, #1204)

[joeloff]

Today the default is selected based on the project's default, this is what you want to change/break, correct @richlander

[richlander]

Yes and no. By default, the default is Debug. If we made this change and someone had <Configuration>Debug</Configuration> in their project file, it should remain Debug. I'm not proposing to change that.

Or do I misunderstand?

[nagilson]

If I am understanding correctly, the considered breaking nature of this change is best described here: #10357 (comment) (TLDR: Some customers may expect and rely on publish to default to the debug configuration and we will be removing that)

[richlander]

Interesting. I like this solution: #10357 (comment).

.NET has always suffered from a lack of global/repo config (like what git has). This property seems like a poster child for that.

Perhaps, we should should create a new property PublishConfiguration. It would match all the other Publish* properties, like PublishTrimmed. This property could then be added to more global configuration, like Directory.Build.props.

Stating the obvious, it would look like this:

<PublishConfiguration>Release</PublishConfiguration>

Sound good?