Components not loading into Grasshopper on startup. Has been occurring since this weekend. Here’s a snippet:
An error occured during GHA assembly loading:
Path: C:\Program Files\Rhino 7 WIP\Plug-ins\Grasshopper\Components\Kangaroo2Component.gha
Exception System.UnauthorizedAccessException:
Message: Access to the path ‘C:\Users*\AppData\Roaming\Grasshopper\PluginLoading.txt’ is denied.
An error occured during GHA assembly loading:
Path: C:\Program Files\Rhino 7 WIP\Plug-ins\Grasshopper\Components\MathComponents.gha
Exception System.UnauthorizedAccessException:
Message: Access to the path ‘C:\Users*\AppData\Roaming\Grasshopper\PluginLoading.txt’ is denied.
An error occured during GHA assembly loading:
Path: C:\Program Files\Rhino 7 WIP\Plug-ins\Grasshopper\Components\ScriptComponents.gha
Exception System.UnauthorizedAccessException:
Message: Access to the path ‘C:\Users*\AppData\Roaming\Grasshopper\PluginLoading.txt’ is denied.
An error occured during GHA assembly loading:
Path: C:\Program Files\Rhino 7 WIP\Plug-ins\Grasshopper\Components\SurfaceComponents.gha
Exception System.UnauthorizedAccessException:
Message: Access to the path ‘C:\Users*\AppData\Roaming\Grasshopper\PluginLoading.txt’ is denied.
An error occured during GHA assembly loading:
Path: C:\Program Files\Rhino 7 WIP\Plug-ins\Grasshopper\Components\TriangulationComponents.gha
Exception System.UnauthorizedAccessException:
Message: Access to the path ‘C:\Users*\AppData\Roaming\Grasshopper\PluginLoading.txt’ is denied.
Weirder and weirder. The file is created (as it should), the file is deleted (as it should), and yet access to the file is unauthorised. The three things I thought might cause this have been ruled out.
When you say “both v6 & v7” you mean you reinstalled both, or is it failing on both?
That’s particularly bad news for v6, I can make the loading check continue on failure tomorrow for v7, and next week’s Beta will have that fix, but i don’t know when or if there’ll be a Rhino 6 service release.
So unless the underlying problem can be solved, v6 is busted for the foreseeable future. I’m searching for possible reasons why Windows would restrict access to the app data folder, but I can’t do much until office hours tomorrow.
Okay, before I call it a day, you running any anti- virus scanners? If yes, any chance you can tell it to not look at the folder C:\Users\thans5\AppData\Roaming\Grasshopper\ ?
Interesting development, this whole plugin load tracking mechanism is already fail-safed up to the neck.
I’m now wondering if some other code is keeping tabs on files in that folder and trying to handle the file creation/deletion.
I’ve reverted to Rhino 6 SR7. Only issues with Grasshopper are breakpoint: components built against a newer minor version of the Grasshopper SDK. Those components fail, but all else is working normally.
When I revert to a previous v7, I’m getting the errors listed at the beginning of this thread.
I’ve redesigned some of the code involved here, and I’ll also make the checking disableable (is that a real word?), so hopefully next Tuesday you can try the latest Rhino 7 release again.
Please try and install this Rhino7 WIP update. The version should be 7.0.20262.3365, 2020-09-18.
There are three changes in this build to do with the loading issue:
I found and fixed a possible path to failure, so even if access is still unauthorised, it should no longer cause the plugin loading to be aborted. But since I could not repeat the problem, I do not know for sure whether the gap I filled was in fact the gap that tripped you up.
The PluginLoading.txt file is no longer deleted when empty. So it doesn’t keep popping into and out of existence all the time, its contents just keep changing.
There’s an option in the grasshopper_kernel.xml settings file which disables the load checking altogether. There’s no UI for this, you have to edit the xml by hand to change the behaviour. The following entry (which will only appear after Grasshopper has been loaded and closed without crashing) must be changed from true to false: <item name="ObjectServer:TrackPluginLoading" type_name="gh_bool" type_code="1">true</item>
Please only change that xml entry if the loading still fails.
Shame. I thought all the holes were plugged this time around. I’ll have another dig though the code, and possibly I’ll disable this feature by default for the ‘official’ weekly beta next week.