NuGet references

Versioning

The JetBrains.ReSharper.SDK package is used to target the current version of ReSharper. There isn't a separate package for major versions of ReSharper, e.g. ReSharper 10, ReSharper 9, etc. When a new version of the ReSharper Platform is released, a new version of JetBrains.ReSharper.SDK is released to match - the SDK package version tracks the version of the ReSharper Platform. To target the current release of ReSharper, add a reference to the latest stable version of the SDK package in the NuGet gallery. EAP versions of ReSharper will have an SDK that is released with a newer version number, and marked as pre-release.

In order to target an older version of the SDK, you can add a NuGet reference to a specific version of the SDK, e.g. by using the following command in the "Package Manager Console":

The specific version number can be found by looking at the package history on the gallery. The major and minor version numbers of the SDK package match the product version of ReSharper. For example:

An existing plugin project can be updated to the latest SDK by simply updating the JetBrains.ReSharper.SDK package. Changes to the API are to be expected (see the guide on Platform Versioning for more details), and significant changes are called out in the What's New? guide.

If an existing plugin project is required to stay at a particular version, rather than be upgraded to a new version, you can specify the required version in the packages.config file, by setting the allowedVersions attribute to the required version:

Test packages

Test projects should be created as .net class library projects and should include the JetBrains.ReSharper.SDK.Tests package. This package includes JetBrains.ReSharper.SDK as a dependency. It is a small package that only includes a simple .props file that gets automatically included into the test project, and sets the JetTestProject MSBuild property to true. This causes the other SDK packages to alter their behaviour. Notably, it enables the "CopyLocal" flag. Normally, the SDK packages disable copy local, so the only files in the build folder are the plugin's, plus dependencies. This is because it's not possible to run the plugin without installing into a local installation of ReSharper, so it makes no sense to copy all of the ReSharper references to the build folder. Tests, on the other hand, run independently of the Visual Studio ReSharper host, and require the ReSharper references so that nunit can find the referenced assemblies.

Continuous integration

The SDK packages are intended to work with continuous integration (CI), and provide everything necessary to build your plugin. Nothing else needs to be installed on the CI server. The NuGet packages are designed to work with package restore, so the packages folder should not be committed into source control.

Troubleshooting

If you see the following error message, or something similar, you will need to restart Visual Studio and try again. It might also help to temporarily suspend ReSharper:

This issue is due to a race condition in MSBuild, that can be triggered while ReSharper is active, and when packages that match certain criteria are installed. Unfortunately, this can affect the SDK. Frequently, there is no issue, and the SDK can be upgraded with no issues. However, occasionally, MSBuild can fail to evaluate properties correctly, which causes the error message above. Furthermore, the error is persistent until Visual Studio is restarted. Restarting Visual Studio and reattempting the upgrade will frequently work (it might also help to roll back to the last source control check in first).

It appears that ReSharper being active can exacerbate this issue, and make it more likely (presumably because ReSharper is monitoring both NuGet installs and changes to MSBuild's project system). It might help to temporarily suspend ReSharper while updating the NuGet packages.