How to make sure a Dynamo Graph can run in different version of Revit?

Revit
1

Hello,

I am trying to make sure that the all my scripts will work in different version of Revit. It feels like some older version dynamo will not run higher version package or vis versa? Or did I setup something wrong? The solution I am currently doing is to build separate dynamo scripts for different Revit version, which feel very troublesome. Is there a better way to manage all the scripts and make sure they will work in all Revit version?

2

Not really - as Python, Dynamo, Revit, .NET and even Windows updates over time you need to build to that environment.

You can make it easier on yourself though. First set up your environments for each release you plan on supporting. Graphs don’t support ‘one package version’ across all environments in general, but you need the ‘right package version’ for your environment. That is a different Revit build will require a different Archi-Lab version, so set those up first.

Next develop to the oldest environment you want to support, test that, then do a save as to the deployment folder for users in that environment. Then copy the deployed version to a new folder and text the next environment. When it works save it to the deployment folder, and continue to repeat the process until all builds are done and move onto the next graph you want to develop.

Then every time you get a ‘new environment’ (i.e. a new Revit version is released) you copy the most similar environment to the new build’s testing directory, and do the test/deploy.

All of this testing can be difficult, but it is the only way to validate things. You can certainly speed some stuff up using playable journals. Towards that end I have a collection of Dynamo graphs to put properties into your graphs and build playable journals posted here which can help in the larger development process.

3

re-write the graph in python.

4

This also requires building a different version of Python for each Revit and Dynamo release as the APIs for both change annually (or more often).

To scale you have to either consume the right content for each environment, or re-do the work for each environment you want to support.

5

Thank you all for the replies. That proofs I am not alone!

1 Like
6

I shared a lot of things to lookout for here:

Funny enough, I work from the latest version I support backward. Testing in the same manner @jacob.small mentioned.

1 Like
7

Curious - do you have a reason for ‘back’ instead of ‘forward’? I always default to ‘forward’ as that’s the annual upgrade practice anyway. For new stuff I typically have a ‘minimum’ from the customer (or I go to the oldest supported build or the oldest version which things work in).

So at the moment stuff I am building to try out Dynamo for Forma I build in 2.18 as it is the ‘first’ version with supported access, then upgrade to 2.19, 3.0, 3.1 and 3.2.

8

Node sizes primarily. But I also don’t duplicate graphs for each version. I use DYNs for 2.18-3.0.x consistently.

I just steer away from new OOTB nodes and certain packages.

1 Like
9

2.18 to 3.0 isn’t as bad as 2021 to 2022 and 2023 to 2024 jumps. The 2022 to 2023 is t too bad less the node size issue. 2024 yo 2025 mostly works without change less a few exceptions around dependencies that don’t play nice together yet…

I get the node size thing entirely though - I find upsizing isn’t as bad as downsizing with automated prep and Monocle though. The EOL for 2022 will be my happiest ‘throw that release into the abyss’ since 2019 which saw the end of individual Dynamo installation’s to deal with.

10

also to piggyback off

If something is very mission-critical, I do have to admit that I would not make that a Dynamo graph and would end up just doing a Revit plugin.

Example: Parallax Team has a suite of “Template Tools” that used to be curated Dynamo graphs. Those are plugins now because we grew tired of finding all of the issues I demonstrated in that AU talk.

1 Like