Dynamo is upgrading it’s underlying framework, .NET, from the 4.8 version we’ve been on for a very long time to .NET version 6 in parallel with our host applications such as Revit and Civil 3D. This is kind of important as if we don’t… Dynamo won’t work anymore in those hosts
What does this mean for you? For package authors? Package consumers? General Dynamo users? Come take a read of our “FYI” blog post here, with a technical one to follow soon.
Edit: If Revit and Civil 3D decide to upgrade to .NET 7/8, we will be following suit. We will continue to keep open, early and transparent communication around it
Edit: We have a new Blog Post out technically detailing the affect on Packages here: Dynamo 3.0 moving to .NET 8
Will there be parameters added to the json file where we can force loading older packages in Dynamo 2.17 and newer packages in 2.xx? To avoid the need for a duplicate package.
A request here:
Please just keep up with what your users/developers are doing.
When i’m half way there upgrading the lot the next move you guys make makes you wanna start all over again
Maybe you guys underestimate the time involved
Or maybe i’m the only one here
i’m getting old too
I think of it this way
What can i do with this program, and make a mind map globally
Then get creative on what lies in front of me (the problem/challenge)
When the mind map changes, i feel i have to start over
Moving on from .NET Framework is a time to rejoice for developers. This move is absolutely a positive step towards keeping up with the times. And from what I can tell, this change seems ultimately driven by what the host applications are doing. Dynamo either upgrades to .NET 6, or you don’t get to use it in Revit, Civil 3D, etc. anymore. Simple as that.
I know,
I wish those updates would be more of an all in change
all in one go
but i’m a Revit user with projects being in R2022
that’s what the client wants
You are right, and .NET 6 is a future safe step, but I felt a (little unpleasant) surprise to read between the lines that I can stop all my current development on AutoCAD and Civil 3D plugins, and probably have to spend all the budget for the upcoming year to be ready next April. It is not just a little switch, everything must be tested and rebuilt at worst (obscure libraries, our license mechanism, the obfuscator system and so on). Also making a plan to maintain older versions and newer versions, which might result in duplicate code.
The Feedback forums and readme documents of AutoCAD Alpha do not mention this (yet), so I am a bit surprised.
Well, anyway, we will have to go along with the future
The biggest disruptor will be any package using API’s in .NET that have changed. So it depends mostly on that for additional work beyond a recompilation targeting the newer .NET. framework. Your packages, depending on complexity, may not even need to be recompiled.
#sadness are you talking mostly about the node size @john_pierson ? Or the If node, Python engine etc.?
Hi @Marcel_Rijsmus - I hear you, and these kind of large disruptions are tricky to navigate across the board. This will necessitate a Dynamo 3.0 release given the large nature of changes. In this particular scenario, if we don't do it, we won't have Dynamo working at all as the target framework for our hosts, Revit, Civil 3D etc. are making this move. The timeline on the .NET upgrade wasn’t our choice as it’s a pan-Autodesk change. The longer Autodesk waited across the board, the more things that would break.
There is no plan to be able to load .NET 4.8 packages if they are identified to have issues. If they have no identified issues, it should work without creating a new version. We will have more info in the technical blog post, which should contain information for package authors on testing.
Please do reach out to your AutoCAD / Civil 3D contacts on how to proceed in those applications @Anton_Huizinga I’m not in the loop with what changes are happening there beyond the fact that they are upgrading to .NET 6.
Dynamo packages may not need to even be recompiled, depending on complexity.
I am really happy you provided this information, can’t talk about AutoCAD 2025 here due to agreements. At least it is for sure that this information has not yet been made public anywhere. I don’t blame the messenger here, of course
I mean, in the Plugin Loader mechanism of AutoCAD we can load specific dlls in AutoCAD from and to version. The Package JSON of Dynamo has not such a thing. So, if I need to rebuild my Dynamo package, I can’t publish it with the same name because prior Dynamo versions can’t run it. So I need to publish a new package (and maintain two packages) to be sure older and newer Dynamo versions can run my package.
Or, the JSON file could get new parameters so I can load an older package in prior Dynamo versions and a newer package in the upcoming Dynamo version
Let’s say you were working on a design project which was set to run forever. Over time you have to do some degree of updates as what you are building with changes - ie: the availability of a particular carpet/telephone pole/whatever could change due to manufacturer constraints.
Over any given year these changes are inevitable, and need not necessarily be done right away but can be done over time with some pain along the way.
As a result you have a choice to make as the project manager. Do you make the changes over time, or do you put them off until the last moment and do them all at once?
In the context of Dynamo for Revit, imagine if in the community had to update to .net 6 framework, the units changes, the forge data type changes, the 64 bit element ID changes, the visual refresh changes, the geometry library changes, Python engine changes, and the like. The way we progressed allowed for each of us to take baby steps and learn how to implement the individual pieces into our work over a span of six months to a year for each. Now imagine if we had to do them all at once, all at the same time? Even knowing that many are struggling to keep up (I count myself among that number), I feel like the process would be significantly worse across the board.
Now we could argue that the sequence of changes would have been better in a different order, however as Sol noted much of this is dictated by other parts of the ecosystem (ASM, APS/Forge, Revit, etc.).
Thankfully the development teams are all doing what they can to give us as much heads up as possible. Using that time effectively will certainly help. Accessing beta and trying out the build on old graphs is certainly on my todo list.
as the target framework for our hosts, Revit, Civil 3D etc. are making this move. The timeline on the .NET upgrade wasn’t our choice as it’s a pan-Autodesk change. The longer Autodesk waited across the board, the more things that would break.
I’m not in the loop with what changes are happening there beyond the fact that they are upgrading to .NET 6.
But yes, I hear you. Unsure on that front as I’m not looped in with that level of discussion on the Revit side.