I am trying create a central location on our network where our packages are located, but every time I path to it not all the packages show in my library in dynamo. I know this has been asked a few times, but none of the solutions worked. I have tried unblocking the .dll’s, checked the permissions settings for the folder, and deleted all of my old dynamo version folders.
The screen shots below shows on the left what it should look like (I pathed it to my roaming folder), the middle one is with the same packages but put on our network drive, and the one on the right is when it’s not pathed to any packages. So as you can see some packages are getting through when I have dynamo pathed to our network drive, but not all. Any help would be greatly appreciated.
This is definitely an issue with the dll’s since I only see packages missing that contain dll’s. Have you tried both packages downloaded via PM vs. internet browser?
I had the same problem in 1.3.1 (i always download the packages from https://dynamopackages.com/)
Everything worked well with 1.3.0, so not a dll problem on our side
For now we reverted back to 1.3.0
I tried using 1.3.0 and had the same problem. I think Andreas is right it probably is a .dll issue since the only packages that are not showing are the ones with .dll’s. Also under manage packages it shows all of the packages even the ones that are not showing in the library. See below for path settings and the directory’s that are being pathed too.
I’d suggest going about it the other way around : instead of pointing everyone’s Dynamo to a network location, look deploying the packages from a network location to everyone’s PC.
We do this at work using a logon script that simply robocopies from \\networkFolder\...\ to %appdata%\Dynamo\DynamoRevit\1.3\packages\ for example. This works a lot more reliably than pointing to network location.
You can set flags to overwrite the folders if they exist, so everyone is on same versions for the packages you’re rolling out. No DLL security problems this way, plus it still lets people install their own packages locally on top of the deployed ones #lowtech
Yes, there’s more network traffic but i’ll happily make that tradeoff for stability & predictability.
That’s what we are currently doing, I was just trying to see if we could simplify things and path the packages to the network, but it looks like something is making this to difficult to achieve. Maybe its the way our shared drives are set up or IT might be blocking them in someway, but I guess for now we will just stick with robocoping packages to peoples PC’s
I’m not in command to tell my IT staff to use Robocopy and do it this way. And many people may be in the same position
And i’m sure that if the software opens this way of getting to our packages, the software should allow us to do so.
I don’t know what is happening here but the network mapping way is what is recommended, it worked perfectly fine with 1.3.0
I’m sure this will be fixed, as many things have been fixed before.
I think it would still be good to open an issue about this on GitHub. Even if it does/can not get fixed, having the dev team look into this may at least result in better documentation on what to do/avoid when setting up package folders on network drives. I am happy to say that in the last two years we’ve only had two or three ocassions where packages could not be loaded from the network drive and both of them were fixed within the hour by IT, so I’m actually very happy withh this kind of setup.
