Using NuGet (Windows)
This guide describes how developers can use the NuGet packages available for RhinoCommon and Grasshopper.
In previous guides you’ve seen how to set up a project to develop a RhinoCommon Plugin or Grasshopper component. These guides relied on the Visual Studio Project Wizards that we publish to quickly get you going on plugin development. The wizards automatically reference the necessary assemblies to make RhinoCommon and Grasshopper SDKs available in your Visual Studio project. While this project setup should be fine for a number of cases, there might be some reasons to switch the RhinoCommon and Grasshopper assembly references to those which are published by McNeel on NuGet…
There are several potential advantages to using NuGet packages for RhinoCommon SDKs:
- It’s great for projects with multiple developers (or developers with multiple computers). No more references to
- NuGet runs on Windows and Mac and is baked into Visual Studio (for both Window and Mac).
- Are you using Continuous Integration (CI)? Your build servers can automatically download the correct version of the SDK before compiling and publishing your shiny new release.
- You’re probably already using it to install packages like Json.NET.
NuGet makes it easy to compile plug-ins against versions of Rhino other than those installed on your computer. This is handy for backwards-compatible and/or cross-platform development. However, the fact that your Rhino installation and your RhinoCommon/Grasshopper references are “out of sync” can cause problems.
- NuGet packages will need to be updated separately to Rhino
- You may have trouble debugging your plug-in if it was built against a version of RhinoCommon that is newer than the one included with Rhino1
You can install the RhinoCommon package like you would any other.
The RhinoCommon (for Rhino 5) package includes
To switch to NuGet packages, follow these steps:
In Visual Studio, find the Solution Explorer and right-click on the References section of your project. Select Manage NuGet Packages… Alternatively, the same can be done through the Visual Studio Project menu, and choosing Manage NuGet Packages…
In the NuGet tab which appears, click on Browse. In the search box, type in RhinoCommon. You should see an entry for RhinoCommon and one for Grasshopper. If you are writing a Rhino Plugin or Grasshopper Add-on for Rhino WIP, ensure you check Include prerelease.
If your project is a Grasshopper Add-on, select the Grasshopper entry. For Grasshopper Add-ons on Rhino 5 choose the latest stable 0.9.76 version and click Install. NuGet will install3
GH_IO.dllas well as the corresponding version of the RhinoCommon assemblies.
(Optional) The references created by these packages have
true. Normally, it is a best practice to make sure that the references are not copied to the output directory, since they are included with Rhino. You can do this by selecting any of the following references if they exist in your project - RhinoCommon, Eto, Rhino.UI, Grasshopper, GH_IO - and, in the Properties window, set
false. The reason this step is optional is that we’ve included some MSBuild witchcraft that will ensure that
CopyLocalis set to
falsewhen compiling your project, regardless of what it says in the Properties window.
(Optional) If you’re using version control, don’t forget to commit the new packages.config file!
Your plug-in will not load if it uses parts of the API which don’t exist in the running version of Rhino. ↩
This means that if you install the Grasshopper NuGet package, the matching RhinoCommon package will be installed automatically. ↩