Dynamo Core 4.0 Release

,
1

4-0-cover
4-0-cover2053×890 486 KB

Hello friends of Dynamo! We’ve got some MAJOR news to share.. quite literally. Dynamo 4.0, our next major version release, is officially here! :tada:

This release while lighter on features has gotten a lot of love and effort from the team on many behind the scenes component upgrades and performance optimization to ensure Dynamo is future-ready and continues to get more performant. :sparkles: :flexed_biceps:

Here’s a quick look at what’s new:
:sparkles: Upgraded to .NET 10: For anyone still salty from the last .NET jump… good news! This one shouldn’t break your world.
:snake: PythonNet3 is now the default engine with a smoother experience if you’re migrating from CPython.
:gear: Geometry Performance Improvements for functions like unions, intersection and projection, with more speed-ups on the way.
:card_index_dividers: Improved collapsed groups for cleaner and simpler graphs.
:hammer_and_wrench: Plenty of bug fixes & quality-of-life improvements

We can’t wait for you to test out Dynamo 4.0 as your feedback means the world to us! :speech_balloon:

Learn more about the release in our blog: Dynamo Core 4.0 Release - Dynamo BIM. For full details, check out the release notes.

When you’re ready to explore, you can download the release here.

As always, we’re grateful for this community and the energy you bring to Dynamo every day which keeps us going. We love to hear from you all. :folded_hands: So, don’t forget to share your feedback in the comments below! :inbox_tray:

Previous few release blog posts:

Dynamo Core 3.6 Release - Dynamo BIM

Dynamo Core 3.5 Release - Dynamo BIM

Dynamo Core 3.4 Release - Dynamo BIM

12 Likes
3

Well done! :tada:
I had to meme this

image
image488×300 43.3 KB

3 Likes
4

Honestly this brings up a good point. IT should be working on rolling out .NET 10 to all devices with a goal of February 1st.

Also thanks for reminding me to post my annual reminder to the world that there now about 4 months until Revit 2023 reaches the end of it’s support cycle and that people need to start upgrading their models.

3 Likes
5

Is Dynamo 4.0 coming with revit 2027? Would be very nice.

6

I would hazard a good assumption that it would, as dynamo needs to be updated. Then the revit dynamo instance would follow the similar updates.

Coming revit dynamo specific updates can be followed in here - GitHub - DynamoDS/DynamoRevit: Dynamo Libraries for Revit

7

Make not purchasing decisions, but if my memory is correct the release of Dynamo that happens in or just before November is the version that most integrations use in the new product line.

8

Revit 2027 will target .Net 10 as Dynamo 4.x

9

How will the movement to .NET10 affect other applications such as Civil 3D, Vault, Navisworks?
Will we be forced to recompile all our code from .NET8 to .NET 10 to be able to upgrade to 2027 version?

1 Like
10

Civil 3D 2027 will target .NET 10 also (I assume, as I can’t reveal what happens in the beta traject).

I did not have a deeper look at it yet but I don’t expect any problems running .NET 8 targetted plugins in a .NET 10 environment. To be sure before runtime that all your functions will work, it is advised to rebuild your applications with .NET 10, but living on the edge is also a valued lifestyle :slight_smile:

More information: Breaking changes in .NET 10 | Microsoft Learn

2 Likes
11

if you’re built in .NET 8 I think you’ll be able to ‘get running’ fast, but you’ll need to update soon. For those who didn’t update to .NET 8 correctly or all the way, I’ve heard of several ‘gotchas’ already from people who managed to upgrade .NET 4 to .NET 8 without rebuild. Those ‘deprecation warning’ messages can’t be ignored forever.

1 Like
12

Make no purchasing decisions. I don’t know any more than you (or anyone else) does. However, we can make some assumptions around what we know about how Dynamo works:

  1. Any ‘in process’ integration of Dynamo 4.0 will need the host application to also be on .NET 10.
  2. Civil 3D, Advance Steel, and Revit all have that type of integration and therefore you can assume a change to .NET.
  3. Civil 3D and Advance Steel are built on top of AutoCAD, and the .NET version there has to align as well so you can assume AutoCAD updates too.
  4. LT versions of tools need the same .NET, so we now have a likely .NET version for the entire AutoCAD and Revit ecosystem.
  5. Any other tool released in 2026 that uses .NET 4.8.1 may or may not update. The host application eventually will need to update past .NET 4.8.1, but there isn’t a pressing need beyond the needs what the application itself requires. The next end of life .NET release is 4.6 which doesn’t retire for two years, and no subsequent build has a end of life date yet. So if the tool didn’t update in 2026 it might not update in 2027 either. I think this is limited to Navisworks, but I don’t have a full listing.

Forced? Not necessarily (@Anton_Huizinga had good feedback there). Recommended? Absolutely. You’re only going to be able to kick the can down the line for so long before it becomes compulsory, I don’t recommend lagging behind any further than you must.

1 Like
13

I have different builds of my Civil 3D and AutoCAD plugins anyway, for 2023 to 2026 (next year 2024 to 2027). It’s the same code but different .NET versions. So for the next version it will target .NET 10.

My Dynamo package is a different story. If the current version won’t run in 2027, then I will rebuild it targetting .NET 10 but prior versions I will not maintain any longer. Only Dynamo works different than AutoCAD regarding running external code, that was why in Civil 3D 2025.0 it was still possible to load .NET Framework based libraries, as long as there was no .NET API break. In Civil 3D 2025.1 it was not possible anymore to load old libraries, not because of .NET Framework but because of the many API changes in Dynamo itself. So I expect the current version will run without problems, but I’ll check this of course :slight_smile:

2 Likes
14

Relieved that we likely wont have to use Revit 2027 for at least 2 more years with the NET Framework/NC8/NC10 version hell add-ins will have to manage. Dust should settle by then…

Is there a clear recommendation (that isn’t use zero touch) from the Dynamo team as to how they suggest managing a Python-based custom package that can cleanly span Dynamo 4.0 and below without needing custom Python packages on at least one side of that fence?

I converted Crumple entirely to CPython3 not that long ago to escape IP2.7 and the ‘you need to install X package’ trudge it got to, and I’m thinking I might just have to not support Dynamo 4.0 in it for a while unless it’s an easy bridge to straddle. I’m likely to just switch to C# by then for Dynamo in my package anyway I’d say, but any tips or suggestions would be great.

15

Hi @GavinNicholls

I would recommend migrating (new package version, e.g., ‘Crumple3’ ?) so that it covers Dynamo3.x and Dynamo4+, with a migration to PythonNet3.

  • Dynamo3.x: PythonNet3 available as a package.
  • Dynamo4.x: PythonNet3 by default.

Even if you do not migrate to PythonNet3, starting with Dynamo4.x, PythonNet3 engine will execute old CPython3 nodes.

16

  1. Set up a good testing framework and run the tests every time you update the environment (install an add-in, add a Dynamo package, update your own add-in or package, update Revit, install a new version, etc.). With the amount of development you do (in Dynamo and elsewhere) I think you should have a way to test any given tool in a selected environment in under 20 clicks now. Journal playback helps a LOT here. Sadly this is something that the larger community hasn’t surfaced via the usual workshops and such. Maybe I’ll submit something to DevCon or the like… For you I imagine the tests would be something like:

    • Launch testing environment (two clicks)
    • Select version to test (2 clicks for a dropdown)
    • Select test type to run (2 clicks for a dropdown)
    • Select the specific files to test on (likely a few clicks here to find a working directly)
    • Hit ‘go’ (one click)
    • Review the output (many clicks)

  2. If I were maintaining a public package I would draw a ‘line in the sand’ around new features. This means anything ‘new’ is in the version I’m building for today; nothing looks backwards. So if you’re in Dynamo 1.3 you’re going to have to use the package from 2017, if you’re in Dynamo 2.4 you’ll need to use the one from 2022, 3.6 you can use the one released today, etc.. Users are welcome to try to use older builds but they’ll have to work around the bugs. The other Option or I would do what @Anton_Huizinga did with his Civil 3D package and make new package at each major breaking change for the package. This breaks vanity metrics like “number of downloads”, but who cares about that bit anyway. Both cases solve the ‘my package needs to work across both builds’ issue which is the root cause.

  3. I’m expecting that the number of changes for the CPython to PythonNet engine will be FAR LESS than what they were from IronPython2 to CPython3. That means you won’t have as many scripts to update. I might be a bit naive on that front though, I won’t know until I get a version of 2027 to really kick the tires on, which will likely happen for you before it does for me.

  4. None of the above solves users trying ot leverage the same package version across multiple builds. To solve that you could write an extension to automatically alter the engine for all Python nodes in your package when your package sees a version mismatch.

Yeah, all of these are extra work, and it is far from easy. Building a thing is simple. Building a thing that scales is hard. Maintaining a thing that scales over years of use is hardest. You and a few others are at that stage.

17

@jacob.small has already covered a lot of the details, but just to add on here. The Dynamo team’s stance on the whole Python-version and dependency-matrix chaos is that moving forward we want to keep it clean and simple. We want to move toward having one Python engine in Dynamo going forward. That’s why we’re recommending an update to PythonNet3. We’ve put a lot of effort into bridging the old gaps, and we’re confident PythonNet3 now covers well over 90% of the scenarios we’ve seen in the wild. So

As @c.poupin mentioned, PythonNet3 is already available as a package in Revit 2025 and 2026 (Dynamo 3.3–3.x), and it will be the default engine for future versions of both Revit and Dynamo 4.x. Only thing is that users in Revit 2024 will have to rely on CPython or IronPython2 (worse case if there are gaps in CPython), until they move to Revit 2025.

To help smooth things out for users and avoid dependency warnings, we’ve also added automatic migration from CPython to PythonNet3 in Dynamo 4.0. So if someone uses a custom node, like a Crumple node, for example, that was built on CPython, it will automatically migrate to PythonNet3. There’s more info about this in the blog post. From what we’ve seen so far, the number of cases where migration from CPython to PythonNet3 causes issues is very small.

All of this should also make it a lot easier for authors like you to update your packages moving forward. If you hit any bumps while updating or notice anything odd, please do holler us. Looking to find all those edges cases and fix the gaps in PythonNet3.

2 Likes