I see this question come up from time to time in the .NET Reflector mailbox, so I’m going to make a stab at a sensible answer that’s more than just a some marketing fluff piece, because there are alternatives, although it’s debatable how realistic they are.

You basically have three options:

1. Create a debug build of the assembly you’re interested in using the generated source code.
2. Use the Deblector add-in from within .NET Reflector.
3. Wait for .NET Reflector Pro, or at least an early access build of the product-should be available in the next month or two-and use that instead.

If you’ve been following my previous posts, you’ll be aware that it’s possible to decompile an entire assembly, and even generate a Visual Studio project for the decompiled source:

http://www.simple-talk.com/community/blogs/bart/archive/2009/07/30/74199.aspx

http://www.simple-talk.com/community/blogs/bart/archive/2009/07/31/74222.aspx

So, at least in theory, you should be able to fire up Visual Studio and build a debug version of the assembly you’ve decompiled (option 1). There are a couple of reasons this probably won’t work, which I’ll talk about below, but let’s assume for a minute it does work; what you then need to do is substitute any references to that assembly in your project with references to the debug version. Then, when you’re debugging, you can set break points in the generated code and debug it, just as you would any other source code.

OK, sounds good, so why is it unlikely to work?

• .NET Reflector may not be able to decompile everything in the assembly, or may generate some source code that isn’t quite correct, or won’t recompile. Many of the reasons for this are discussed at http://www.simple-talk.com/community/blogs/bart/archive/2009/07/30/74203.aspx. Thus, you’ll get build errors in Visual Studio when you try to recompile the assembly, unless the code in the original assembly is relatively simple and was compiled from an OO/imperative language, such as C# or VB.
• If the assembly you’ve decompiled is used by other assemblies that you haven’t decompiled, they probably won’t work with the debug build you’ve created, even assuming it recompiles successfully. To get around this you’ll need to decompile all of the other assemblies that reference the assembly you’re interested in, and then recompile them against the debug build you’ve created. The chances of this working are minimal.

So, option 1 is probably out.

Option 2 involves using Deblector to debug the assembly from within .NET Reflector itself. You can find Deblector here:

http://www.codeplex.com/deblector

The downside here is that documentation is sketchy and there hasn’t been any activity on the project since early 2008, which makes me think it’s probably dead.

Option 3, which isn’t really an option yet, if I’m completely honest, is to use .NET Reflector Pro. If all goes well, I’d like to see an early access build out there that you can use within the next month or two. As any of you who have used our early access builds before will know, they’re generally pretty usable, albeit with bugs in them, but I’d say this is probably your best option in the longer term.

EDIT: .NET Reflector Pro is now in beta. Download instructions are available here: http://www.red-gate.com/messageboard/viewforum.php?f=109.