Upgrading nodes to latest package

This question has been asked before but without a resolution, but is there a way to bulk upgrade nodes on a canvas with the latest version?

The graph has been devloped over several years and has a mix of nodes from different versions of the same package. Using the workspace reference functionality doesn’t resolve the issue - it just installs a different package version but Dynamo remembers which version the nodes on the canvas came from.

Would require editing the workspace references of the dyn. Likelyworth reviewing in the context of ‘I have run this with the new version and can confirm it works’.

Would you want this for the active file, or for the full library of files?

@jacob.small just the active file is fine.

Do you mean editing the *dyn file in a text editor? Is it as simple as copying the unique ID from one node library dependency into the other? Would this cause any instability? What are the ‘Dependencies’ (above nodel library dependencies)?

Otherwise what would be the alternative - using something like Monacle to find all the custom nodes and then manually subsitute out?

BTW, it would be really useful to have some sort of utility tool (kind of like etransmit) which clears out bindings without the need to edit the dyn file in a text editor.

1 Like

RE the binding request, there is an idea in the git I made for it - agree:

That is what I meant. Though I haven’t played with this part of the file to confirm how it would work or what instability might come from it. So the question remains, is this for the active graph, or a background file? If it’s the active graph we may have an issue. If it’s background stuff (ie updating the entire library) you could be good. My first edit would be to the package info, not moving stuff between packages though. Something like changing Clockwork 2.0 to Mechanical apparatus 2.0.

My gut says that the first list of GUIDS is where the dependencies are set though, so you’d really just want to reset those to the right version.

I believe Monocle has this already, and while you’d want to close the graph first, but the bulk upgraded tools I built and have shared here a few times will do this and a bit more. Like etransmit you’d want to not be in the file first though.

Does your If Replacer tool work with 3rd party packages or just the OOTB nodes?

I’m not sure about the Dependencies. Only 4 packages are used but 7 dependencies are shown.

You could make it work with the 3rd party nodes; just need to identify the relevant info about each and build a lookup dictionary.

I actually just added a tool to monocle (node swapper) to help with this because the Generative Design Nodes do the same thing and do not auto-resolve on upgrade.



@john_pierson does this work on 3rd party nodes?

So far I’ve had success with zero touch, code blocks and traditional custom nodes (dyf).

It is a really new feature, so let me know if there are any that act odd.

I feel curious but i don’t understand what is this and the relationship with the original question of the post

Node swapper helps you switch out nodes that might be showing “unresolved” warnings.

A great example of this is generative design. Those nodes show the same warning Paul has in his screenshot and I made the tool to solve that exact issue.

1 Like

So I’ve had some success with this.

“Dependencies” in the dyn file are actually custom nodes - even from 3rd party packages (why?)
“NodeLibraryDependencies” in the dyn file are zero touch nodes from 3rd party packages

But it turns out you don’t need to edit the dyn file in a text editor. The workspace reference “keep installed version” does appear to remove references to the older package.

1 Like