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-2015 Red Gate Software Inc.
The only thing that is really helpful and which free tools don’t offer is the ability to debug an assembly with no PDB provided. However, Red Gate did manage to break even this only good thing with the recent update, making debugging in VS 2012 nearly impossible (extremely slow and unstable) even with no decompiled assemblies at all: http://forums.reflector.net/questions/4642/vs-debugger-extremely-slow-after-the-latest-update.html Besides that, the product has ZERO support and no ability to roll back to a previous (minor) release. In fact, there is even no such thing as a release archive. At least it is not discoverable on their AWFUL web site - just look on THAT: http://documentation.red-gate.com/display/REF8/.NET+Reflector+8+documentation (they call it “Support”, as it states on the main product page: http://www.red-gate.com/products/dotnet-development/reflector). Apparently, Red Gate concentrates all the efforts on stuffing Reflector full with bells & whistles instead of to ensure the most (and only) helpful functions just really work.
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.
My only real grump so far is the tiny "Trial" notice at the top left of this page, there should really be a notice in bold at the top of the description that this is a 14 day trial, and you'll need to buy it for £120 at the website. Fantastic addon though.
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 :) All in all - an excellent decompiler, but that needs a few enhancements of the more advanced features.
I'm using .NET Reflector and ReSharper and have source server support enabled.
Now, when I use "Open in .NET Reflector Desktop" ReSharper starts to download the PDBs and when that's done, Reflector says there is already source code on my system and opens that one in VS Studio. That is not what I would expect from a menu option labeled "Open in .NET Reflector Desktop". Please provide a separate option that will always open the specified member in .NET Reflector.
Many thanks, Michael
I have a similar issue now when I upgraded to VS 2015, whatever I try to open in Desktop is stopped by that message. The opened window in VS is showing the class "recreated" from metadata with only method signatures (I don't know the cause for this)
There is a bug in VS2015 pre-RTM that flags the VSIX download as 'Invalid certificate...' or '... contains an onsolete algorithm', depending on the method of install. It works fine for VS2013 through VS2015 RC as far as I can tell. There is a related Microsoft Connect bug that you can track for this issue: https://connect.microsoft.com/VisualStudio/feedback/details/1547846/invalid-certificate-obsolete-algorithm
So sorry you've still been experiencing issues with .NET Reflector! The only version with known chronic crashing is v8.3.0, though there is one known issue that still exists where an expired .NET Reflector trial can cause Visual Studio to crash when closing or switching solutions (apologies as I realize what an inconveniencing issue this can be!). Can I just make sure - is the extension successfully activated? (if you go to .NET Reflector>Help, it should provide an option to 'Deactivate')
If it is definitely activated though, can you kindly provide more details on how .NET Reflector is crashing VS? Does it happen as soon as you open VS/particular solutions or maybe when you enable debugging on assemblies? Are there any error details in Event Viewer?
Thanks for your post!
There's no specific support that was added for debugging WinRT solutions, though .NET Reflector will still work with them, at least for debugging into any standard managed DLLs that are referenced and used by the solution.
However, there are known issues with metadata files (.winmd), including the "Windows 8.x" reference of any WinRT solution. Reflector is unfortunately unable to decompile and debug into these. (There is a bug though that will still offer the option to enable debugging on winmd files even though the request will fail--apologies for any confusion caused by this!)
I've found an issue that I could reproduce on both machines on which I tested this:
Debug Just My Code is diabled.
When I try to attach Visual Studio debugger to the already running IISExpress process, I receive "Unable to attach to the process. Catastrophic Failure". By trial and error I finally figured out that it is related to Reflector. If the add in is disabled, attaching works.
Further analysis shows that if I set the "Just my Code" flag, attaching will work. Same goes for attaching to an IISExpress process that was previously attached to with a debugger.
Also, starting via "Debug > Start new instance" works, but of course, that's not the same as attaching to a running process.
I'm guessing that Reflector is doing something (or trying to) with the jitted code of IISExpress or the .NET Framework assemblies that won't work if the process is already running. Could you please fix this issue because working around it is a real hassle.
To me, personally, it would be okay, if the .NET Reflector addIn would offer separate options for enabling VS-Go-To-Reflector and Debugger Integration because I actually usually only need the first one.
Best regards, Michael
Thanks for your post and sorry to hear you're running into issues with Reflector!
I tried reproducing this with the specs and steps you provided but haven't been able to yet, I'm afraid.
There weren't any major changes with version 8.4 (it mainly added VS2014 support) but in case something about that version is conflicting with your machines or VS installs, can you please try reinstalling v8.3 to see if the problem persists? ftp://ftp.red-gate.com/ReflectorInstaller.zip
Can I also just check--does this happen with any application running in IIS Express?
And regarding the separate options, we used to offer different editions of Reflector that did this--I'll pass on your feedback that you'd like to bring that back. :)
Your idea with the different applications was spot on. It literally only happens when one particular page of my application was the last page processed by IIS Express right before I attach the debugger. Unfortunately, that page was also the one I most often try to debug so it never popped up anywhere else.
Version 8.3 and 8.4 don't make a difference. I did notice though, that version 8.4 still identifies itself as 8.3 in the isntaller and the Programs Window. Looks like a missed version number in the installer to me.
Anyhow, I'll keep an eye out for the issue and if I manage to triage it into a simple repro-case, I'll get back to you with it. For now, I'll just have to remember to do a different request before starting the debugger. No biggie.
Best regards, Michael
After using it only one time - (a) install, (b) checking out functionalities, and (c) deinstallating - it was not possible to use Windows SDK again.
Installing of Visual Studio 2012 failed, because of the fact .Net is not installed, BUT IT IS!
Installing of Visual Studio 2013 failed, because of the fact .Net is not installed, BUT IT IS!
I guess that this .Net Reflector has changed pathes in the registry or some assemblies which make it not possible to develop any Windows application which are using .Net!!! It's a shame!
So sorry for all this trouble .NET Reflector caused!
From your trial, do you recall if you enabled debugging on a framework assembly that required .NET Reflector to alter your DEVPATH? It sounds like the DEVPATH was altered but may not have been reset after your debugging session.
(Reflector needs to alter the DEVPATH when you enable enable debugging on a assembly that doesn't have a debugging signature. Reflector will make a copy of the assembly with the added signature and place it in the Reflector DEVPATH folder. If you don't "reset the DEVPATH" after debugging, any program that uses that assembly will continue trying to load that edited assembly from the DEVPATH folder, although .NET Reflector likely already deleted it after debugging was finished.)
I know you've already reinstalled Windows now (so sorry again for this inconvenience), but in case you ever give Reflector another try and run into this issue again, you can reset the DEVPATH from the VS menu (.NET Reflector > Reset the DEVPATH).
Or if in any case you've gotten rid of the DEVPATH environment variable, you can instead go into the Reflector distribution directory and run "RedGate.Reflector.DevPathSetter.exe /reset"
Again, my apologies that we weren't able to help with this issue in time.
Lately (possibly after updating to 188.8.131.52, VS 2012 crashes when closing a solution. I found the stack trace:
UNHANDLED EXCEPTIONS FROM PROCESS 6984:
2/12/2014 8:35:32 AM
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object parameters, Object arguments)
at System.Delegate.DynamicInvokeImpl(Object args)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
Just to confirm I'm understanding correctly, is .NET Reflector slow while you're navigating through the code via the Reflector Object Browser or is it just slow when you actually try to decompile the code (or both)?
Does it crash or hanging Visual Studio at all?