Experience with .NET Reflector Pro

Question

Does anyone have experience with .NET Reflector Pro (not the free version)?

I have searched for some way to easily debug an application in an external environment (e.g. a production server that is out of the office), and I found .NET Reflector Pro and its feature "Step into decompiled assemblies and use all the debugging techniques you would use on your own code".

It looks very useful, but I would like to hear about personal experience with the tool ... especially from people who are using it "every day".

Thanks!

EDIT: Some additional information: I would like to use this feature for debuging the old versions of a modular application (100+ modules in several versions) for hard-to-reproduce bugs that don't show up in a testing environment (e.g. combination of data in the database, current configuration of the server/client, etc.).

There is a way to rebuild the specified assemblies (sometime there are dozens of assemblies required) ... adding some issue-specific logging information. But, it takes a long time instead of easily debugging and looking at things such as local variables, fields, threads, etc.

Sherrillsherrington

Answer 1

Just ran across this post ... but I do have experience with .NET Reflector Pro. Overall, the debugging feature can really save your bacon (i.e. help you out) at times.

In fact, I recently wrote a blog post on how to debug the .NET Framework source code using .NET Reflector Pro. This post will definitely give you some insight into my own experiences with the tool.

http://www.cplotts.com/2011/01/14/net-reflector-pro-debugging-the-net-framework-source-code/

I would also say that you might be hard pressed to find someone who uses the debugging feature every day. I use it only when I have to debug (or gain some insight on) very hard problems that are likely not in my own code but in the .NET Framework or some third-party assembly.

Some might argue, "Why wouldn't you just use Visual Studio's native support?" Well, I do ... if I can, but not every assembly is supported. Also, sometimes the released bits get out of date with what's available on Microsoft's public symbol server ... that is, even the supported assemblies, aren't supported at certain times.

Of course, .NET Reflector Pro also allows you to debug third-party assemblies where you have no access to the .pdbs and/or the source code. My blog post will be helpful in these situations as well. The post is a pretty generic 'how to' post on using the debugging feature.

One obvious thing to point out/emphasize (as others have noted already), is that the debugging capabilities of .NET Reflector Pro can only be used from within Visual Studio. So, Visual Studio must be installed on the machines you are trying to debug on. Most production environments don't have (or allow you to install) a development environment on these machines. Therefore, it may not even be possible to use .NET Reflector Pro in your particular scenario.

The free version of .NET Reflector only needs to be copied somewhere in order for it to work, so you could (at least) analyze (but not debug) the assemblies you are interested in.

Hack

Answer 2

It does look pretty cool, but I doubt that it will be useful very often.

Most of the time the bug is probably in my own code for which I have source, PDBs and the lot, so I don't need Reflector for that. With the option to debug Microsoft framework code I don't need Reflector Pro for that either. So the use case for Reflector Pro seems to be debugging third party libraries. Obviously these will be the source of some bugs from time to time and in those cases Reflector Pro may be worth its price.

However, the "only" thing it adds is the ability to seamlessly debug these. You can still look at the code with the plain vanilla edition of Reflector. In my experience that is enough in most cases.

I admit that I could be wrong here, but my gut feeling is that the free edition will be enough for a lot of users. In any case, I am in no rush to pay $200 for that specific feature.

Paregmenon

Mainly I agree with your opinion. But there is several issues where remote debuging would be very, very, time saving ability. Look at my "EDIT" in question. However thanks for reply. – Sherrillsherrington

Good point. As I said I may be wrong. The above is just my immediate response. – Paregmenon

I do think that Red Gate charges TOO MUCH for this one feature ... but, when you really need it ... you really need it. – Hack

Answer 3

In the link you posted, it is written this "NET Reflector Pro is an add-in to Visual Studio that lets you debug third-party code and assemblies, even if you don't have the source."

So, you can use it only on a development machine ... because I doubt the user has Visual Studio on a production machine.

Firedog

Answer 4

I use .NET Reflector Pro and use the "Step into decompiled assemblies and use all the debugging techniques you would use on your own code" feature quite heavily. Here's a couple of examples:

Citrix XenServer:

We use Citrix XenServer and automate many processes using the C# Xen API. Sometimes it's not obvious from the documents how best to use the API to perform certain functions (such as snapshot management).

Citrix XenServer comes with an administration front end called XenCentre. XenCentre is a .NET Windows Forms application that leans heavily on the Xen API and SDK tools. Whilst the application isn't open source they haven't obfuscated it. I use Reflector Pro to step into their code, set break points etc so I can understand the Xen API better.

It's a very very useful tool for me and was well worth the money (in fact I purchased mine when they had an offer running so it only cost me 46.00 euro's). I've saved countless hours because of this feature rather than just having a static disassembled view of the code (ala vanilla .NET Reflector) to work with, or waiting around to have questions answered by their support team (who are very good, but "teach a man to fish"....) or on their forums.

IIS Metabase Explorer 1.6:

Another good example of where the tool came in handy was with the IIS6 Metabase Explorer 1.6 tool. I needed to understand how to call into the IIS6 ABO (Admin Base Objects) COM API from a .NET application. As luck would have it, it turns out that this version of the Metabase Explorer is a .NET Windows Forms application with a managed interop wrapper around the ABO API.

Using the "step into" feature I was able to gain an understanding of how to use the ABO API from .NET, set break points, examine live variables etc. Again, this shaved a fair few hours off of what was becoming a fairly torturous task (the ABO API isn't exactly well documented or friendly).

In conclusion, unless you have an actual need to go poking about someone else's code AND you need to be able to set breakpoints and see the application's state at runtime, then the basic tool may be sufficient for your needs. However, more often, I seem to find myself needing to see what an application or library is actually doing and it's "live" state. Without getting into the rights and wrongs of RedGate's latest antics with .NET Reflector, from a mercenary point of view it's been damned useful.

Tobietobin

Answer 5

I find I don't debug into compiled assemblies often, but when I need to do so, it usually occurs in a two-day stretch in which, I believe, not having it would result in double the calendar time.

It can sometimes take awhile for Reflector Pro to scan the assemblies for a debug session, but this state is kept around, which is good, and the scanning occurs in the background.

I came across your post as I was hunting down an issue wherein errors show up in Visual Studio's Error Window for assemblies Reflector Pro had decompiled. These are meaningless to my application development (and don't prevent the app from compiling) but add some clutter to that window. After a bit more research, this may end up being another SO question.

Vicissitude

The errors seem to only pop up when the generated source file for the third-party assembly is open in the editor (e.g. due to a breakpoint hit). – Vicissitude

Answer 6

debugging in disassembled libraries saved my ass while searching for a weird behavior in some SharePoint SPFieldUser. I spent several days on it and I wouldn't have solved it for sure without the ability to step through the control lifecycle and see which properties affect what behaviour during specific phases. truly a lifesaver!

Aguste

Answer 7

You might want to ask your questions on the forum that Red-Gate watches for the product: http://www.red-gate.com/messageboard/viewforum.php?f=85

Miyamoto

Best here IMO. He's asking the opinion of users not Redgate and how many users will visit that forum more than a couple of times? – Footloose