Dynamo Package Deployment (2024)

I have searched other forums for some information, but their solutions did not seem to work for me.
I am looking to deploy Dynamo scripts to my office for the first time. I have a couple graphs that use a few different packages that need to be deployed as well. I have tried the moethod of just copying the package folders from a central location on our servers to the local machine and when I go to run a graph, it says some of the packages are not installed. Steam Nodes (1.2.3) works with just a copy of the package folder, but Rhythm (2024.10.1), Data-Shapes (2024.2.114), and IronPython 2.7 (2.4.0) all say the package is not installed and I have to manually install these packages.

Is there a way for a simplified aproach to package deployment so users do not have to open Dynamo (read: scary) and install the required packages? Is there perhaps a command line solution or Dynamo graph solution? Or a way to compile the graph into some other runtime tool?

Copying from the server should work - double check that they are there. All the packages you mentioned have a DLL component, which means that some extra infosec issues might come into play (you wouldn’t want someone to be able to put code on your server, automatically push that code to each end point, and then execute it without a user taking action, would you?). Check stuff like the mark of the web having been cleared/added (note that many servers are actually treated as web links thanks to cloud mirroring and such).

I wrote a DYN file to copy the package directories from our server to the user’s AppData folder and used a BAT file with command line command to execute it outside of Revit. Is there something else I should be doing or checking?

This is the link I used: How to Deploy Dynamo Packages Easily - Dynamo BIM

So the end users are running that .bat?

Talk to your IT team as .bat execution frequently requires admin rights. If your company has strict infosec policies which impact installation and deployment you might not be getting the content copied over.

Yes, end users would run the bat file. But, it ran fine on my machine and I do not have admin rights. Maybe I should try manually copying the files from the network location to my local machine and see if that helps? Otherwise, what would the infosec policy be filtering out?

My IT guy has set up a logon script that robocopies the package folder for each Dynamo version to the default package folder in Appdata for all users.

This way new packages that need to be added, always have to be placed on the shared folder, users always have the latest version and users dont have to change package paths.
The dyn files remain on a shared location

1 Like

Every user profile is different - best to have a typical user run it not yourself, then check to see what they have for results. Sure the .dyn doesn’t run, but are the files where they should be? Are they unblocked?

Having ‘not you’ test this is key, as you already have stuff around and have configured parts of your environment.

Your IT team members should be able to do this readily, as they’re best positioned to do so as only they know what limits your users have, and how to ensure they ALWAYS get the content (not just when the decide to run a .bat).

So I spoke with one of our IT guys and he said that there is likely an infosec policy blocking a bat file from copying the package files from the network location to the user’s AppData folder. However, even when I run this bat file on my machine, I cannot get Dynamo to recognize all the packages. What is even more confusing is that all the files appear to have copied properly (same list of files, same size, everything). So I don’t know how to tell what isn’t being copied…

I got something to work. I installed the packages fresh from Dynamo, copied them out to my local drive (Documents folder), deleted them from the AppData directory, restarted, then copied them back into the AppData directory from my documents folder and everyting came in correctly. I will reach out to our off-site IT team to see how we can make this work from the network.

maybe:
Macros from the internet are blocked by default in Office - Microsoft 365 Apps | Microsoft Learn

your network location could be untrusted I guess, how are you copying the files?

If theyre any good, see if they can set up a policy on startup so that they copy the files if not found, and before users have a chance to jump into Revit (very short window of time, in my experience).

A user group policy and some basic IT work can achieve this fairly easily.

If they can’t, tell them to look up at the meteor coming their way.

It appears that there is a security issue on our server side. If/when IT resolves it, I will post the best update I can explaining what they had to do so others can hopefully guide their IT teams in the right direction.

This is the error message I received when trying to download/install a package right from Dynamo to our server location:

This is an issue with security in business, personal need to go to the directory contains assembly to choose unblock all assembly downloaded one by one,

I’m not sure Dynamo team can give update with a small trick from core is download a zip file and unzip in folder, that will bypass the issue.

I know this will eventually break, we map the package folder to a network location. There are only a few packages currently, other packages I often use I copy with a Dynamo script to my local computer.

This is not a recommended way but it seems to work for the time being, we have very few Dynamo users. I expect it to go wrong at some point, when it does I will have IT setup something to copy the packages.

In my experience, mapping to a network location makes dynamo extremely slow.

We had IT set up a logon script that copies the packages from the network location to the package folder in the appdata directory.

3 Likes

I occasionally experience some slowdown but I have then when Ive copied all the packages to a local folder so I don know if its that. Were also working in a virtual environment, our virtual machines and the packages are on the same server.

Setting up a script is the long term intention, for now in testing it seems ok but I will try and figure out if the slowdown is Dynamo or related to the network locate packages