@solamour @john_pierson @Michael_Kirschner2 @jacob.small
I have opened up a Visual studio project and it would seem the latest 3.6.2 and 3.7.0 versions of DynamoVisualProgramming.Core nuget package has been changed to .net 10. Therefore this is now giving Framework compatibility errors, I assume this was done accidentally and could someone look into this?
I can work around this temporarily by targeting the 3.6.1.X package, instead of 3.X but thought I would highlight as others may start to see similar issues.
Thanks in advanced
Visual studio Error:
3.6.1 Info(last .net8 version):
3.6.2 Info:
3.7.0 Info:
Nope. Intentional. Make no purchasing decisions based on what I am typing here including investments or software purchases. I will start with a few statements of fact, speaking not as a representative of my employer but as a member of the community (I am currently on my lunch break so Iâm not getting paid for this).
- If you look at the lifecycle policy .NET 8 has an end of life date of November 10th 2026. This means any program using .NET 8 will have to update to .NET 10 in order to be kept secure.
- Autodesk takes security seriously, and as such takes action to keep everyone as safe as they can. This includes hotfixes, updates, security advisories, and migrating off underlaying referenced components and toolsets which are no longer secure.
- Autodesk also cares about users getting stuff done, so they like to give as much ârunwayâ as practical and possible within the bounds of federal trade regulations. Often they canât âscream it from the mountain topâ due to such regulations limiting what can be said about future product statements. This means that sometimes products are released earlier than they need to be, or that beta builds and referenced components trigger curiosities in advance of real change. The goal is to have everything in place to help facilitate movement though the change in advance of the date a company would be unsafe.
- Looking at the Autodesk product portfolio for applications built on .NET 8 youâll see offerings like Revit 2025, Revit 2026, Civil 3D 2025, Civil 3D 2026, and a whole bunch more that I wonât bother listing here.
So if we accept that #1 is time bound (~8 months now), #2 is actively spoken about and marketed, and that #3 is historically true, one could assume that items in #4 will need to be addressed in some way, and that people âinside the factoryâ are considering how to best help those impacted before the issues become major blockers in production environments. Your finding reinforces this assumption as valid since Dynamo is one of those âcomponentsâ which the other tools consume.
So again, make no purchasing decisions, but it would appear form all the tea leaves in the larger industry that this isnât a mistake but intentional. (I am now heading back to my regularly scheduled sandwich).
My general recommendation is to target 3.0 unless you need a feature which was added in a newer build. This ensures your tool gets a bit more âbackwards compatibilityâ by limiting you to tools âinside the coreâ instead of possibly getting something which works in 2025.1 but not 2025.2 as you leveraged one of the new mesh tools.
This is all fine, but I thought dynamo version/framework was done with Semantic Versioning V2 being used. Where major breaking updates would be major builds(eg 1.X, 2.X, 3.X, 4.X, 5.X) which the changing of .net version would/could cause breaking updates?
Therefore i would have thought Dynamo versioning and .net was built as follows:
Dynamo 3.X is built of .net 8 - Hosted onto Autodesk 2025 and 2026 software that is built of .net8
Dynamo 4.X is built of .net 10 - Assumed this will be hosted onto Autodesk 2027 software that is built of .net10(.net 10 taken from revit public roadmap).
This is true. HoweverâŚ
Dynamo has to be picked up by other tools. And other core components of Dynamo 4.x arenât necessarily viable in older versions of other tools. So moving to a new build of 4 would require âdowngradingâ content that took awhile to put into 4.0. And doing so would produce a mess which would persist until everyone moved to Dynamo 5.0. Those errors would surface as things like âmesh.translate works in Dynamo 4.0 and Dynamo 4.2+, but not Dynamo 4.1â. Effectively 4.1 becomes a TON of additional work for someone with no real value to the community.
In a perfect world (meaning Dynamo is the center of it all) a version 4.0 would be pushed to all .NET10 builds. But doing so is a VERY big lift for those host applications who arenât currently capable of jumping all their components into that build. Also the host applications making those changes would add additional breaking changes onto the non-Dynamo ecosystem users (add-ins are a thing in both the Revit and Civil 3D ecosystem). As such a ânewâ build of 3.x which uses .NET 10 is a logical compromise, as it helps pick up some bugs and new features for the âupgraded to .NET 10â tools, and minimizes the impact on *pointing broadly at the world* all the rest of that stuff out there.
1 Like
Hey @Brendan_Cassidy - good catch, and thanks for calling it out.
Also worth noting: this is a pretty recent change and only part of Dynamo daily builds, so you caught it early before more folks ran into the same framework mismatch.
This change was intentional. The DynamoVisualProgramming.Core NuGet packages in the recent 3.x line are now built for .NET 10 so they align with where .NET changes are heading. That does mean you will see the framework compatibility errors if your package is still targeting .NET 8.
For a package that is in use right now with released versions of Dynamo in host products, the guidance is:
- Pin to the last .NET 8 compatible package (for example
3.6.1.x).
- Or, as @jacob.small mentioned, target
3.0 unless you specifically need APIs added later.
On the semantic versioning point: normally a framework change feels like a major bump, but Dynamo has to stay consumable by multiple host applications in different states of transition. The approach here is a compromise that lets the ecosystem move forward without forcing every host to take the full Dynamo 4.x stack at the same time.
We are still finalizing this change, so we will have a better update in the near future. But for the 3.6.2 Nuget, the plan would be that that one would be superseded by 3.7.0 to indicate a bigger change (.NET 8 â .NET10)
Also: this is a good callout for us to document more explicitly. We should add a short section to the Developer Primer covering which Dynamo NuGet versions target which .NET runtimes (and what that means for add-in / Zero Touch authors). Iâll aim to get that captured here: Developer Primer | Dynamo
Thanks for your patience with these changes and thank you for bringing them to the attention of the broader community.
-John
Side Note: as a package author, this .NET compatibility on top of everything else really is intimidating to me as well, but we are working to make it as frictionless as possible.
4 Likes
@jacob.small @john_pierson ,
Thank you both for this update, and good to hear about the changes to come, yeah be good to see it documented somewhere for others. I did look at the release notes and could not see anything on there. So maybe a quick note added on there for these builds even if it says further release notes to be released once version actually released?
But after Jacobâs note i did a further digging at the âpull requestâ and found it hidden in there.
I have updated my versioning within visual studio project to mitigate it grabbing the later version that is built on .net10
For anyone elseâs reference this is where i added it
2 Likes
