Currently, I package the release builds with Nuget for the official builds to nuget.org, but I package the debug builds with Nuget for the symbol source pushes to symbolsource.org.
EDIT: (Jon Skeet, with some bias from Noda Time development)
NuGet now supports pushing to both NuGet gallery and symbolsource.org (or similar servers), as documented. Unfortunately, there are two contradictory requirements here:
That would be fine, but NuGet doesn't (as far as I can tell) allow both the release and debug builds to be published in a useful way, in the same package.
So, the choices are:
The first two really boil down to the effect of the differences between debug and release builds... although it's worth noting that there's also a big difference between wanting to step into the code of a library because you want to check some behaviour, and wanting to debug the code of a library because you believe you've found a bug. In the second case, it's probably better to get the code of the library as a Visual Studio solution and debug that way, so I'm not paying too much heed to that situation.
My temptation is to just keep with the release builds, with the expectation that relatively few people will need to debug, and the ones who do won't be impacted much by the optimizations in the release build. (The JIT compiler does most of the optimizing anyway.)
So, are there other options we hadn't considered? Are there other considerations which tip the balance? Is pushing NuGet packages to SymbolSource sufficiently new that "best practice" really hasn't been established?
In general, ALWAYS deploy Release builds to production. Debug will add to your assembly weight and degrade performance.
Lots of your code could be completely removed or rewritten in Release mode. The resulting executable will most likely not match up with your written code. Because of this release mode will run faster than debug mode due to the optimizations.
Release mode is way more slower than debug mode for user defined functions.
It's because the optimizer schedules registers completely differently, trying to make code run fast, while the debug compiler tries to preserve values of temporary variables so you can read them from the debugger.
Speaking for SymbolSource, I believe that the best practice is to:
While we're at it, it is a common misconception that release and debug builds in .NET really differ much, but I am assuming that the differentiation is here because of various code that might or might not be included in either build, like Debug.Asserts.
That said, it is really worth pushing both configurations to SymbolSource, because you just never know when you're going to need to debug production code. Remotely in production to make it harder. You're going to need the help you can get from your tooling when that happens. Which I obviously do not wish upon anyone.
There is still a matter to consider regarding versioning: is it correct to have 2 different packages (build in debug and in release) sharing 1 version number? SymbolSource would accept that, because it extracts packages and stores binaries in separate build mode branches, IF ONLY NuGet allowed to tag packages accordingly. There is no way at present to determine if a package is debug or release-mode.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With