Recommended usage of Yak for versioning, regarding Yak's own dll version, and the plugin version

  1. 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?
  2. 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?
  3. 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-
Yak install --source=tweener-
Yak install tweener-

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.

Yak.Core.dll isn’t part of our public SDK. The version can and will increase from release to release. If you’re going to use it, I recommend doing so in a controlled environment where you have control over the version of Rhino that the users of your plug-in have installed.

Yes, the plug-in’s ID should be the same for all versions of the plug-in, regardless of distribution method. I think we need to do some work to make it easier to migrate from a manually installed plug-in to one installed by the package manager (without manually editing the registry). However, I can’t reproduce the “ID already in use” error going the other way; it should be possible to uninstall a package, restart Rhino, and manually install the same plug-in via drag/drop without any errors.

If you get the “ID already in use” error, check in _PluginManager to see which .rhp is being loaded first.

The --source argument accepts an alternative server (i.e., or you can use the path to a directory that contains .yak package files and it will treat that as if it was a server. So, assuming the file “tweener-” is in the current directory ("."), you could use…

yak install --source=. tweener

You could use this technique to install a debug/development package for testing, rather than using the manual drag/drop method. That will make it easier to switch back to the release package once it’s ready. You could debug your project by attaching to Rhino.exe, instead of starting it from VS.

This assembly attribute isn’t currently used by yak.exe, but I do plan to support it. For now, the only way to add an icon is via the icon_url field in manifest.yml.

Thank you, @will
So, I guess, it’s better not to try and reference Yak.core.dll in order to check for an updated version. I thought others were also trying to do that (saw someone asking about that somewhere around here, but can’t find it right now). But anyway, it’s fine, the user will just have to check for a new version manually, at least for now until I figure out how to issue a get/post request over a socket to the yak server.
Ok, the line

yak install --source=. tweener

seems to be a perfect template to put in post-build events - much more elegant than what I did until now which was to overwrite old versions with the development version. I’ll have to check if it works together with edit-and-continue but why shouldn’t it.
(I guess one never settles with a build pipeline; these things keep evolving forever … :slight_smile: