Hello everyone, I created a bunches of codes for the office, it runs well on my VPC. But it wont run on other people VPC due to the reason of missing package or dynamo versions (when runs with player) etc… is there a way to make Dynamo recognize a shared package folders? or a way to have every computers has the same packages automatically?
If it is for packages, you can install them to your server and point everyone’s Dynamo installation to that directory:
1 Like
I dont know why it kicks me out each time i tried to add a new path. :-/ But yeah if Dynamo adds the nodes from package from path, it is what i am looking for. Thanks
1 Like
We developed a tool for that (sorry for the shameless plug)
www.orkestra.online
6 Likes
Hey,
There was a podcast the other day on this…
Pointing every user to a shared server location is useful, unfortunately it is then a lot slower. An alternative option demonstrated in the video is to sync everyone’s packages on their local machine.
This won’t solve everything though, because different users on different Revit versions have different Dynamo versions which different packages are built against… So Orkestra (which is nothing to do with me, but I am happy to plug!) is a very sophisticated yet user friendly solution for these problems.
Hopefully that is of interest.
Mark
Edit: I just saw a post about using Dyna-hub to sync DYNs to github, which is an interesting idea for office-wide solutions.
2 Likes
We first tried to use a server location, which made dynamo unbelievably slow.
We then made a powershell script that pushes new packages from this server location to the users local harddrive when i update the server location.
This works fine for our office since i am the only one making scripts, coworkers only use them. I can imagine this not being a great solution if you have lots of coworkers who develop themselves.
4 Likes
MVE1112
Just seeing this thread because I am working through ways to implement packages company wide. We are not a big company and I’m the only one making scripts. What is the process to setup a powershell script? It sounds like that might work for us.
Thanks
Hi kslifter,
It doesnt have to be Powershell, it’s just our IT Guy’s prefered way to approach this.
It’s basically just a script that launches on start up for users, so when they start their computer, a script simply copies and pastes (overwrites) the designated Dynamo folders that another script of mine has created on all computers:
All users have this folder and the users have to manually add this as a path in Dynamo.
Whenever i change something with packages, i add it to a network disk, which in turn ‘notifies’ the script that something has been changed about the packages and a log on script is needed.
This will only work properly if not everyone is creating scripts, or the packages are very well monitored. In our case, i am the only one creating scripts and the other users only use Dynamo player.
Hope this helps, feel free to ask more!
Letting the IT team handle this is the best way to ensure things work consistently, and deploy well. If you don’t do all software deployment and network administration efforts for the company, you should loop them in on the conversation.
1 Like
Yeah definetly!
I’m on average discussing Dynamo and the implementation around the office like every two weeks with my IT team. I would not recommend doing this without the IT guys either setting up deployment for you or helping you with figuring out how to set it up.
If you have multiple computers in an office, theres a decent chance there are already existing logon scripts that update new revit versions (except for the revit 2021+ which doesnt allow automatic installments for some reason). They will easily be able to add something that just overwrites a folder on users during start up.
We are a small firm of about a dozen designers and I sit next to the main guy who handles the IT work and I’m discussing stuff with him regularly.
After talking with him about it this morning he suggested the following process first. Almost, if not all, of our files are through Google (which honestly kind of annoys me because I don’t have access to Excel) so he suggested that we have the download location be on our Google Server and then set the folder to be available offline. All users would have access to this folder on their computer since it would sync an actual copy of it on their desktop.
Thoughts on that? I know previously in the forum is suggests staying away from a central folder that everyone accesses.
1 Like
I like and agree with the idea of using something like google drive.
I would add that I would not want to map everyone to the folder though. Instead, I would have some sort of startup script that would sync from that Google folder to the AppData folder that is default with Dynamo.
This would then work between Revit upgrades and you never have to mess with the folder. Instead, you would just update the startup script that you are using.
(Script can be powershell, robocopy or even Dynamo)
1 Like
That thought workflow occurred to me as well. I did Google copying folders and and came across the ‘Copy-item’ command.
I’m assuming the the ‘Copy-item’ command is what I’m to use to connect the two folders?
Is there a sync command through Powershell?
When writing the script I’m guessing I just need to enter the pathway to each of the users computers by replacing the user name in the pathway?
Once I make the script in Powershell I would just have each person add that to the startup list on each persons computer?
Sorry for all the questions. I’ve never been the IT guy, but as I get deeper into Dynamo, then Python, and now Powershell I’m learning as I go. It’s been a lot fun, but also a lot to take in and learn.
We tried a network folder that routes people to the same folder, which was incredibly slow for some reason. Made even small scripts a pain.
I think the easiest way is just robocopying a folder from somewhere to a users C drive on startup.
If you’re new to this, even a batch file could do, where users just run the batch file whenever you send out an email that tells them to run the batch file. ’ Hey guys i updated some packages, please run Package.bat that’s on your desktop before launching Revit’ or something. @kslifter
From the Dynamo known issues:
This issue alone is enough reason for me to never recommend mapping to a network drive.
When sending out a batch file, how do you get the ‘user’ portion of the file path filled in correctly for each user? I’m assuming there is an easy way and not that you have a separate file saved for each user that you would send out.
I made a powershell script to copy over folder contents and I googled how to make it work as a batch file. I’m just not sure about the user portion of the file path that is default by Dynamo.
You can typically do this with environment path variables like %APPDATA% which are essentially shortcuts to specific directories. For example, you could dynamically path to the Dynamo Revit packages folder for 2.13 by using %APPDATA%\Dynamo\Dynamo Revit\2.13\packages.
1 Like
Thanks, I’ll give this a try.
Ask him if he is ok with running dlls (many packages are entirely this) on local systems which were synced via a cloud folder. I personally wouldn’t be, but maybe he is. Coping them to the local drives at sign in allows a greater degree of security as they can monitor and sign off, while preventing write out. Then again, I may be a bit too conservative at this point having been through one too many security trainings of late… 
My plan right now is this:
-I have setup a scheduled task to mirror a Google folder with my package folder.
-Then as I add packages to the folder I will send out a batch file (using %app) to the others in the office to update their package folder by mirroring the Google folder.
I spent more time than I probably should have yesterday trying to figure mirroring with powershell and/or robocopy, then trying to figure out a workflow with my dynamo and the package locations, etc.
This seems pretty straightforward, I was just struggling with getting the info to the users app folder since each file path is different.
2 Likes