Yak.exe --source broke in Rhino 8 SR 15

Hi McNeel,

the latest 8SR15 has broken yak.exe on our machines.

Related posts:
Rhino 8 - Yak install command fails

Installing package for Rhino 8 using Yak.exe

We deploy our in-house plugins by dropping them into a folder on our network drive, e.g. \\x-drive\yak_folder. A Rhino start-up script runs once every day, and checks if the package version on X: drive is newer than the one installed, and runs yak if this is the case:

"C:\\Program Files\Rhino 8\System\yak.exe" search --source="\\x-drive\yak_folder"

With the latest 8 SR15, running yak.exe search/install with a --source folder option is broken:

System.AggregateException: One or more errors occurred. (Could not load file or assembly 'System.Runtime.Caching, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.)
 ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.Caching, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'System.Runtime.Caching, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Yak.PackagesClient.GetAll()
   at Yak.Cli.Commands.SearchCommand.Search(String query, String source, Boolean pre, Boolean all)
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at Yak.Cli.Commands.SearchCommand.Execute(String[] args)
   at Yak.Cli.Program.Main(String[] args)

I tried both, the UNC path '\x-drive' and the drive letter ‘X:’

What are my options?

a) Download the latest(?) yak.exe from https://files.mcneel.com/yak/tools/latest/yak.exe
as per this post:
Installing package for Rhino 8 using Yak.exe

This seems to work. Why is yak.exe from https://files.mcneel.com newer than the yak.exe that comes with the latest SR?

Would I put the ‘latest’ yak.exe on the same network drive, and run it from there instead of the installed version in C:\Program Files.…? How do I know that the latest version from https://files.mcneel.com is not more broken than the one that comes with Rhino? I guess I would have to try both, and hope that one works?

b) Add the local network path to
Options > Advanced > Rhino.Options.PackageManager.Sources, as per this page:

I can’t get this to work. PackageManager does not list any of the yak packages that sit in our network folder.

c) as b), but copy our local yak packages to C:\temp\Yak8 first.
Options > Advanced > Rhino.Options.PackageManager.Sources now points to

C:\temp\Yak8;https://yak.rhino3d.com

Make sure ‘Automatically update packages when Rhino starts’ is enabled in the PackageManager

This works rather nicely. Are there any other robust approaches to deploying local packages that I have not considered?

Thank you
-axel

Hi Axa

Rhinos automatic update doesn’t work for your yak packages on a network drive?

This surprises me. I’d expect either to work, drive letters have worked for me in the past.

It seems to be yak 0.12.14, which is an earlier version from before this issue which I believe is 0.14. You can check with ./yak.exe --version

I used to use this and for the most part it worked well

I’ve created a ticket for the issue. It seems you have a workaround for now which is to use the latest download link. You could also keep a copy of Yak locally and just use that version for your scripting purposes.
https://mcneel.myjetbrains.com/youtrack/issue/RH-85606/Yak-fails-to-due-DLL-conflict

Hi Callum,

I think there are two distinct but possibly related issues here:

a) we are unable to configure PackageManager to search in and install from a network drive. This has been the case since we moved to Rhino 7;
b) yak.exe --source broke in Rhino 8 SR 15.

To reply to your questions…

Correct. This is because we can’t actually get PackageManager to install from a network drive. We can, of course, drop the yak file into Rhino. But since PM doesn’t know where it came from, it can’t auto-update it.

This is the reason why we have to install our in-house packages via yak.exe, not PackageManager.

Yes, that is correct. 8SR15 comes with yak 0.14.0, whereas the version from https://files.mcneel.com/yak/tools/latest/yak.exe
is 0.12.14, which is older and still works with the --source option.

Yes, I do have a workaround, but it’s not to use the ‘latest’ download link, because this might break as well at some point.

My workaround is to copy our yak packages from the network drive to a temp folder on C: first, and point PackageManager to install from this location.

-axel

This endpoint is not going to be updated anymore, so you can rely on this being the same version.

Not optimal, but it works for now. I’d rather we could provide a more elegant solution for you however.

You’re using a standard network drive which is mapped to users computers, adding the path to it in the options Rhino.Options.PackageManager.Sources correctly and if you search for your package in the Package Manager it doesn’t appear? (Is it just slow?) Is it an internal server, or cloud storage like Google Drive?

This is true for Rhino 7 and 8?

There is a ticket to get this resolved.

Hi Callum,

That’d be great. Thank you for looking into this.

Correct. It’s not just slow – our packages on the network drive simply don’t show.

The packages do show up if I add a folder on C: drive to Rhino.Options.PackageManager.Sources

It’s a normal Windows file server. Not cloud-based.

True for R7 and R8.

Great. Thanks again

-axel

1 Like

Thank you for reporting this exception. RH-85602 has been fixed and will ship with the next service release of Rhino, 8.16. The next service release candidate is scheduled for Tuesday.

In the meantime, if you need to use a self-contained yak.exe please grab one from the link below. This is the version that shipped with Rhino up until 8.14.

I’m hoping to have better documentation for these self-contained/standalone yak executables soon.

@axa, with the self-contained yak.exe shared above, are you able to reinstate your Rhino start-up script?

Hi Will,

our start-up script relies on the yak.exe that comes with Rhino, rather than the the self-contained yak.exe from https://files.mcneel.com/

You seem to have the fix in 8SR16 RC3, so that should work for us.

We are rewriting our auto-update script to rely on PackageManger, rather than yak.exe. PM appears to be a lot more robust. Our updater is now going to copy the latest local yak packages from our network drive to c:/tmp, and point

Rhino.Options.PackageManager.Sources

to that location. Hopefully, this should also avoid situations such as this one:

Thank you for getting this fixed.

-Axel