Enable publishing as `Release` with `PublishRelease`

Enable publishing as Release with PublishRelease

The following proposal has been replaced with this new (non-breaking) plan: https://github.com/dotnet/sdk/issues/23551#issuecomment-1176765107

[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.

[richlander]

To my mind, the proposed properties are better, for two reasons:

• We already have the Publish* scheme, and this approach matches it.
• Publish* and Pack* obviously contrast with build. It’s unclear when _ShouldDefaultToRelease would be effective. We don’t want it to be effective for dotnet build.

[eatdrinksleepcode]

@richlander @nagilson We use configurations to build for different deployment targets. For example, we have a separate configuration for building a version of our app that is designed to run on an AWS AMI. We recently added configurations for creating a FIPS-compliant version of our app by excluding non-compliant code. There are more examples.

For most folks, I think a boolean property is best.

I agree that most people stick with the default “Release” configuration (though my experience is that this is becoming less true since SDK-style projects have encouraged people to actually understand and own how their build works). But I don’t think that <PublishConfiguration>Release</PublishConfiguration> is any harder or less usable for those people than <PublishRelease>true</PublishRelease>; but it has way more utility for people who do customize their build configurations.