.NET Tools
Essential productivity kit for .NET and game developers
ReSharper 6 Bundles Decompiler, Free Standalone Tool to Follow
Previous posts introducing ReSharper 6:
What’s going on here?
We’ve recently hinted on a new kind of functionality that’s being developed within ReSharper 6 EAP. Those of you who saw that post got the message right: ReSharper 6 will feature a decompiler. More than that, it is already available in ReSharper 6 EAP builds that you can download and try.
As if it isn’t enough, we have more great news: make sure to read on to the end of this post.
How do I invoke the decompiler in ReSharper?
There are several ways you can navigate to decompiled code in ReSharper:
- You can navigate to a decompiled library symbol right from its usage in the source code. This should be done via ReSharper’s Navigate To feature. To invoke Navigate To, press Alt+` and select Decompiled sources:
- You can jump to the declaration of a specific library type from anywhere within Visual Studio using ReSharper’s Go to Type menu (Ctrl+T in Visual Studio layout). You can even go further by jumping to a specific library method or property using Go to Symbol (Shift+Alt+T).
- If you prefer browsing library types using the Object Browser, you can invoke Navigate To Decompiled Sources right from there:
- Navigate to declarations and implementations:
- Search for usages, inheritors, and base symbols:
- Explore a decompiled type with File Structure:
- View type hierarchy or even see incoming calls to library symbols from your source code:
- Highlight usages of symbols:
Will common ReSharper features be available with decompiled code?
Well naturally, you can’t refactor decompiled libraries, generate new code in them, or run code inspections (though it would be fun in some cases).
However, most navigation features that ReSharper normally provides in source code are equally available in decompiled code. For example, you can:
Where can I configure the behavior of ReSharper decompiler?
Decompiler is configured in the same group as other features from the External Sources feature group, namely ReSharper | Options | Tools | External Sources | Decompiled Sources.
If you’re trying to get ReSharper show decompiled code but it’s failing to do so, make sure that Decompiled sources is selected as an external sources data provider in ReSharper | Options | Tools | External Sources. By the way, if Decompiled sources is at the top of the list, you can navigate to decompiled code with Go to Declaration (F12 or Ctrl+click).
How sophisticated is ReSharper decompiler?
Let’s just say, ReSharper decompiler is sophisticated enough to correctly infer lambda expressions and yield returns. Some things are not yet supported, for instance auto-properties, but that’s only a question of time.
Why has ReSharper moved in this direction?
Source code management has been in focus of the developer community for ages. We have lots of source code storage systems with histories and branches, distributed and personal, tools ecosystem, and what not. However, many applications are quite large today, and handling them in source form tends to get more and more complicated. Setting up binary reusable libraries even inside a single business entity can be a very painful thing to perform.
ReSharper started assisting developers with this in version 5, by introducing navigation to and within external sources. The External Sources feature brings code available through information in PDB (Program DataBase) files straight into Visual Studio editor. For example, when Microsoft releases another library in Reference Source form, they publish PDB files having links to their Source Servers. ReSharper can parse this information, download source files and display them for a developer to explore.
That’s cool, but what about home-built libraries? What if your company doesn’t have Source Server infrastructure in place and doesn’t want to invest into getting one? How to get seamless integration with source code and binary libraries referenced in projects?
That’s exactly the task that the decompiler in ReSharper 6 is going to solve. Adding to the Source Server support, the new ReSharper reconstructs source code from compiled assemblies and enables all code reading features in such files.
Say, one department in your company builds a framework, and another department uses it to create an end-user application. You can reference assemblies for the framework and avoid bloating your workspace with files and projects that you don’t really need. However, when required, you can easily jump into decompiled sources and explore internals. Should you need further details — comments, real variable names, exact code — you can go and check out sources for that project, but in fact it is quite rarely needed.
Another point is the emerging market of packaging solutions: NuGet and OpenWrap to name a few. Packages (or wraps) contain binaries and tools, but not source code. However, many of them are open source and it is perfectly legal to look for sources, even reconstructed. We would like to talk to providers of packaging solutions and ask them to include information about source code locations into package descriptors, so that everybody can get the exact source code for a specific version of binaries.
Will the decompiler be only available as a part of ReSharper?
At this point you are probably asking yourself “Well, but what about a standalone solution? I don’t need ReSharper!”.
Bad news is you should only not need ReSharper if you’re not doing .NET development.
Good news is that we’re preparing a standalone binary-as-a-source application, i.e. a decompiler + assembly browser to explore whatever .NET compiled code is legal to explore. We don’t have any specific date for release, but it’s going to be released this year, and it’s going to be free of charge. And by saying “free”, we actually mean “free”.
UPDATE (May 12, 2011): Standalone decompiler called dotPeek is now available for download!
If you’ve read it up to this point, you completely owe it to yourself to try ReSharper 6 EAP builds with decompilation engine right now!
Let us know what you think about the quality of the decompiler and overall source-binary integration experience and how we can make it even better for you.
Subscribe to a monthly digest curated from the .NET Tools blog:
