Is there a way of targeting a version of Rhinocommon by feature? Specifically, find coincident Brep Components is not supported in every version of Rhinocommon, and I want to build a plugin on the earliest version that supports this feature.
Hi @jacobblitzer - I’ve moved this to a new topic.
There are many different versions of RhinoCommon available on nuget. You can choose to compile against any of these
Thanks, what I’m trying to find out, is what version of RhinoCommon is the first version where the method Im using ( FindCoincidentBrepComponents)supported. At the moment, my method is installing progressively older versions more or less one after the other using the Nuget manager until i have the earliest one that supports this method. Is there a more targeted way of targeting a version of Rhinocommon by feature?
Why is this important?
In general you should want users to be using the latest service releases of Rhino, as they are the most stable and they contain important fixes.
I’m planning on releasing the plugin to the community at large, and for one reason or another some users prefer to avoid updating Rhino 6. I want to prevent the plugin from referencing a version of rhinocommon that these users (users say, that haven’t updated rhino 6 in over a year) dont have.
Well, if you don’t own a legal copy, you can’t upgrade. So there’s that.
there is that. I also personally know a few people that don’t upgrade due to the fact that they’re worried about small changes bricking their workflow… In any case, i take it there is no method of selecting a version of rhinocommon based on the when a method was added?
Not really any other method other than going through old versions on nuget like you have been doing.
Something to point out is that Rhino 6 supports both backward and forward compatibility checks when it loads a .NET based plug-in.
You may use reflections.
I don’t understand why new methods (& members) are not documented in the API. In RhinoCommon it’s as simple as adding a note in a comment “Introduced in Build so and so”. Or whatever approach which slips through the documentation system being used.
If always using the same leading phrase like “Introduced in Build…” one could easily find the version when a member was introduced.
I’ve asked for this many times before. I think that solving this should be put on the pile.