Rhino 3D is a widely used computer graphics and CAD application that can be extended with plugins and add ons. If you develop a commercial Rhino plugin, software licensing can control access to the plugin, manage different editions, and support subscription or perpetual licensing.

Because Rhino plugins can be developed using .NET and C#, the basic licensing implementation is similar to licensing other .NET applications. However, there are some Rhino specific considerations around how the plugin is packaged, loaded, and distributed.

What Does Software Licensing Code for Rhino 3D Need to Do?

A licensing system for a Rhino plugin generally needs to perform four tasks.

‍

License Activation and Verification

The plugin should verify that the customer has a valid license before enabling licensed functionality. This can involve contacting a licensing service when the plugin starts or when a customer activates their license.

‍

Machine or Installation Binding

If a license is intended for a specific workstation, the plugin can associate the activation with a machine code. This makes it possible to limit how many computers can use the same license.

‍

Entitlement Enforcement

Licensing can also determine which features are available. For example, a Basic edition could provide a subset of the plugin's functionality while a Professional edition enables additional tools.

‍

Handling Connectivity Requirements

Some Rhino plugins can assume that the user's computer has Internet access, while others may need to work in restricted or offline environments. The licensing implementation should reflect how the plugin is actually deployed.

‍

Using a Rhino 3D Licensing SDK

Since Rhino plugins can be developed with .NET, a .NET licensing SDK can be integrated directly into the plugin project.

For Rhino 8, for example, you can add the Devolens licensing library to the plugin project and reference the appropriate .NET assembly. The Devolens SDK provides both standard and cross platform versions, allowing you to select the version that matches your deployment requirements.

For a Rhino plugin that only targets Windows, the standard library may be sufficient. If the plugin needs to support other platforms, the cross platform version can be used instead.

The important point is that licensing becomes part of the plugin rather than requiring a separate licensing application.

Implement License Verification in Rhino 3D

Once the SDK has been added to the project, the plugin can perform license activation using the same basic verification flow used by other .NET applications.

A simplified example looks like this:

var licenseKey = "YOUR_LICENSE_KEY";
var publicKey = "YOUR_RSA_PUBLIC_KEY";
var auth = "YOUR_ACCESS_TOKEN";

var result = Key.Activate(
   token: auth,
   parameters: new ActivateModel()
   {
       Key = licenseKey,
       ProductId = 1234,
       Sign = true,
       MachineCode = Helpers.GetMachineCode()
   });

if (result == null ||
   result.Result == ResultType.Error ||
   !result.LicenseKey.HasValidSignature(publicKey).IsValid())
{
   Console.WriteLine("The license does not work.");
}
else
{
   Console.WriteLine("The license is valid.");
}

The exact implementation should be adapted to the plugin's user interface and activation flow. For example, the plugin could provide a command or settings panel where the customer enters their license key, then store the resulting licensing information for subsequent launches.

For the complete API reference and implementation details, the documentation should be used alongside the plugin integration.

Enforce Features and Entitlements

Once the license has been verified, the plugin can use the license information to determine which functionality should be available.

For example:

if (license.HasFeature(1).IsValid())
{
   // Enable feature 1
}

if (license.HasFeature(2).IsValid())
{
   // Enable feature 2
}

This allows a single Rhino plugin to support multiple editions without maintaining separate plugin builds for every pricing plan.

It can also be useful for gradually introducing new functionality. A feature can be enabled for customers whose licenses include the corresponding entitlement without changing the core plugin architecture.

‍

Choosing a Machine Code for Rhino 3D Plugins

Machine based licensing is particularly useful for desktop Rhino plugins where a license is intended for a specific workstation.

The licensing SDK can generate a machine code that is sent during activation. The licensing service can then use that identifier to determine whether the license has already been activated on another machine.

The appropriate machine identification strategy depends on the deployment environment and how much flexibility customers need when moving a license between computers.

For example, a node locked license may allow one activation, while another licensing model could allow several activations for the same customer.

‍

Handling Licensing in Production

The initial license check is only one part of a production licensing implementation.

A Rhino plugin should also have a defined behavior for situations such as:

1. The customer enters an invalid license key.
2. The activation limit has been reached.
3. The licensing service cannot be reached.
4. The customer's subscription has expired.
5. The customer changes their license or purchases additional functionality.
6. The plugin is running in an environment without reliable Internet access.

For online deployments, the plugin can periodically verify licensing information against the licensing service. For environments where Internet access is restricted, offline licensing can be used instead.

Learn more about offline licensing

For larger deployments, a dedicated license server can also provide centralized control over licenses and activations.

Learn more about the Devolens License Server

‍

Rhino 3D Plugin and Dependency Considerations

The licensing library needs to be compatible with the Rhino version and .NET environment targeted by the plugin.

The original Devolens Rhino integration guide used Rhino 8 and the netstandard.2.0 library. It also described adding the licensing assembly as a project dependency and installing Newtonsoft.Json through NuGet.
When updating an existing plugin, it is therefore worth testing the licensing integration against the exact Rhino version and runtime configuration used by customers rather than only testing it in the development environment.

This is especially important when distributing a plugin to many customers, since the licensing layer becomes part of the plugin's deployment and update process.

‍

A Practical Approach to Rhino 3D Software Licensing

For most commercial Rhino plugins, the implementation can remain relatively small.

The plugin needs to:

1. Collect or retrieve the customer's license information.
2. Generate a machine code if the license is device bound.
3. Activate and verify the license.
4. Check the customer's entitlements before enabling licensed functionality.
5. Handle expiration, activation limits, and connectivity failures.
6. Test the licensing flow using the same Rhino versions and deployment configuration used by customers.

This keeps the licensing logic separate from the actual CAD functionality while allowing the plugin vendor to change pricing plans, editions, and licensing rules without rebuilding the entire licensing infrastructure.

‍

Conclusion

Software licensing for Rhino 3D plugins follows many of the same principles as licensing other .NET applications, but the licensing layer needs to fit naturally into the Rhino plugin architecture and deployment process.

A licensing SDK can handle the core verification flow while allowing the plugin to enforce features, bind licenses to machines, and support different commercial models.

With Devolens, Rhino plugin developers can integrate licensing into their existing .NET projects and use the same licensing infrastructure across different products and customer plans.