Digging Into the .NET Framework Code

Every developer has had one of those head-scratching moments while debugging a particularly problematic section of code and thought “I really wish I could see exactly what is going on inside the .NET Framework library.”

If you haven’t heard of Lutz Roeder’s .NET Reflector program, I highly recommend heading over to his site and downloading it. It’s one of those tools that every .NET developer simply must have in their arsenal of tools.

The program lets you open any .NET-compiled EXE or DLL file and see everything inside. You can browse the classes and methods (public, private, internal, you name it), as well as navigate through the disassembled code using the automatic hyperlinks. It even lets you browse embedded resources as well as search for strings.

As if that wasn’t powerful enough, there exist many useful add-ins that greatly enhance Reflector’s functionality. For example, if you find yourself jumping around between many sections of code trying to figure out what’s happening, it may be helpful to completely decompile the entire assembly to source code and load it up in Visual Studio. This amazing feat is accomplished using the FileDisassembler add-in. I’ve used this a number of times and it is extremely helpful.

And, to top everything off, if looking at the code isn’t enough to really get a feel for the inner workings of the BCL (base class library), then why not just debug the code directly? Visual Studio 2008 has the ability to directly debug the .NET Framework Library code. Check out Shawn Burke’s step-by-step explanation of how to set this up. Right now only mscorlib, the WinForms libraries, and the WPF libraries are available, though WCF, Windows Workflow, and LINQ libraries should be released soon.

I have mixed feelings about the availability of the code. On one hand, it is a huge productivity enhancement since you can really dig deep into the code and discover hard-to-find bugs and side effects with your code. It’s also a great learning tool to see “best practices” for implementing things like events, event handlers, exception handling, etc.

However, it also makes the code available in such a way that copy/paste is incredibly tempting. In the back of my mind, I keep having this nagging feeling that by looking at the code I’m somehow breaking a EULA, and if (heaven forbid), I accidentally copy/paste a snippet of code out of the .NET Framework code that I will be sued for intellectual property infringement. It’s even worse when you think about the repercussions that could happen if I was working on an open-source project (there are several I have been involved with in the last few years). Sometimes I wish I was a lawyer to fully understand the situation — in the meantime I suppose I’ll just continue being slightly uneasy with the whole ordeal, enjoy the benefits of being able to debug the code, and make a mental note not to copy/paste anything out of the .NET Framework code.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

AddThis Social Bookmark Button

One Response to “Digging Into the .NET Framework Code”

  1. [...] Digging into the .NET Framewok Code.  Matt discusses using Reflector to view or another technique to directly debug .NET framework [...]

Leave a Reply