Scott Hanselman

Debug vs. Release - The Best of Both Worlds

February 13, 2004 Comment on this post [4] Posted in ASP.NET | Bugs
Sponsored By

Mark Pearce posted in the comments about my Debug vs. Release post some valuable tips that deserved being shared in a formal post.   Mark reminds us of the little-known little-used [.NET Framework Debugging Control] section of a {gasp} .INI file.  These help guide and control the JIT.  From MSDN:

This JIT configuration has two aspects:

  • You can request the JIT-compiler to generate tracking information. This makes it possible for the debugger to match up a chain of MSIL with its machine code counterpart, and to track where local variables and function arguments are stored.
  • You can request the JIT-compiler to not optimize the resulting machine code.

So Mark suggested this (emphasis mine):

You can have the best of both worlds with a rather neat trick. The major differences between the default debug build and default release build are that when doing a default release build, optimization is turned on and debug symbols are not emitted. So:

Step 1: Change your release config to emit debug symbols. This has virtually no effect on the performance of your app, and is very useful if (when?) you need to debug a release build of your app.

Step 2: Compile using your new release build config, i.e. *with* debug symbols and *with* optimization. Note that 99% of code optimization is done by the JIT compiler, not the language compiler, so read on...

Step 3: Create a text file in your app's folder called xxxx.ini (or dll or whatever), where xxxx is the name of your executable. This text file should initially look like:

[.NET Framework Debugging Control]

Step 4: With these settings, your app runs at full speed. When you want to debug your app by turning on debug tracking and possibly turning off (CIL) code optimization, just use the following settings:

[.NET Framework Debugging Control]

Great stuff Mark!  I'm going to go see how this would work with ASP.NET (do I use an ASPNET_WP.EXE.ini(?) and I'll probably have to recycle the ASP.NET worker process.) 

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
February 13, 2004 16:29
Now, the question is...

February 13, 2004 23:09
I makes more sense when you think about it. INI file APIs are simple, one call Win32 APIs. They need to call these APIs before the JIT gets going. If they did this as an XML file they'd need a lot of overhead, parsing, etc. just to get a boolean. This way, it's a single call to GetPrivateProfileString.
February 15, 2004 12:22
My 'lazy' logic say that coding some kind of add-in/app to do some of this automatically would be a better solution?

Finding your exe/dll/whatever, opening notepad, pasting in the information you get from somewhere (or if you're uberleet memorize it and type it out by hand), then saving the ini file seems a little time consuming when these settings don't really change.

The ini file for whatever you're debugging will always have:
[.NET Framework Debugging Control]

The only thing that will change is the 1's and 0's in the ini file itself. What will also change is where the ini file will be if the exe or dll moves locations and you forget to send the ini file with it.

I could be missing the whole point in doing things the 'old fashioned' way. There may be some all important reason to do all of this by hand but I really can't see it. I tend to question methods when they involve an ini file with 2 settings in it. Am I wrong for thinking this?
March 21, 2005 5:06
ah yes..

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.