- If one references Yak.core.dll in a plugin in order to check for new versions, does one risk referencing a version that users don’t have in their local Rhino systems folder? The solution to the analogous problem about Rhinocommon.dll was to install an old version with nuget, but Yak.core.dll is not on nuget so that mitigation doesn’t apply to Yak.core.dll. Or does Yak.core.dll not change within Rhino 7?
- Is it correct to assume that the plugin-id should not change throughout package versions (as we’re used to from the versioning behavior of all the Grasshopper plug-ins on food4rhino)? If so, after uninstalling a specific version of a package with yak, the Rhino plugin manager still says “id in use” when I try to install a new version of the RHP for debugging. How does one tell Yak to release the id for installation of a new version, so that one can install a new local version of the plugin for debugging?
- Alternatively, should one install a new debugging version of the entire package locally through Yak? I tried that, but none out of
Yak install --source tweener-0.0.0.102-rh7_2-win.yak
Yak install --source=tweener-0.0.0.102-rh7_2-win.yak
Yak install tweener-0.0.0.102-rh7_2-win.yak
etc. seem to work.
4. Yak doesn’t seem to recognize the icon even though AssemblyInfo.cs contains a line
[assembly: PlugInDescription(DescriptionType.Icon, “Tweener.Properties.Resources.tweening.ico”)]
and the string is the name of an existing resource in the assembly. How does Yak parse this string? Are there any hidden requirements that yak makes on the resource in order to recognize it?
Apologies if one or the other of these questions was answered elsewhere.
Thanks in advance.