We’ve just finished the first of our sprints towards .NET Reflector v7.5, and have released an EAP build for you to take a look at. The first thing we wanted to do is move Reflector’s GUI into Visual Studio to make it easier to explore assemblies without having to leave the confines of Visual Studio. We got some of the way there during this sprint, so let’s look at that first…
But first! Before we dive into the details, I should mention that we’re putting together a bona fide Early Access Programme, so if you’d like help us improve .NET Reflector, drop an email to email@example.com with EAP in the subject line. Now to business: We’ve added the appropriately named “Reflector Object Browser” into Visual Studio, where you can launch it from the View menu or via the .NET Reflector menu. It currently starts up with the 2.0 and 4.0 versions of mscorlib loaded into the tree, mainly so that we could test that we could have two different versions of mscorlib loaded side-by-side. You can navigate the assembly in the same way as in the standalone product, so that should be very familiar. The resource browser has also been integrated, so you can double-click the node representing a resource, and the resource will be displayed in the usual fashion as you can see to the left.
Unfortunately, in this initial sprint we didn’t have time to integrate decompilation on demand, so if you double-click the node corresponding to a method or class, we will currently only show an editor tab displaying the source if you have previously decompiled it.
In the more usual case, you’ll get a temporary file which will display the code URL representing the item you wanted decompiled. Naturally, we’ll be wiring this up to dynamically decompile the selected item in a future sprint.
In older versions of the add-in, we had the browser for the .NET Reflector Decompiled Assemblies (see below), but the idea here is that the Reflector Object Browser will be pre-loaded with all of the assemblies that the project references, and they will be decompiled on demand if they have not been previously decompiled. This existing browser will go away at some point in the future.
So now let’s take a quick look at the other pieces of work we’ve been looking at as part of this sprint:
- We started automating more of our tests. Ruchika started automating two test scenarios, one for the standalone product and the standard demo we use for Reflector pro (You’ve probably seen it on the Red Gate web site – the library that calculates the n’th Fibonacci number but which we have lost the source code for. We’ll be able to run the automated tests overnight to get automated coverage for some scenarios.
- Nick spent time getting our automated tests for the decompilation and pdb generation running overnight…
- …and Nigel and I had a great time working on the GUI and various infrastructure tasks.
Of course, a number of forum reported bugs were also fixed:
We’d had a number of reports about the “open in .NET reflector” context menu item not working; We’ve fixed this, and also fixed some problems with the BAML decompilation.
In previous releases, the Reflector Core has had a fixed version number to support add-in, and in the past this was fixed at 188.8.131.52 or 184.108.40.206. We use automated error reporting technology (SmartAssembly) and this fixed version for the Core meant that the software found it difficult to track whether a bug really is fixed.
When we fix a bug, we note the build number in which it was fixed. A SmartAssemby-to-Jira importer can then check incoming reports, deduce if they happened in the period when the bug was outstanding, and then only reopen the bug if we find it present in a build when it ought to have been fixed. The core version will now change, and we use a trick that Bart blogged about before to allow add-ins to load into a different version of Reflector. We’d be grateful if add-in authors could check that this works in the EAPs!
Various decompilation and assembly loading problems have also been fixed as part of this work. Personally, I would very much like to get a batch of C# decompilation work into the next sprint, including some code that would allow Reflector to handle a large range of new code patterns, though since we’re Agile we won’t know if this is going to happen until sprint planning happens 😉
You can download the results of our labour, down at the foot of the home page (or, if you’re in a hurry, you can download the file right from this post). This EAP is a little bit of a damp squib, in that we’d love to have the Reflector Object Browser fully plumbed into the system to give you more to play with. However, we’d be really grateful for any feedback you can give us on what you can already see, to help give us a nudge in the right direction! 😉
And finally… because it’s Friday, I had to include this picture Chris managed to snap of Nigel doing his “Build dance”.