ayo ayo - got a lil issue that I want to throw out for the team
We’ve been going through the growing pains of moving all of our servers / machines to a DaaS system with IronOrbit and I was giving speckle 2 a try today with my VD when I encountered an issue with the installation process, specifically an issue with local appdata.
Our VD structure routes all roaming data into a directory that is accessible to each machine the user is assigned to. However, it doesn’t change anything that would be placed in local / locallow and keeps those directories on the disk associated with that VD.
Here is the path for a typical machine C:\Users\<user>\AppData\
Now the path using our VD machine \\S00769FR01\users$\\<user>\AppData\
I used the speckle manager to install everything and was able to link my account, but when I tried throwing a grasshopper component down a bunch of flags were raised around not having access to the right database. It seems like the gh connector (which I believe is in roaming) is searching for a database / cache, I believe it’s AppData\Local\SpeckleSettings, but can’t find it since it’s located on the disk space of a VD machine while the connectors are being stored on the actual VD system structure.
We’ve experienced this same issue with other software and we’ve been putting together some solutions for re-routing some of the files and shortcuts during their installation process. I was figuring we could do the same, but I wasn’t sure what exactly would need to be re-routed or if changing the location of the database would cause speckle to break So, I guess my request for halp is will modifying the locations of local app data cause an explosion of some sort?
Short answer: yes, Speckle is quite heavily reliant on the %appdata%/speckle folder for kit, account and cache management.
The is under C:\Users\USERNAME\AppData\Roaming\Speckle, note the roaming and not local folder (like Speckle v1) so I’m a bit surprised that it’is causing you issues…
Maybe we could have quick debug session to see exactly what’s happening in your local environment if you have the time?
ohh interesting! I was concerned that I mixing up v1 and v2 stuff, I thought I had figured out what belonged to what but I’m glad that wasn’t the case. I would be happy to set some time up with ya. To the emails!
@teocomi to pass along some more info, it seems like the main error comes from when the account node is dropped on the canvas, below is the error message thrown
I’m a bit puzzled about this since non of the messages seem to be associated with speckle. The value list account node shows up blank when you close out of that message.
uh oh, necroing this thread. I believe the issue of mapping the manager install on a VD machine has come back to life.
I downloaded the most recent manager and ran the install process, added my accounts and the grasshopper + rhino (connectors through the manager) with no issues. When I tested both connectors there were no kits available. I poked around the folders where the installs were hiding and the manager installs everything to the C:\users\<user>\appdata vs \\s00769fr01\users$\<user>\AppData. Ideally we would need the manager to map the installs to the latter.
Tried poking at this again to see if I could discover any additional information. Nothing really new came up, but I figured I could illustrate the issue a bit better. Just to reiterate, this is solely a VD issue but is blocking our efforts for deploying speckle firm wide at sasaki.
The issue seems to live in two parts: installing the files needed for connector, and accessing the data from the connector
When installing the manager it splits up the files into two different location instead of the main appdata location. Kits and manager stuff gets placed correctly in the VD appdata folder, but other database stuff get placed in C:\Users\<user>\AppData\Roaming\Speckle.
I copy and the account data over to the folder we would want, but the manager no longer finds it.
The other issue is around connectors (I’ve only tested this with the rhino+gh connector). When using either grasshopper or rhino it can quickly locate my account information but it blocks any sort of operation node with the issue not being able to locate the kits and converters.
My assumption with all of these errors is that file pathing is not consistent between speckle.core and the manager installation, but I haven’t done any testing besides my lil pokes through connectors. Would be great to get support on this since we can’t deploy speckle to teams without this addressed.
Would you be able to tell us how to find that \\S00769FR01\user$\dmorgan....\AppData folder from C#? If that’s possible, we could add that logic in.
Alternatively we could provide a way to override the default location in wich Core looks for kits etc (maybe via a file placed somewhere on the machine).
Oh no, we used to use Environment.SpecialFolder.UserProfile but had to move away from it as it did not support some weird network account management set up (see this convo)…
I’ll chat with @AlanRynne when he’s back from BILT and see what solutions we can come up with…
ah I see how that works in that case. I tried that same pathing and it ends up pointing to the wrong location in our VD environment. I’ll pass this information to our IS peeps and see what they say.
I spoke with the IS peeps and they said we could create some exceptions for the installation process so the manager would be forced to install the files in specific location, which would resolve the issue with the manager installation. But we would still have an issue with accessing that data from the connectors.
We discussed this solution and it seems like a good approach. It would require companies to be aware of these variables but would relieve speckle from worrying about handling something specific to our environments.
I believe there is a pretty straightforward and standard solution for dealing with these kinds of “home” folder choices on Windows. Most apps use an Environment Variable to specify the path. This allows you to set a default (your installer can set it) but users can always override if they have special needs (like your user who needs to use the user profile folder instead of the more standard ApplicationData location).
In an enterprise environment, most IT teams will have deployment scripts they can use where these kinds of overrides can be easily configured through environment variables.
So, I guess my request for halp is will modifying the locations of local app data cause an explosion of some sort?
When installing the manager it splits up the files into two different location instead of the main 
the account data over to the folder we would want, but the manager no longer finds it.
The other issue is around connectors (I’ve only tested this with the rhino+gh connector). When using either grasshopper or rhino it can quickly locate my account information but it blocks any sort of operation node with the issue not being able to locate the kits and converters.
