We’ve created a package for Rhino 7 windows. Intermittently, when trying to install it via the package manager, or via yak.exe, we get this error.
The process cannot access the file something.dll because it is being used by another process
e.g.,
It’s a different DLL every time. Investigations show it’s during the Directory.Delete of the temp directory created during install.
I believe it’s due to some security software we have at our company, but I’m wondering if anyone else has seen something similar, or has any ideas for fixes/workarounds?
Hey @James_Duley ,
Are you trying to install it via Rhino 8 or Rhino 7?
Would you be able to share this package with me so I can test it? If you don’t feel comfortable sharing to the world you can DM me it 
Hi @CallumSykes, apologies for not getting back to you sooner, we’ve been going back and forth with the technical support of the security software, Airlock Digital, that is causing the problem.
Investigations have shown that, during the yak Install function, it unzips it to a temporary directory, copies the DLLs to the PackageFolder, then deletes the temporary directory.
The problem is, when the DLLs are copied from the temporary directory, Airlock detects they are being read into the process. Airlock then also opens the files to read their contents for verification. However, it isn’t always fast enough, so when Yak/Rhino tries to delete the temporary directory, there is a sharing violation, because Airlock is still reading one of the files. This leads to the exception seen in the image above.
Airlock are unwilling to change the way their tool behaves, so would it be possible to add a workaround in Yak by adding retry logic for the directory delete?
Thanks for getting back to me @James_Duley, no worries about the delay, all in good time
Rhino 7 won’t recieve (many) updates anymore unless there is something that breaks Rhino 7 entirely, i.s an OS change on Windows/Mac. Our focus is on Rhino 8 and 9. I would assume this issue still persists in Rhino 8 however. Do you use Rhino 8 at your company, and if so could you test to see if this issue persists?
Yes, we’re in the process of moving to Rhino 8. It still happens in Rhino 8 with NETFramework runtime, but not with NETCore. I’m not sure if there’s something fundamentally different there, or the timings are just a bit different with NETCore such that the issue doesn’t occur. Do you know if the install process is any different when running in NETCore mode?
I did that testing with one of our smaller plugins, unfortunately our main one only works with NETFramework at the moment. However, if NETCore is guaranteed to work, that might increase the priority of the upgrade.
The code that rhino runs is the same AFAIK, the dotnet runtime however is vastly different, it’s designed to be compatible, but it is not 100% identical thankfully, and there are many welcome bug fixes and performance upgrades in there.
Best of luck with moving to a multi-targeted plugin, I found the process mostly quite seamless and hopefully our docs guide you well. If not, we’d love some feedback on what you struggle with so we can better help.
I’ve found we can get away without a multi-target plugin, I just had to change a couple of dependencies. One of them had a netstandard2.0 and a net462 target, but the net462 target, that was picked up by default was using some functions flagged by compat.exe. There was no nice way to force it to use netstandard2.0, but I found this workaround worked.
1 Like
