More From Red Gate
.NET Reflector Visual Studio ExtensionTrial
Integrates .NET Reflector into Visual Studio to allow you to seamlessly debug into third-party code and assemblies, even if you don't have the source code for them. Visit www.reflector.net for more information. Copyright (c) 2009-2013 Red Gate Software Inc.
Q and A (2)
Sign in to Write a Review
A great tool!
.NET Reflector Visual Studio Extension v7.0 or later installed, Visual studio 2010 SP1 often no response
I liked the tool as it was a free one by Lutz Roeder. Nowadays I would not pay for It, as the benefit to free tools (JustDecompile, CodeReflect, ...) is to marginal for me.
Wow I knew you could de-compile .dlls and things to an extent, as in get a basic list of the procedure calls and references, but the depth of this blows my mind. Never thought you'd be able to de-compile and see the EXACT code right there. Granted it isn't AS nice as working with it in your own solution, but wow it is certainly helpful to see what exactly is happening behind the scenes. Great for debugging 3rd party .dlls that just return a "No" when something's not working, and a godsend for retrieving some code from .exes where a dev hadn't backed up the source. Also nice to see how Microsoft does things when you're making calls to the framework components.
There are quite a few decompilers out there, but I think this is the only one that allows you to debug 3rd party dll's at runtime (given they aren't obfuscated...) - you can go step by step, step into, and everything else, just like it's your own code (it creates a debuggable clone of the assembly that enables this). This is very powerful option, but, having said that, it doesn't work quite nicely. The code it displays as "current execution line" isn't the one that's executed (like when you get when source code differs from debugging exe/pdb, when code is optimized etc), so you always have to look e.g. 7 lines above the currently displayed to see where he's at. Furthermore, it breaks in files where there's no break but it's breaking there just because they're calling the line in a file that has it. It's all minor issues, but mighty annoying at that... some assemblies might work without issue, mine haven't :)
Since version 7.6 the installation for Visual Studio 2010 fails with the error message "The specified path, file name, or both are too long. The fully qualified file name must be less then 260 characters, and the directory name must be less than 248 characters."
Red Gate August 03 2012
Ah, yes - that's a broad issue that hits a few VS Extensions. We're aware of that error and working on get it cleared up.
Sign in to Start a Discussion