This way of deploying plugins is obsolete in ReSharper 8, although still works. See Packaging Section for modern way of deploying plugins.
Once you’re done writing your plug-in, you probably want to deploy it to end users. Well, the great thing about all of this is that ReSharper essentially supports “xcopy deployment”, meaning that it’s enough to copy the plug-in DLLs to a particular folder and then restart Visual Studio (if open) in order for ReSharper to load the necessary files.
ReSharper typically looks for the plug-in annotated with the suitable metadata. This is the metadata that the SDK project/solution wizards generate and that gets put into
AssemblyInfo.cs. Don’t worry -- additional DLLs that appear in the directory next to your plug-in just fine.
In order to locate plug-ins, ReSharper searches a number of predefined locations. These locations are searched recursively, so you can create nested folders for keeping your plug-ins. In terms of the locations, there are two potential ways to install a ReSharper plug-in: per-machine and per-user.
Before we get on to discussing the two varieties of deployment locations, it’s worth noting that you can get detailed information about where the plug-ins are loaded from and what problems are encountered right from ReSharper. To do so, open up ReSharper | Options, navigate to the Plugins tab and press the Show developer information link at the bottom of the window. This will display detailed information on plug-in discovery.
Let’s deal with the per-machine install first. This basically means that the plug-in, once installed, is available to all users of the plug-in on the machine.
The location of the per-machine plug-in has to be inside a
Plugins folder underneath the ReSharper
Bin folder. For example, on my system, R# searches for plug-ins in the folder at
C:\Program Files (x86)\JetBrains\ReSharper\v6.1\Bin\Plugins. Typically, one would create a folder for the plug-in inside the
Plugins folder. Note that the
Plugins folder may not exist on a clean ReSharper installation, and may need to be created.
If you are using an install package such as WiX to install the plug-in, you can find the ReSharper install location in the registry. Here is the code one would use to determine the location:
In the above XML snippet, we explicitly determine the version of both ReSharper that we are looking for. The above registry key also has subkeys corresponding to different versions of Visual Studio, just in case you want to constrain your plug-in to particular version(s).
The other installation option is to install things per-user, i.e. to install the plug-in for the current user only. This means other users on the machine will not be able to use the plug-in. On the other hand, this implies that it’s possible to install a ReSharper plug-in so that users may be able to access this same plug-in on many different workstations, provided they use the same credentials.
There are many per-user locations where a per-user install can go. First of all, it can go either into the local profile or the roaming profile. On my system, these would correspond to the following locations:
Now, you’re probably wondering why I stopped at the level of the company name rather than the ReSharper product. The reason is that you might also wish to deploy plug-ins which affect other .Net tools (such as dotTrace or dotCover). Thus, there are two options again:
- .Net products:
But that’s not all! In terms of versioning, it’s possible to constrain deployment to just ReSharper, to a ReSharper of a specific version (the recommended option), or to specific versions of both ReSharper and Visual Studio:
- ReSharper (any version):
- ReSharper 6.1:
- ReSharper 6.1 under VS2010:
Sample WiX Definition
The following is a sample WiX XML definition for deploying a plugin to the
AppData folder. This example deploys the plugin for all versions of ReSharper, but ensures it is only installed if VS2010 or 2012 is present:
- One security measure of Windows causes binary files shared over the network (e.g., acquired as an e-mail attachment) to become 'sandboxed' in a particular version of the .NET framework. This may, in the case of plugins, cause it to be loaded and yet not functional. The solution for this issue is, for each binary file, to right-click it in Windows Explorer, choose Properties, and then press the Unblock button.