ReSharper has always had a powerful extensibility story – its Open API allows plugins to use the same APIs that the core product uses. But distribution – discovery, installing and uninstalling – has previously been left to the plugin author, meaning the user is left with an experience ranging from msi installers to zip and batch files. Recently, .NET has seen the success of the NuGet package manager, which makes it very easy to install, uninstall and update libraries in a project. We’d like to bring that ease of use and discovery to ReSharper, which is why we’re very happy to be taking the wraps off our NuGet based Extension Manager.
The latest EAP build of ReSharper 8 adds support for extensions to be distributed as NuGet packages. You get to use a very familiar interface to browse and install extension packages from our new extensions gallery. Of course, you can easily uninstall and update, too, and ReSharper will check for updates for you, and notify you when a new build is available – perfect for keeping up to date with EAP changes.
Speaking of EAP changes – since ReSharper 8 is currently still under development, it is obviously changing and evolving with each EAP release. Which means our packages are marked as “prerelease”. Once 8.0 is released, these will of course become Stable. Until then, please make sure to select “Include Prerelease” when browsing with the Extension Manager, or in the Gallery.
Extensions, Not Plugins
A very important change, though, is that an extension is not just for plugins. An extension can also be used to distribute ReSharper’s settings files and External Annotations, meaning you can now write useful extensions without even having to write any code.
The benefit of distributing .dotSettings files is that these are the files used by ReSharper to store Live Templates, Structural Search and Replace patterns, and other settings. For example, the xUnit.net test runner extension includes a plugin to provide the test runner capabilities, but also includes a .dotSettings file, adding lots of Live Templates to help generate code to write asserts faster.
And the sample patterns catalog extension adds a sample set of Structural Search and Replace patterns. These patterns are a very powerful, declarative way of analysing code and applying the standard warning squiggly underline highlight. What’s more, they can also provide a declarative means for creating a quick-fix for this code – adding an action to the alt+enter quick-fix menu to replace the code. See here for an introduction to SSR, and check out these posts for more information.
Of course, settings files aren’t limited to Live Templates and SSR patterns. While these were the primary motivation for adding support for .dotSettings files, it opens the door for more interesting extensions – defining code formatting standards, code cleanup profiles, extra To-do items, or even a different set of opinionated code inspection defaults (don’t like our default “var” recommendations? Change them!).
Extension packages take advantage of ReSharper’s settings layers. If the extension contains a .dotSettings file, it is added as a read-only layer. The settings in the file are merged with the other layers in your installation (This Computer, Solution and project files – see this post for more information on layers), and naturally appear in the Options dialog or Live Templates Explorer. This means you can edit the templates, patterns or other settings, and any changes are then saved in the This Computer layer.
If you don’t want these extra settings (for example, you want the test runner, but not the included Live Templates) you can easily remove them from the system by disabling the layer in the Manage Options dialog. The settings, templates or patterns are immediately removed.
External Annotations are xml files that contain a map between ReSharper’s annotation attributes, and pre-compiled assemblies. ReSharper’s code analysis uses these annotations to make better decisions about the warnings to show. For example, without annotations, this test code warns about potential null usage, even though the preceding Assert will throw an exception if the value is null – in other words, the value is guaranteed to be not-null when accessed.
The xUnit.net extension adds annotations for the xunit.dll assembly, which tells ReSharper that Assert.Null will throw if the passed parameter is null. Now, ReSharper knows that the second assert will never get hit, and marks it as unreachable.
ReSharper ships with annotations for the BCL, and some annotations for third party assemblies, notably to enable INotifyPropertyChanged support. Extensions can now distribute annotations for other third party assemblies.
Dependencies
Since extensions are NuGet packages, they can have dependencies. Someone could write an extension that exports a Live Template for creating test methods. That template could use a macro from another extension to make sure the method name you type gets converted to a valid name – changing spaces to underscores, for example.
Bundled Extensions
Another exciting benefit we get from the extension manager is the ability to have bundled, or pre-installed, extensions. These are simply extensions that are installed for you as part of the normal installation process. Once installed, they behave just like normal extensions, and we can push updates to the Gallery at any time, allowing us to update these plugins on a separate schedule to ReSharper itself.
In the latest EAP build, we’re bundling our NuGet plugin which uses NuGet to add package references, rather than file references when importing types. We now get the best of both worlds – this really useful functionality is included by default for every ReSharper user, and we have the flexibility to update it at any time, decoupled from ReSharper’s release schedule.
Custom sources
Of course, since this is based on NuGet, we get to take advantage of the existing infrastructure and tooling available in the NuGet community. Our Gallery is based on the NuGet Gallery sources, and is the default, primary location for getting extensions (remember to select “Include Prerelease”!). But you can also use the Extension Manager page in the Options dialog to specify extra sources – local or remote file system or a custom NuGet feed, such as TeamCity or MyGet. This makes it easy to install private, company wide extensions that target your specific needs, or nightly builds of an extension you build, or perhaps create a curated feed of your favourites.
How to Build Your Own Extensions
Building extensions is very straightforward. While we’re based on NuGet, we have a very different purpose to NuGet – extensibility information as opposed to assembly references. So we don’t use the standard libs, tools or content folders. Instead, we have our own folder structure that makes more sense for the data we need to distribute in the package. But that’s really the only difference. We still use the .nuspec file for metadata, and we pack and push the .nupkg file to the ReSharper Gallery in the same way – sign up for an account, get an API key and push away! You can get more information on creating an extension package at the ReSharper 8 devguide site, and if you have more questions, please email us at resharper-plugins@jetbrains.com, or send a message to the new resharper-plugins Google Group.
Please note that the Extension Manager relies on NuGet’s core library to implement a lot of its functionality. Since this is a .NET 4 library, the Extension Manager is limited to Visual Studio 2010 and 2012. We’re looking at ways to improve this as we progress through the EAP.
We hope you enjoy the changes we’ve introduced around extensions. Please try it out and let us know your feedback. We’re still quite early on in the EAP cycle, so expect changes – but if there’s something you want to see changed or updated, let us know! You can report issues at our YouTrack instance.
And remember, you don’t need to write a plugin to release an extension – let’s see some Live Templates and SSR patterns!
