Dynamo upgrading to .NET 6

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 :frowning:

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 :blush:

Edit: We have a new Blog Post out technically detailing the affect on Packages here: Dynamo 3.0 moving to .NET 8


This is the case with the 2025 versions?

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.

1 Like

As a zero-touch package author who has not really touched .NET 6.



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


You are not the only one. The Dynamo “UI Refresh” really messed up a lot on our end at Parallax for shipping .dyns to customers.

Dynamo went from being incredibly backward compatible to, “Please make the graph over again in every version of Revit” very quickly.

Thankfully that is only the most extreme cases because generally, our graphs work from 2024 to 2021.


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

1 Like

Thanks for the advanced heads-up, @solamour!

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 :face_with_diagonal_mouth:

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 :frowning: 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 :cry: 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.

1 Like

Fair point. But on the flip side, I think we’d all prefer to know with as much advanced warning as possible, so we can give Sol kudos for that :slight_smile:

1 Like

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 :pray: 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.

the next move will upgrading to full 64-bit i hope (for Revit) :slight_smile:

Element ID’s are 64-bit now! :sweat_smile: But yes, I hear you. Unsure on that front as I’m not looped in with that level of discussion on the Revit side.

1 Like

We’ll ask ChatGPT7 to reprogram the lot in due time :slight_smile:


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 :slight_smile:

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 :slight_smile:


I’ll also weigh in on this…

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.


What’s up in the foreseeable future?
I didn’t see this one coming
maybe i didn’t look tho