StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POBest practices with Nuget: Debug or Release?
text
Body
copied!<p>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.</p> <p>EDIT: (Jon Skeet, with some bias from Noda Time development)</p> <p>NuGet now supports pushing to both NuGet gallery <em>and</em> symbolsource.org (or similar servers), <a href="http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-symbol-package">as documented</a>. Unfortunately, there are two contradictory requirements here:</p> <ul> <li>When just <em>using</em> a library without any need for debugging, you really want a release build. That's what release builds are for, after all.</li> <li>When debugging into a library for diagnostic purposes, you really want a debug build with all the appropriate optimizations disabled. That's what debug builds are for, after all.</li> </ul> <p>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.</p> <p>So, the choices are:</p> <ul> <li>Distribute the debug builds to everyone (as shown in the example in the docs) and live with any size and performance hits. </li> <li>Distribute the release builds to everyone and live with a slightly impaired debug experience.</li> <li>Go for a really complicated distribution policy, potentially providing separate release and debug packages.</li> </ul> <p>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 <em>as a Visual Studio solution</em> and debug that way, so I'm not paying too much heed to that situation.</p> <p>My temptation is to just keep with the release builds, with the expectation that <em>relatively</em> few people will need to debug, and the ones who do won't be impacted <em>much</em> by the optimizations in the release build. (The JIT compiler does most of the optimizing anyway.)</p> <p>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?</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload