Well, most of it, anyway. We recently relocated the .NET Reflector web content to red-gate.com

You can now find information about .NET Reflector and Red Gate’s other .NET tools at:

www.red-gate.com/products/dotnet-development/reflector/

We’ll be keeping the blog here for the moment, and we’ll eventually migrate that over to Red Gate, too.

On Thursday we released version 8.0 of Reflector. Unfortunately, things didn’t quite go according to plan, and it looks like we’ve confused a few people.

The Check for Updates notification for version 8 incorrectly lists it as a free trial:

The bad news is that currently it doesn’t look like we’ll be able to fix that.

The good news is that you can just ignore it.

Version 8 is a free upgrade to version 7 users, and when you update, you’ll get the full version, not a free trial.

For more on what’s included in v8, check out the release blog post

For a bit more on why this happens, keep reading.

Continue reading…

Reflector V8 has just shipped, so here’s a quick overview. In this update we’ve added better search and filtering (in Reflector Desktop, and the Visual Studio extension), improved navigation to decompiled code from the call stack, fixed plenty of bugs, improved performance a little, and added decompilation in Visual Studio when you hit an exception. The big idea was to make it easier and faster to get to the relevant lines of code when you’re debugging.

Search and filtering

This is the most visible change in version 8. The object browser in Reflector Desktop, and in the Visual Studio extension now has a search box at the top. This lets you filter the tree view so you can just look at the things you might be interested in.

The search includes some scoping, so you can search for, say, all instances of a search string within a particular namespace. This should make it a bit quicker to find what you’re looking for, and navigate through unfamiliar code.

Debugging in Visual Studio

If you’re debugging an executable or library without source code, and that’s where the error is, the call stack can be a bit unhelpful. It’ll either be empty or greyed-out, depending on your settings. What we’ve done in V8, is add the ability to navigate to decompiled source from grey frames. So when you break in a debugging session, you should now always be able to get direct to source.

It works under IIS, too, so debugging should get a little nicer for the web and SharePoint folks.

Try it out

Version 8 is available now, and you can download it and try it out.

This release wraps up what’s been a fairly sizeable version 7. It’s nothing like an exhaustive list, but we’ve seen: a new installer, plenty of engine work (C#5, VB improvements, XAML, etc) various batches of work on the power commands, PDB generation and debugging in Visual Studio, VS2012 support, this new search and debugging functionality, and a substantial set of bug fixes. You can check out a full list of what’s new since version 7 on the changelog.

If you’ve already bought version 7, we’ll be making version 8 available as a free upgrade, so your existing license should just work. If you haven’t tried v7 yet, it’s well worth taking a look at version 8, because quite a lot has changed in the last couple of years.

We hope you’ll like it, and as always, drop us a line if you have any feedback

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.

You can download it for free from the Red Gate Labs

The checker shows obfuscation and security information.

It’s a beta, and certainly not perfect, but it works and we’re pretty happy with it.

Continue reading…

It’s Down Tools Week here at Red Gate, which sounds a bit like a bout of messy industrial action, but is actually a kind of week-long hack day. Most of the Reflector team (and some of our DevOps guys) are working on something we’ve had on a back burner for a while: the .NET Obfuscation Checker.

It does exactly what it sounds like it does. The checker uses Reflector to examine the assemblies and .exe files in a directory, and see what’s obfuscated. It’s based on the tool David built and that we use internally to check that our builds are ready to ship.

Continue reading…

We got really interested in debugging workflows during our last batch of user research. One of the things we noticed was that even with Reflector installed in Visual Studio, the debugging trail can easily go cold when you hit third party code.

If you’re attached to a process in a debugging session and you break or hit an exception, the typical experience is either a rather useless greyed-out call stack, and the disassembly metadata view, or worse, if you’ve got “Enable just my code” switched on, an empty call stack and the faintly sad message “No disassembly available”. Neither is particularly helpful.

Progress so far: enabling call stack frames

Continue reading…

Rather than write about what we’ve been working on this time, we’ve done a short video.

As usual, we’d love to know what you think, and you can download it here

We’re doing a refresh on the search functionality; below you can see the old search pane. One of the main problems with this is that when you open it up, it eats up the space you would normally use to look at code.

So to try to address this we started working on a filtering solution for the assembly tree. We got some way into development and put it out in a beta. We also got straight into user testing with a number of volunteers.

Continue reading…

Carlos Quintero (MVP, and developer of MZ-Tools) recently wrote a blog post on debugging into Visual Studio’s assemblies. We liked it, and asked him to tell us a bit more…

Using .NET Reflector to understand and debug Visual Studio assemblies

As a developer of Visual Studio add-ins, I have been using .NET Reflector to understand the internals of Visual Studio assemblies since many years ago, and I consider it an invaluable tool for developers of Visual Studio extensions (add-ins, packages, etc.). In this guest post I will explain why.

Developing a somewhat complex Visual Studio extension, there are two scenarios where you may desire to have the Visual Studio source code and even to debug its assemblies:

• To understand how Visual Studio does some kind of things, because you need to do the same or similar ones in your own extension.
• To guess which code path inside a method is actually used at run-time. I mean: you may have the source code of a Visual Studio assembly with some complex logic, and it is difficult to guess which branches are actually executed for certain cases.

Microsoft has released the source code of the .NET Framework and you can even debug its assemblies, but it hasn't done the same with Visual Studio assemblies. This is where. NET Reflector comes to the rescue. You can use .NET Reflector for those two scenarios. I’ll illustrate this with a real case…

Continue reading…

Download the latest beta release

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.

Filtering the object browser. Click to expand.

Continue reading…