If I understand this, Reflector Pro is just Reflector integrated with VS's debugger, so you can step through decompiled .NET code. Because other than that, the free version of Reflector (which you should definitely get) has done this stuff for years.
That seems pretty cool to me. I've never really needed to do this because well what good would it do you really unless you could change your input to not trigger the undesired behavior but it's very interesting nonetheless.
I guess you could let the 3rd party vendor know about what you found though which might be helpful to getting a new dll that's fixed whatever it was you were debugging.
> I've never really needed to do this because well what good would it do you really
ISTM it's not about avoiding triggering undesired behaviour, or "debugging" third-party code (as in finding bugs you don't own). It's about debugging your own code as invoked by third-party code - that's usually an underdocumented black box in application frameworks everywhere, where control pops in and out of your code from mysterious locations beneath the water. Figuring out the exact ordering constraints and implicit assumptions is tricky at the best of times when using trial and error; good luck trying to do that with documentation. Using the source (any readable representation of the source) is leaps and bounds ahead.
I had a coworker once that used a library of his in all of the company's main applications but kept it out of source control. If you ever asked to see the code, he would say "what do you need, I'll do it for you?" One day after chasing a bug for hours, I begged him to allow me to see the code and he refused. I calmly walked back to my desk and Reflectored it and found the bug in less than 10 minutes.
Well, I think you're underplaying the awesomeness of being able to step through library code you're using, even when you don't have the source. That's crucial for understanding overridden method and event dispatching scenarios, where your code gets called from the bowels of third-party code.
To put it another way, I think you're missing the forest for the trees, i.e. the benefits for the features, in a way that so many engineers do. The crucial feature isn't new. The benefit of this application is huge, and improves the usefulness of plain decompilation (+ analysis etc.) by about 3x IMO.
I guess I agree. I have had to debug .NET code through plugins like the Deblector before, and it's not fun. Thankfully, I don't have a job that often requires me to single-step .NET.
All I want to point out is, the capability of turning bytecode into high-level source code isn't new. It's something the free version of Reflector has done beautifully for years. If you work in higher-level languages (like Java, C#, PHP or Python), you should probably be aware that your source code is out there, even if you publish only bytecode.
I'm never going to forget the shock on the faces of my co-workers when I told them that by using reflection and looking at the bytecode/MSIL you can get pretty much anything that's in the executable. "But why does .NET allow you to access private fields? Isn't that a security hole in .NET?" They apparently based the security of their application on the assumption that an attacker cannot read private fields of their objects. Man, do I need to find another job.
What I want is Find Usages/References in code I don't have the source for without having to use FileDisassembler (and crank out the entire thing into .csprojs and .slns).
10 comments
[ 2.0 ms ] story [ 24.9 ms ] threadI guess you could let the 3rd party vendor know about what you found though which might be helpful to getting a new dll that's fixed whatever it was you were debugging.
ISTM it's not about avoiding triggering undesired behaviour, or "debugging" third-party code (as in finding bugs you don't own). It's about debugging your own code as invoked by third-party code - that's usually an underdocumented black box in application frameworks everywhere, where control pops in and out of your code from mysterious locations beneath the water. Figuring out the exact ordering constraints and implicit assumptions is tricky at the best of times when using trial and error; good luck trying to do that with documentation. Using the source (any readable representation of the source) is leaps and bounds ahead.
That is seriously anti-social behaviour, and should not be tolerated.
To put it another way, I think you're missing the forest for the trees, i.e. the benefits for the features, in a way that so many engineers do. The crucial feature isn't new. The benefit of this application is huge, and improves the usefulness of plain decompilation (+ analysis etc.) by about 3x IMO.
All I want to point out is, the capability of turning bytecode into high-level source code isn't new. It's something the free version of Reflector has done beautifully for years. If you work in higher-level languages (like Java, C#, PHP or Python), you should probably be aware that your source code is out there, even if you publish only bytecode.
I hate those things and want to see if they could have avoided them. :)