pdb-only debug information option
September 3, 2005In Visual Studio 2005, you now have the ability to use the pdb-only debug information option. This underestimated debug option is available for the command- line C# compiler, but could not be configured through Visual Studio 2002/2003 (only enable/disable debug information). This is finally possible with Visual Studio 2005 by clicking the Advanced button on the Build page of the project properties. There you have the option Debug info. What is the use of this extra feature? First of all, let’s get through some background information.
When having a project in Visual Studio, you can perform a debug build (default) that is used throughout the development stage or you can use a release build. This release build outputs the binaries that are used in the production environment. Now I always considered using debug information in release builds as a best practice. You can remotely debug your software in production when a problem occurs or when a bug has been noticed. It’s a tricky business with the optimize switch turned on, but it’s still better than nothing. A small performance penalty is imposed when doing this but in most of the cases this is an acceptable offer. When debug information is turned on, a .pdb file is automatically generated containing the necessary debug information. This .pdb file maps the IL code that is generated by the compiler to the original source code.
But the Visual Studio debugger needs more information in order to debug your application. The mapping described above is only half the work. The JIT compiler, which translates IL code into native machine code, needs to create a mapping between the generated machine code and the IL code. This is accomplished by decorating the assembly with the Debuggable attribute, whose IsJITTrackingEnabled property needs to be enabled. When the JIT compiler loads the assembly it looks for this attribute. When this IsJITTrackingEnabled property is enabled, a slight performance penalty is imposed. In most cases this is not an issue because the JIT code is compiled only once into native machine code. Once a method has been JIT compiled, no additional costs are associated. So far, so good.
There are some situations though, where these additional costs are not allowed when your application is running in the production environment unless your application is experiencing a problem. Here is where the pdb-only debug information option comes in. A .pdb file will be generated as usual, BUT the IsJITTrackingEnabled property will NOT be enabled. The application will run without the generated tracking information by the JIT compiler. No performance penalty is implied.
When you want to debug your application, you can enable the IsJITTrackingEnabled property in two ways:
-
Creating an ini-file with the same name as the assembly you want to debug:
f.e. MyApp.exe -> MyApp.ini
[.NET Framework Debugging Control] GenerateTrackingInfo=1 AllowOptimize=0
-
Using the debugger (opening an existing project of type executable(.exe) and selecting the executable you want to debug).
With this option, everybody wins. The application runs without the extra penalties of debug information and when necessary the application can be debugged.
Only one exception to this is with applications that are being executed in a seperate worker process like ASP.NET (aspnet_wp.exe). I know for sure that all this wasn’t possible with versions 1.0/1.1 of the ASP.NET runtime, but I don’t know if version 2.0 of the ASP.NET runtime provide a means of setting the debug options at run time. I’ll have to find out. I will make a sequel to this post if I have some new information regarding this matter.
Questions? Remarks? Please let me know.
Greetz
If you and your team want to learn more about how to write maintainable unit tests and get the most out of TDD practices, make sure to have look at our trainings and workshops or check out the books section. Feel free to reach out at info. @ principal-it .be
Jan Van Ryswyck
Thank you for visiting my blog. I’m a professional software developer since Y2K. A blogger since Y2K+5. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Past organizer of the European Virtual ALT.NET meetings. Thinking and learning about all kinds of technologies since forever.
Comments
Writing Maintainable
Unit Tests
Watch The Videos
Latest articles
-
Contract Tests - Parameterised Test Cases
June 28, 2023
-
Contract Tests - Abstract Test Cases
April 12, 2023
-
Contract Tests
February 1, 2023
-
The Testing Quadrant
June 15, 2022
-
Tales Of TDD: The Big Refactoring
February 2, 2022
Tags
- .NET
- ALT.NET
- ASP.NET
- Agile
- Announcement
- Architecture
- Behavior-Driven Development
- C++
- CQRS
- Clojure
- CoffeeScript
- Community
- Concurrent Programming
- Conferences
- Continuous Integration
- Core Skills
- CouchDB
- Database
- Design Patterns
- Domain-Driven Design
- Event Sourcing
- F#
- Fluent Interfaces
- Functional Programming
- Hacking
- Humor
- Java
- JavaScript
- Linux
- Microsoft
- NHibernate
- NoSQL
- Node.js
- Object-Relational Mapping
- Open Source
- Reading
- Ruby
- Software Design
- SourceControl
- Test-Driven Development
- Testing
- Tools
- Visual Studio
- Web
- Windows
Disclaimer
The opinions expressed on this blog are my own personal opinions. These do NOT represent anyone else’s view on the world in any way whatsoever.
About
Thank you for visiting my website. I’m a professional software developer since Y2K. A blogger since Y2K+5. Author of Writing Maintainable Unit Tests. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Thinking and learning about all kinds of technologies since forever.
Latest articles
Contract Tests - Parameterised Test Cases
Contract Tests - Abstract Test Cases
Contract Tests
The Testing Quadrant
Contact information
(+32) 496 38 00 82
info @ principal-it .be