Rhino_DotNET will be discontinued

Edit: this is no longer true. Rhino_DotNET will still be available in Rhino6 albeit in a somewhat reduced form. It will probably disappear in Rhino7. Once we have a webpage up explaining what, how and why, I'll post a link to it here.

Come Rhino6, the old Rhino_DotNet SDK will no longer be available. This means the Legacy VB/C# components will no longer work, nor will any GHA files that depend on that SDK. It'll be pure RhinoCommon all the way.

If you are still using Rhino_DotNet.dll, please stop doing so asap. If you need functionality which isn't yet available in RhinoCommon, let us know and we'll make sure it gets added.

David Rutten

david@mcneel.com

Tirol, Austria

Replies to This Discussion

Permalink Reply by David Rutten on October 23, 2013 at 8:47am

We decided on a new approach, but note these are not promises yet. We're going to try and keep Rhino_DotNET available, but all classes and methods will be marked as deprecated. A recompile will be required before any of this code will run on Rhino6.

Furthermore some classes will become unusable, definitely the MRhinoPlugin and probably the MRhinoCommand classes. So if you want an RHP that uses Rhino_DotNET, you'll have to reference both RhinoCommon and Rhino_DotNET and provide your plugin and command data through RhinoCommon alone.

The ultimate removal of Rhino_DotNET has now been postponed to Rhino7.

David Rutten

david@mcneel.com

Seattle, WA

Permalink Reply by Steve Baer on October 28, 2013 at 8:24pm

Yes, I'll put together a post about this. Rhino_DotNet will exist as a deprecated API in V6. There are some finer details I need to point out when I get time to write a post on this.

Permalink Reply by David Rutten on October 9, 2013 at 2:37pm

Paul,

is the code you're worried about RHP, GHA or Vb/C# script code?

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Paul N Jeffries on October 10, 2013 at 4:05am

A little bit of everything, but mostly RHP stuff - most of my GHAs I converted over to RhinoCommon when grasshopper itself did, although it's not entirely clear-cut since a lot of my grasshopper components actually just feed data back into a separate plugin and then get stuff back, converting between RhinoCommon and Rhino_DotNet as necessary, so they're still dependant on RDN even if only indirectly.

I do also have some old legacy VB.NET and C# scripts floating around, although they're comparitively short and are mostly to do job-specific things on ancient projects, so I'm not too worried about them. The plugins and their ability to interact with grasshopper are the absolute core of my workflow, however.

Permalink Reply by David Rutten on October 9, 2013 at 2:40pm

Incidentally, this is nothing to do specifically with Grasshopper. It seemed like Rhino_DotNET would not be available in Rhino6, and therefore it could also no longer be available in GH. If however we decide to maintain the legacy SDK after all, then Grasshopper will also happily maintain legacy script components.

David Rutten

david@mcneel.com

Tirol, Austria