If I run Rhino normally, I do not get the error and the converters work fine. In this situation I am also using the custom components that were compiled, so I don’t think there’s a clash between .dll files, though there could be because we do include the following packages as they are used in our custom component.
Okay after some investigation it appears for be a Rhino/GH issue and which user is being used for the AppData folder.
See picture below. The folders in the top row show the Grasshopper libraries and Rhino plugins present in the Default user’s AppData, while the folders in the bottom row is for my personal user. You can see in the bottom one that the GH and Rhino connectors (I installed the 2.6.5 versions now) are present in my user.
All the way on the right you can see that Speckle manager/kits/accounts is in my user’s appdata folder.
If I install version 2.7 of the connector (so Rhino + GH connector), both connectors show up, but we’re back to the original issue, where the kits and accounts are not found.
So it appears to me that GH and Rhino are looking in different users…
Here’s some additional context too that might be useful:
When developing/debugging, the kits should get copied in the right location (appdata) when you build the Converter project.
So I would suggest always rebuilding the whole Connector solution.
Accounts, instead need to be set up manually from Manager or Desktop UI (eg the Rhino Connector).
Both accounts and kits should live in %appdata%\Speckle.
You should try avoiding mixing a development version of the connectors and the ones from Manager, as there might be involuntary crossovers.
I’d suggest cleaning your environment by removing any version of the Gh/Rhino connectors and trying again.
Also, as you noticed, from 2.7 onwards the GH&Rhino connectors are bundled together when installing from Manager, not sure if that’s part of your problem as well!
So I tried to clean my environment completely by removing everything Speckle related, and I removed any Library Folders I had added in the Grasshopper Developer Settings where additional dlls were loaded. I checked everywhere for SpeckleCore2.dlls and there were none left that could be possibly be loaded. After I uninstalled my Speckle Managers I made sure that the AppData\Roaming\Speckle folders were deleted.
Then I installed the Speckle Manager v2 and the Rhino + Grasshopper connector v2.7.
Still didn’t work.
Then finally I tried to copy the Kits folder from <MyUser>\AppData\Roaming\Speckle to Default\AppData\Roaming\Speckle, and it finally worked.
So it doesn’t seem to me that it’s the same issue as Merijn had (which coincidentally I was there for and we frantically trying to fix it, and I actually didn’t have that issue that time ). It seems rather that the issue is that different AppData folders are being used in different situations (one by Rhino and one by GH) for some reason… Not sure how this happened, but I’m starting to think that it’s an issue I might have to bring up with McNeel…
When I open the Special Folders > Components Folder from GH, it opens it in the Default user, but SpeckleRhino2 is installed in my user folder…
I also had to copy Accounts.db from my my user to the Default user in order for the GH connector to find the accounts I logged into in the Manager for Speckle
@knut.tjensvoll this is rather odd! Do you know if your machine has any sort of virtualization or network account management set up?
If you type %appdata% in windows explorer, where does it take you?
And what if you type Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); in a gh C# node?
I remember Default Kit error being caused by installing of different versions for Rhino and Grasshopper connectors. I had it before and once i made sure they were same, it disappeared on my end.
Can you please do an additional test for me? What does Environment.ExpandEnvironmentVariables("%AppData%") return if you put that inside a GH C# node instead?
Sorry to have you poking around… but it’s the only way we can figure out what’s going on with your specific setup.
As I understand it, the Default user in Windows is not something we should ever be touching, as it’s the “template” for any new user’s in that machine.
I’ve got one extra test for you…It’s weird that the SpecialFolder.ApplicationData points to the default though, could you try and check if this line of code does return your user profile (not the Default one)
We may be able to work around your issue by just grabbing the proper user profile and appending /AppData/Roaming at the end, but i’d like to confirm that it actually points to the user you’d expect
We might push a “preliminary version” of this fix for you to test sometime today/tomorrow, but meanwhile I have 2 new questions for you @knut.tjensvoll
We’re using the same logic in the KitManager and the Account selection node, so it just dawned on me… does your account node pick up the accounts setup in Manager properly?
Just to triple check, that path C:\Users\909587 is in fact the correct path for your current user, right?
Thanks again for your patience while we figure this out!
@AlanRynne Thanks for helping out! And sorry that I haven’t responded, but it’s been quite busy. I unfortunately don’t have time to test today, but I’ll definitely test it on Monday or maybe even during the weekend.