Now that the RhinoScriptCompiler.exe works in Rhino v7.3, I notice that the plug-ins created with this version won’t run in Rhino v5. In fact, the <MinimumRhinoVersion> tag in the .rhc file seems to be bound to v6. Is it expected?
Edit: Reading old posts, if nothing has changed since April '20, I suppose this post from @stevebaer is the closest one from an answer.
If I read it correctly, I suppose the RhinoCommon from v6 SR0 is embedded in the RhinoScriptCompiler.exe and it is not possible anymore to specify a SDK. If anyone could confirm?
Hi @stevebaer, does that mean that if a PlugIn is compiled for V6 with the new compiler, any RhinoCommon methods added after V6 SR0 are not supported ? Asking for a friend.
In a way, yes. If you mark a plugin as V6 compatible, then that plugin will load in V6. If the script that the plugin embeds happens to call a function that was added in V7, then the script will fail.
i understand that there can be no upward compatibillity, that was not my question. I’ll try to ask better:
What is if the compiled script uses functions which where added or changed with V6 SR17 ? Will the script fail if it is bound to The RhinoCommon version shipped with SR0 because it cannot find the method ? If a RhinoCommon method was changed in a higher SR but the same major version, will the script then fall back to use the SR0 (faulty) method ?
If all this is the case, why don’t you include the newest SR instead of the oldest ?
_
c.
There is no binding to an older version of a function. At runtime the function that the script attempts to execute is found and called. If we change how a function works in a service release, the behavior of the script will change when you run it in a different service release. There is no difference for this if you are running the script stand-alone or bundled up in an rhp via the script compiler (script bundler would have probably been a more appropriate name.)
If you know of a function that was added in a service release that you use in a script, then setting the service release in the yak package name is a good approach. Yak is smart enough to know that something shouldn’t be installed in an older SR when the package is named appropriately. This is covered in the “Distributions” section of the yak documentation at