A long while ago in developer years – sometime last year in real time – the Reflector team decided to do a spike to see if we could spice up the Reflector code pane.
The Reflector code pane
At the time we were focussed on making it easier for someone to take decompiled code and understand it, in order to get to the root cause of their debugging problem. When you edit code in Visual Studio there are many tools for helping you understand the flow of data of data through the methods. Since we generate the decompiled code, we know lots of information about the code and its relationship to other decompiled methods, and so we should be able to make this information available to users of Reflector in the form of some kind of head up display.
Here’s a quick preview of something Clive is busily prototyping:
Translating values on hover
Toggling values in and out of hex for easier comprehension was a small but frequent request in user tests, and it felt like a nice place to start. So here it is on hover – we’ll keep you posted on how we get on.
There’s some other stuff we’re considering, too: something to highlight data flow, maybe, or make it easier to see variables move through decompiled code. But this was a good, simple place to start.
Let us know if there’s anything you’d like to see.
Last week, we worked on polishing up the .NET Obfuscation checker, and by the end of the week, the beta was ready to ship. We’ve posted it up on Red Gate’s “Labs” site – a place for experimental tools and small free widgets.
Version 7.7 of .NET Reflector was released only a couple of weeks ago, and we’ve been working on many changes. The most prominent of these was integrating the power commands into the tool (you can find details of the earlier release here). We’ve since been working on the next version of Reflector, version 8. The goals here are making it easier and faster for people to find bugs and understand third-party code by improving the static code analysis inside the desktop version of the tool and improving the route into debugging. The current beta is a step forward towards achieving this goal for Reflector 8.0.
One of the most significant improvements we’ve made to Reflector is attaching a search filter to the assembly browser. You can now dynamically search for any implementation within the list of assemblies loaded in the assembly tree view.
.Net Reflector 7.7 is going to have a fairly quick turn around and a short beta period, as we’re looking to release later on this month. We’ve mostly been fixing bugs and tidying things up but there are probably a couple of things of note that are worth mentioning.
Visual Studio 2012 is slated to ship soon, and when it does, Reflector will be sim-shipping right there alongside it. As part of our work to support the newest technologies from Microsoft (C# 5, WinRT, .NET 4.5) we’ve been working on Visual Studio 2012 integration and the new theming styles.
Nigel, our developer who’s been doing most of this UI coding, tells us a bit more about the work involved and how he did it:
We’ve been a bit quiet on the EAP front recently, and there’s a reason for that. The rest of the team and I feel like we’ve spent the last fortnight locked in a meeting room. In hindsight, that’s substantially because we have. All I can see when I close my eyes is post-it notes, but we’re getting a lot closer to scoping out version 8 of Reflector.
V8 is all kinds of exciting, but still very much at the on-paper stage. But somehow, in the midst of all the planning, and sketching, and brainstorming, and well-intentioned bickering, Clive, Nigel, Ruchika, and Nick have shipped a new EAP.
The version 7.6 EAP is the first slice of our support for Visual Studio Dev 11, .NET 4.5, and C# 5
Reflector’s Visual Studio integration is now working in Dev11, so you can decompile code and start to debug it within the new VS beta. You can explore the changes in the .NET 4.5 framework too, and Clive has a blog post coming about this shortly.
Because it’s our first EAP, it’s not all up and running yet. For example, we aren’t currently decompiling the new C# async/await construct, but we’ll be fleshing out the C# 5 support in the coming releases.
The trouble with having a code base that you didn’t write yourself is that you’re often surprised to discover features that you’ve never seen before. I had this revelation some time ago when I was looking through the Reflector code, and had a close look at the IAssemblyManager interface: