ReSharper 5 Overview: Navigation to and Within External SourcesOctober 4th, 2010 by Obfuscator
While you’re waiting for the first public build of the recently announced ReSharper 6, here’s a follow-up on the “Introducing ReSharper 5″ blog post series that we did earlier this year. One feature that we have not highlighted before but that’s a major presence in ReSharper 5 is navigation to and within external sources.
When you want to know how a certain method is implemented, with ReSharper you expect to be able to quickly navigate to the declaration of an identifier. In most cases you can do this perfectly well. However, things get tricky in the following two scenarios:
- The method you’d like to zoom in on is part of the .NET Framework.
- Your really huge project is broken down into several subprojects. You’re working in one of them but the class or method that you want to navigate to is declared in another subproject.
ReSharper 5 covers both scenarios with a fresh feature called “External Sources”. External Sources makes all sources available to a developer even if they should be accessed remotely. This is the first step to eliminating differences between your local working copy and actual sources of all components involved in your project.
Let’s take a look at standard use cases when you need access to sources not included in the current project.
.NET Framework Sources
Microsoft provides free access (with certain licensing restrictions) to source code of the entire Microsoft .NET Framework. Within plain Visual Studio, you generally access it during debugging sessions. ReSharper complements this use case with the following extended functionality:
- Navigation to.NET Framework sources.
- Find Usages over all .NET Framework public symbols.
This enables you to easily and transparently access sources of complex .NET Framework classes such as DataGrid.
Your Company’s Library Sources
When working on a big project, a developer usually either doesn’t have the entire sources on their local machine, or they do have them but not in the current project.
In the latter case, if the sources are available but not included in the current project, ReSharper allows you to specify the path to these sources. So, when you try to navigate to an external symbol, ReSharper will search the local (or network) drive for the appropriate file and open it. The only requirement is having .pdb files available for external components.
In the former case, if the sources are way too numerous (or if it is simply impractical to store them all locally, i.e. if they are used infrequently or if there are just too many versions), you can use the Microsoft Source Server. There’s a good chance that it’s already installed in your place of work. ReSharper provides full support for the Microsoft Source Server and relies on it to implement navigation to the source of the .NET Framework. All you need to do is specify the path to the local server(s) in Visual Studio (Tools | Options | Debugging | Symbols).
Now, what do you do if you don’t have .pdb’s, or even no sources at all? Or if you can’t set up Source Server?
For many developers the answer is Reflector. But as you probably know, it is rather cumbersome to use: first you find the right .dll, then you look inside it for the symbol you need. ReSharper PowerToys include a plugin that lets you to connect Reflector with Visual Studio. On the outside it will look like you’re navigating to the source, only Reflector will be used ‘behind the curtains’ to retrieve them.
You might ask, in what way is Reflector integration with Visual Studio inferior to that of ReSharper? We at ReSharper wanted to make the integration seamless, and that’s exactly what our plugin does. You no longer have to think about where a particular symbol is declared - ReSharper finds it for you, wherever it is. First it looks for it on your local drive, then it polls the Source Server, and if that fails, finally it decompiles the sources you need via Reflector.
If you open ReSharper Options and select External Sources, you will see a list of configured source providers. Use this dialog window to define the order in which these providers will be polled. For some providers you can define additional options, e.g. set C# or VB as the presentation language, show XML-doc or not, etc.
The first time you try to navigate to an external source, ReSharper will ask you which provider to use by default:
If you’re not happy with the current provider or the default provider, you can always click on a symbol to bring up the Navigate To menu (ReSharper | Navigate | Navigate To…) and switch the view:
The Way Forward for External Sources
In Internal mode, you can already see the feature called “Find Usages In Compiled Code”. This works like Find Usages which lets you search for symbols used in builds already compiled. This tool is indispensable for situations such as when you’re developing a system core and you must know exactly where and how your public API methods are used.
Another area JetBrains will focus on in growing this functionality is integration with TeamCity — one of today’s most powerful Continious Integration products. Oftentimes, different development teams work on different parts of a system, and synchronizing all their source versions and compiled libraries becomes a real challenge. Enter TeamCity: it knows at all times which source version corresponds to each local library version. Why maintain a huge codebase locally, when you can rely on TeamCity to be your company’s internal Source Server — with no extra configuration required?
Author: Alexander Zverev, senior ReSharper developer