Debug + Release DLL in one package so dependent can auto-choose?

Jul 11, 2011 at 2:55 AM

This question is mostly for my use with local feeds (but may be appropriate for public feeds too?)..

Is there a way to package up both a Release and Debug DLL in one package so that when my dependent projects reference this package, they will use the Debug one vs. the Release one depending on if I'm in Debug vs. Release Solution configuration?

JD

Coordinator
Jul 20, 2011 at 5:53 PM

There is no way currently to do that. Instead, we recommend package authors make their packages use release DLLs and create a corresponding symbols package. That provides the best of both worlds in that you get the release DLL in your project, but if you need to debug into it, you get the full source available.

I understand that's only part of the problem though, since a debug build might have extra logging information. But that's what we have available today.

Jul 30, 2011 at 6:25 PM

Does this not also mean that all the release optimizations have been applied and the debugger will do things like skip inlined methods and such?  I know I've found it to be frustrating to debug in release mode historically.  You end up asking questions like "why isn't my method being called?"  Though I suppose the NuGet / SymbolSource solution also falls short here since the source cannot be opened to set arbitrary breakpoints without reaching a previous breakpoint in that file first.  Is that all correct?  If so, are there thoughts about a solution?

As mentioned on another thread, I'd also be in support of having a set of references for Debug and one for Release.

Jul 30, 2011 at 7:40 PM
patearl wrote:

Though I suppose the NuGet / SymbolSource solution also falls short here since the source cannot be opened to set arbitrary breakpoints without reaching a previous breakpoint in that file first.  Is that all correct?  If so, are there thoughts about a solution?

I agree this can be a pain with the symbol server. I wonder if there is a trick to pre-open some sources files.

Various mitigations:

  • If you ever get to step into a method in a file, it opens and you can set BPs
  • If methods in a given file are anywhere on the stack, you can get the file to open from there
  • Any file that has previously been open is in the local cache (deep in some folder) and you can directly open it
  • You can also set BPs by method names, though it can be error prone

As far as optimized code making things harder to debug, COMPLUS_ZapDisable can sometimes help with that.

Aug 2, 2011 at 7:42 AM
Edited Aug 2, 2011 at 7:50 AM

davidebbo did a great job here summing up the possibilities. I just want to add that in .NET there are no hidden differences between Debug and Release builds - no additional optimizations are applied, only preprocessor conditionals and the Conditional attribute. The entire optimization work is done during JIT, and that can be disabled by COMPLUS_ZapDisable (which, by the way, is a really cryptic name for what it does). or with an INI file: http://blogs.msdn.com/b/jaredpar/archive/2008/08/29/disabling-jit-optimizations-while-debugging.aspx