McNeel Wiki

• New project wizards for plug-ins and commands in Visual C# 2010 and Visual Basic 2010, including Express Editions. Same as installing from VS 'Extension Manager'. After installing the wizards and when you create a new project in Visual Studio, make to set the Framework to 4.0 in order to see the Rhino plug-in in the list.
• Online SDK documentation
• Offline help file that is outdated and changed with every new RhinoCommon version. You might need to right-click it and choose unblock after downloading it.

RhinoCommon is the new .NET plug-in SDK available for:

• Rhino 5 (both 32 and 64 bit versions)
• Rhino for Mac
• Rhino.Python scripting
• Grasshopper

The term common is meant to be just that; an SDK that can be used across Rhino platforms. A plug-in built with RhinoCommon could potentially run on both Windows and Macintosh platforms with no changes.

Rhino 4 and Rhino 5 already contain a .NET plug-in SDK called Rhino.NET. We will continue to ship and support the Rhino.NET SDK in Rhino 5.

The good news is that you can use both SDKs in a single .NET plug-in. If there is a new feature in the RhinoCommon SDK that you want to use in your Rhino.NET based plug-in, just add a reference to RhinoCommon.dll and start using it.

Tip: When adding a reference, make sure to always set Copy Local to False.

RhinoCommon is meant to be version 2 of the Rhino.NET SDK, and it improves on the design and implementation of the current SDK. Some of the goals of RhinoCommon are:

• Faster for some data types: All data types in Rhino.NET were wrappers around C++ pointers created on the unmanaged heap. This was a mistake when working with primitive data types (like 3d points and vectors). Primitive Rhino data types in RhinoCommon are written as value classes and implemented entirely in .NET. This allows the data types to
  • be placed on the stack when only temporarily needed in a function
  • no requirement to call through to C++ to simply get the value of something like X,Y,Z in a point
  • no potential fragmentation of the C++ unmanaged heap because the type is entirely inside of .NET and under the control of the garbage collector
  • operator overloading works much cleaner since value types can not have a value of null
• A .NET style SDK:
  • Multiple appropriately named namespaces in an attempt to better organize the SDK.
  • Properties are used when they make sense
  • All parameter arguments are clearly named to describe their purpose
  • Standard .NET style events are used instead of forced subclassing when it makes sense
  • Descriptive enumerations are used instead of vague int for function parameters and returns
  • .NET attributes are used where appropriate
  • This is not a one-to-one conversion from C++ SDK to .NET
  • Removal of separate const/non-const versions of classes.
• Improved documentation:
  • We are making an effort to provide descriptive XML comments for all classes/functions/properties
  • The current SDK documentation can be found here
• Platform neutral: RhinoCommon is built to run on Windows 32bit, Windows 64 bit, and Mac OSX (currently only 32 bit)

The Python plug-in for Windows/Mac, Grasshopper, and all Mac based .NET plug-ins are being built against RhinoCommon. This lets us figure out where the problem spots are in RhinoCommon and make changes.

During 2011, Grasshopper was rewritten by David to be based on RhinoCommon. This was a big project and took some time to complete, but once done it provided performance improvements and better memory management. This has also been a step toward being able to run Grasshopper on Mac Rhino!

Grasshopper will maintain a special build of RhinoCommon to allow it to continue to run on Rhino 4. Because Grasshopper needs to run on Rhino 4, there will still be some dependencies in Grasshopper on the older Rhino.NET SDK.

The Python script engine is entirely based on RhinoCommon. All python scripts directly use RhinoCommon to work with Rhino. I'm finding that typically if something in RhinoCommon is difficult to write a python script for, then the RhinoCommon SDK needs to be fixed in that area.

RhinoCommon on Mac is executed through an embedded Mono framework.

I'm still learning all of the ins and outs of Mono so there will probably be some hiccups along the way. I'm currently trying to figure out the best way to write user interfaces for OSX and Mono. System.Windows.Forms has some problems which I am trying to better understand, but there are other user interface frameworks that I need to experiment with for writing more “pure” OSX style user interfaces.

The Mono development team appears to be pretty active and are adding more and more improvements to their OSX version.

One of the areas that developers need to be aware of is any .NET code that uses P/invoke will have problems on OSX/Mono. P/invoke is a technique to call unmanaged native functions from .NET code and typically these native functions are functions made available by the Windows Operating System. These native functions won't exist on Mac and therefore will throw an exception at run time.

All of .NET is not yet implemented in Mono (although an awful lot is.) A good tool to use for finding potential problem spots is the Mono Migration Analyzer (MoMA). This application can examine your DLLs to see find functions that are not supported by Mono.

Many commercial .NET components use P/invoke so this is something I highly recommend you investigate.

RhinoCommon is composed of the following pieces. These files are included with Rhino 5 / Mac Rhino.

• RhinoCommon.dll - This is a pure .NET DLL that plug-ins can reference and use to work with Rhino.
• RhinoCommon.xml - This is an XML file that contains SDK documentation comments specific to RhinoCommon.dll. Programming development environments like Visual Studio and MonoDevelop use this XML file to display tooltips and other helpful information while the developer writes code
• rhcommon_c.dll, monomanager.rhnp - These are C++ shared libraries compiled for specific target platforms (Win32, Win64, and OSX). These libraries are used by RhinoCommon, but should never be directly accessed by plug-in developers.