Category Archives: Version 7.0

We’ve just released .NET Reflector 7.1

Version 7 customers can go to Help>Check for Updates or just download the latest version and unzip over the existing installation.

If you are not yet a version 7 customer you can download a new 14 day trial of version 7.1.

What’s new in version 7.1?

• Improved VB support
• Better handling of resource types
• Lots of improvements to C# decompilation

Version 7.1 also adds command line activation and deactivation, as requested by many of our larger customers, and fixes another 105 bugs, including a common issue with breakpoints in .NET Reflector VSPro, and a number of stability problems. Further details about some of the bugs fixed can be found in this earlier post by our tester, Nick Maidment.

If you have any feedback about version 7 or feature requests for the future we would love to hear from you in the new .NET Reflector forum. Please just post feedback, bugs or feature requests as questions for now, and remember to vote for other people’s requests.

We really hope you enjoy the improvements made to version 7.1 as I and the rest of the dev team head straight onto version 7.2… as of… well last week actually!


To get the latest .NET Reflector news, follow us on Twitter @dotnetreflector

We’ve just released the first public EAP of .NET Reflector 7.1

EAP’s have been a part of the Red Gate way for the last couple of years and we plan to continue this practise with .NET Reflector. See below to find out what’s new in V7.1 or download the latest copy here.

We love releasing EAP’s for a number of reasons:

Firstly EAP’s allow us to get early feedback and bug reports on new features and versions. With the inclusion of SmartAssembly error reporting and feature reporting we are also able to make much better decisions about our priorities as me move towards a final release.

The second big reason is the chance for our users to get their hands on new features or bug fixes as early as possible. EAP’s give us the chance to put new features or fixes in the hands of our users faster.

Over the next few months we plan to be release updates to version 7 early and often. These will be spread across multiple EAP’s and minor releases. We really encourage you to get involved and give us your feedback.

So what’s new in 7.1?

7.1 fixes over 90 long term bugs providing:

• Improved VB support
• Better handling of resource types
• Lots of improvements to C# decompilation

7.1 also fixes a common issue with breakpoints in .NET Reflector VSPro.

It would take too long to cover every single bug we’ve looked into but I thought I’d cover a few specifics reported by people via the forums, I’ve included links to these issues below so you can read about them yourselves.

vbnet-byref-arguments-still-incorrectly handled

We are so happy to see the beginnings of a proper Reflector community on our forums where users try to help each other out as well as just using it as a channel to report problems. This is something we hope to encourage and grow in the coming months.

Obviously we’ve not been able to fix everything in 7.1 but we hope you’ll notice some general improvements. Please send us any feedback about the EAP build by posting a question on our forum tagged with #7.1 and #EAP. It would be great to hear from you!


To get the latest .NET Reflector news, follow us on Twitter @dotnetreflector.

We’ve just released contains a workaround for a problem that affected our add-in when it was loaded into VS 2010 SP1 on non-English locales.

Thanks very much to Sörnt for his question that quickly became the most viewed post in our new forum and gave us some indication of how many people this was affecting.

Sörnt also let us log into his machine to run WinDbg and was the first person to test our new build. Thanks Sörnt, we owe you one!

It turned out that the code used by the add-in was calling one of the IsolatedStorage functions to open an isolated storage file with the intention of catching the exception that is raised if the file doesn’t exist. When the file didn’t exist, an exception was constructed, but of course this needed the localised message from a resource assembly. This involved some assembly resolution. VS 2010 SP1 runs with an assembly resolver which checks for resource files according to previously loaded add-ins. The resolver makes a File.Exists call, which would fail because we were running inside the context of the IsolatedStorage. Isolated Storage works by setting a file permission which only allows access to the isolated storage directory. This meant that an exception was constructed, and in constructing it a search was carried out to find a localised string. This lead to a vast number of Security exceptions, which caused start up to take a long time and hence for the COM call that initialises the add-in to time out.

Thanks again to Sörnt and the other guys who replied to my appeal for stack traces. As a result of this particular bug we have decided to implement a public bug tracking system for .NET Reflector where users will be able to log bugs and vote up the most important ones so we make sure we are fixing the issues that will impact the highest number of users. Hopefully we will get something live in the next few weeks.

We’ll also be reporting this bug to Microsoft.


Please do send us any feedback about version to or post a question on our forum. We’d love to hear from you. To get the latest .NET Reflector news first, follow us on Twitter @dotnetreflector.

Some notes on Reflector 7

Both Bart and I have blogged about some of the changes that we (and other members of the team) have made to .NET Reflector for version 7, including the new tabbed browsing modelthe inclusion of Jason Haley’s PowerCommands add-in and some improvements to decompilation such as handling iterator blocks. The intention of this blog post is to cover all of the main new features in one place, and to describe the three new editions of .NET Reflector 7.

Three new editions

.NET Reflector 7 will come in three new editions:

  • .NET Reflector
  • .NET Reflector VS
  • .NET Reflector VSPro

The first edition is just the standalone Windows application. The latter two editions include the Windows application, but also add the power of Reflector into Visual Studio so that you can save time switching tools and quickly get to the bottom of a debugging issue that involves third-party code.

Let’s take a look at some of the new features in each edition.

Tabbed browsing

.NET Reflector now has a tabbed browsing model, in which the individual tabs have independent histories. You can open a new tab to view the selected object by using CTRL+CLICK. I’ve found this really useful when I’m investigating a particular piece of code but then want to focus on some other methods that I find along the way. For version 7, we wanted to implement the basic idea of tabs to see whether it is something that users will find helpful. If it is something that enhances productivity, we will add more tab-based features in a future version.


PowerCommands add-in

We have also included Jason Haley‘s PowerCommands add-in as part of version 7. This add-in provides a number of useful commands, including support for opening .xap files and extracting the constituent assemblies, and a query editor that allows C# queries to be written and executed against the Reflector object model .

All of the PowerCommands features can be turned on from the options menu. We will be really interested to see what people are finding useful for further integration into the main tool in the future.


My personal favourite part of the PowerCommands add-in is the query editor. You can set up as many of your own queries as you like, but we provide 25 to get you started. These do useful things like listing all extension methods in a given assembly, and displaying other lower-level information, such as the number of times that a given method uses the box IL instruction.


These queries can be extracted and then executed from the ‘Run Query’ context menu within the assembly explorer.


Moreover, the queries can be loaded, modified, and saved using the built-in editor, allowing very specific user customization and sharing of queries.


The PowerCommands add-in contains many other useful utilities. For example, you can open an item using an external application, work with enumeration bit flags, or generate assembly binding redirect files. You can see Bart’s earlier post for a more complete list.

.NET Reflector VS

.NET Reflector VS adds a brand new Reflector object browser into Visual Studio to save you time opening .NET Reflector separately and browsing for an object. A ‘Decompile and Explore’ option is also added to the context menu of references in the Solution Explorer, so you don’t need to leave Visual Studio to look through decompiled code. We’ve also added some simple navigation features to allow you to move through the decompiled code as quickly and easily as you can in .NET Reflector.


When this is selected, the add-in decompiles the given assembly,


Once the decompilation has finished, a clone of the Reflector assembly explorer can be used inside Visual Studio.


When Reflector generates the source code, it records the location information. You can therefore navigate from the source file to other decompiled source using the ‘Go To Definition’ context menu item.


This then takes you to the definition in another decompiled assembly.


.NET Reflector VSPro

.NET Reflector VSPro builds on the features in .NET Reflector VS to add the ability to debug any source code you decompile. When you decompile with .NET Reflector VSPro, a matching .pdb is generated, so you can use Visual Studio to debug the source code as if it were part of the project. You can now use all the standard debugging techniques that you are used to in the Visual Studio debugger, and step through decompiled code as if it were your own.

Again, you can select assemblies for decompilation.


They are then decompiled.


And then you can debug as if they were one of your own source code files.


The future of .NET Reflector

As I have mentioned throughout this post, most of the new features in version 7 are exploratory steps and we will be watching feedback closely. Although we don’t want to speculate now about any other new features or bugs that will or won’t be fixed in the next few versions of .NET Reflector, there are lots of improvements we intend to make. We plan to do this with great care and without taking anything away from the simplicity of the core product.

User experience is something that we pride ourselves on at Red Gate, and it is clear that Reflector is still a long way off our usual standards. We plan for the next few versions of Reflector to be worked on by some of our top usability specialists who have been involved with our other market-leading products such as the ANTS Profilers and SQL Compare. I re-iterate the need for the really great simple mode in .NET Reflector to remain intact regardless of any other improvements we are planning to make.

I really hope that you enjoy using some of the new features in version 7 and that Reflector continues to be your favourite .NET development tool for a long time to come.

.NET Reflector 7 Beta, Integrating Jason Haley’s PowerCommands Add-in is Now Available

I’m very pleased to announce the release of .NET Reflector 7 Beta.

I’ve been holding off for a week or so because I wanted to be able to announce the great news that we’ve acquired the excellent PowerCommands add-in from Jason Haley, and have integrated it directly into .NET Reflector. The amount of time Jason’s invested in PowerCommands really shows, because it provides an extremely powerful set of extensions to the core Reflector functionality. To illustrate, here’s a summary of the complete feature list which Jason provided us: Continue reading

On Her Majesty’s Secret Source Code: .NET Reflector 7 Early Access Builds Now Available

Dodgy Bond references aside, I’m extremely happy to be able to tell you that we’ve just released our first .NET Reflector 7 Early Access build.

The new version so far comes with numerous decompilation improvements including (after 5 years!) support for iterator blocks – i.e., the yield statement first seen in .NET 2.0. We’ve also done a lot of work to solidify the support for .NET 4.0. Clive’s written about the work he’s done to support iterator blocks in much more detail here, along with the odd problem he’s encountered when dealing with compiler generated code.

On the UI front we’ve started what will ultimately be a rewrite of the entire front-end, albeit broken into stages over two or three major releases. The most obvious addition at the moment is tabbed browsing, which you can see in Figure 1.


Figure 1. .NET Reflector’s new tabbed decompilation feature. Use CTRL+Click on any item in the assembly browser tree, or any link in the source code view, to open it in a new tab.

This isn’t by any means finished. I’ll be tying up loose ends for the next few weeks, with a major focus on performance and resource usage. .NET Reflector has historically been a largely single-threaded application which has been fine up until now but, as you might expect, the addition of browser-style tabbing has pushed this approach somewhat beyond its limit. You can see this if you refresh the assemblies list by hitting F5. This shows up another problem: we really need to make Reflector remember everything you had open before you refreshed the list, rather than just the last item you viewed – I discovered that it’s always done the latter, but it used to hide all panes apart from the treeview after a Refresh, including the decompiler/disassembler window.

Ultimately I’ve got plans to add the whole VS/Chrome/Firefox style ability to drag a tab into the middle of nowhere to spawn a new window, but I need to be mindful of the add-ins, amongst other things, so it’s possible that might slip to a 7.5 or 8.0 release.

You’ll also notice that .NET Reflector 7 now needs .NET 3.5 or later to run. We made this jump because we wanted to offer ourselves a much better chance of adding some really cool functionality to support newer technologies, such as Silverlight and Windows Phone 7.

We’ve also taken the opportunity to start using WPF for UI development, which has frankly been a godsend. The learning curve is practically vertical but, I kid you not, it’s just a far better world. Really. Stop using WinForms. Now. Why are you still using it? I had to go back and work on an old WinForms dialog for an hour or two yesterday and it really made me wince. The point is we’ll be able to move the UI in some exciting new directions that will make Reflector easier to use whilst continuing to develop its functionality without (and this is key) cluttering the interface. The 3.5 language enhancements should also enable us to be much more productive over the longer term.

I know most of you have .NET Fx 3.5 or 4.0 already but, if you do need to install a new version, I’d recommend you jump straight to 4.0 because, for one thing, it’s faster, and if you’re starting afresh there’s really no reason not to.

Despite the Fx version jump the Visual Studio add-in should still work fine in Visual Studio 2005, and obviously will continue to work in Visual Studio 2008 and 2010. As before, we continue to support every edition of Visual Studio exception the Express Editions.

Speaking of Visual Studio, we’ve also been improving the add-in. You can now open and explore decompiled code for any referenced assembly in any project in your solution. Just right-click on the reference, then click Decompile and Explore on the context menu. Reflector will pop up a progress box whilst it decompiles your assembly (Figure 2) – you can move this out of the way whilst you carry on working.


Figure 2. Decompilation progress. This isn’t modal so you can just move it out of the way and carry on working.

Once it’s done you can explore your assembly in the Reflector treeview (Figure 3), also accessible via the .NET Reflector > Explore Decompiled Assemblies main menu item. Double-click on any item to open decompiled source in the Visual Studio source code view. Use right-click and Go To Definition on the source view context menu to navigate through the code.


Figure 3. Using the .NET Reflector treeview within Visual Studio. Double-click on any item to open decompiled source in the source code view.

There are loads of other changes and fixes that have gone in, often under the hood, which I don’t have room to talk about here, and plenty more to come over the next few weeks. I’ll try to keep you abreast of new functionality and changes as they go in.

There are a couple of smaller things worth mentioning now though.

Firstly, we’ve reorganised the menus and toolbar in Reflector itself to more closely mirror what you might be used to in other applications.

Secondly, we’ve tried to make some of the functionality more discoverable. For example, you can now switch decompilation target framework version directly from the toolbar – and the default is now .NET 4.0.

I think that about covers it for the moment. As I said, please use the new version, and send us your feedback.

Until next time!

(Follow us @dotnetreflector to get the latest .NET Reflector news and updates.)

We’ve completed the first iteration

There are a lot of features in C# that are implemented by the compiler and not by the underlying platform.

One such feature is a lambda expression. Since local variables cannot be accessed once the current method activation finishes, the compiler has to go out of its way to generate a new class which acts as a home for any variable whose lifetime needs to be extended past the activation of the procedure. Continue reading