Revit 2025/2026 migration to .NET 10 — compatibility and deployment concerns

[Archigrafix_Norge]

Reference: https://aps.autodesk.com/blog/call-preview-testing-revit-20262025-migration-net-10

Autodesk explains that the reason for moving Revit 2025 and 2026 from .NET 8 to .NET 10 is to follow Microsoft’s LTS support lifecycle, since .NET 8 support ends in November 2026 and .NET 10 is the next LTS release.

We understand the motivation, but the blog does not appear to address the deployment and compatibility risks for production add-ins.

We already have evidence that some add-ins may stop working under .NET 10. In some cases this is due to third-party dependencies that support .NET 8 but do not yet support .NET 10. In other cases, code may fail directly because a runtime change is not just a transparent “same binary, newer runtime” update. Add-ins may depend on assembly loading behavior, reflection behavior, serialization behavior, native interop, transitive NuGet dependencies, or runtime-specific behavior that was tested and validated only under .NET 8.

The concern is not only whether the add-in can be recompiled. The concern is that Revit 2025 and 2026 are already released and used in active production projects. Changing the .NET runtime mid-lifecycle can break installed add-ins during ongoing work if customers update Revit before the correct add-in build is available or installed.

Autodesk’s blog asks developers to test and report problems, but we need engineering guidance on the supported deployment model:

1. How can an add-in detect whether the running Revit 2025/2026 build is using .NET 8 or .NET 10?
2. How should publishers package separate .NET 8 and .NET 10 builds for the same Revit version?
3. Does Revit support selecting one DLL or another at load time based on the host runtime?
4. How will Autodesk App Store distinguish between Revit 2025/2026 add-ins built for .NET 8 versus .NET 10?
5. How should add-in updates be synchronized with customer Revit updates?
6. Will Autodesk provide a compatibility matrix showing exactly which Revit 2025/2026 builds use .NET 8 and which use .NET 10?
7. What safeguards will prevent customers from installing or running an add-in build that targets the wrong runtime?

This appears different from the Revit 2025 move to .NET 8, which happened at a major Revit version boundary. This proposed .NET 10 migration affects already-released Revit versions mid-lifecycle, so the operational risk is higher.

We need a clear answer from Autodesk engineering on runtime detection, packaging, App Store versioning, side-by-side DLL support, and customer-safe update sequencing before this change is rolled out broadly.

[ricaun]

I saw that in Autodesk Revit Feedback : Revit 2026.5 Beta is .NET 10 

Great post @Archigrafix_Norge you nail in the questions and concerns.

Changing Revit 2025/2026 to .NET 10 definitely feel like a bad idea, Autodesk gonna do it anyway 🥲

[Sean_Page]

But do we really want R26 to have 2-3 years of life after .NET 8 is now longer supported at the end of this year? We got spoiled a little bit with 4.8, but these newer runtimes have a lot more features, stability, and efficiency with them. Really, isn't this just the price of progress?

[ctm_mka]

@Sean_Page I would say yes, its a bit of an issue with active projects having to wait for third party vendors to update before we can use them, thus disrupting people workflows, possibly causing delays. But then we also have the option to not update to this.

[lukasz_michalskiNCGR7]

I guess installers could try to read installed Revit version and decide which files shall be installed. But if users Revit migration will happen after plugin installation then plugin reinstal may be necessary. Users shall be informed about it in some way.

[roman_karpovich]

I like it. Modern, actual dependencies are always great. Performance, new features, compatibility with a new frameworks, libraries. Ideally, all supported versions of Revit (currently 24–27) would use the same version of .NET

[jmcouffin]

1. How can an add-in detect whether the running Revit 2025/2026 build is using .NET 8 or .NET 10?
2. How should publishers package separate .NET 8 and .NET 10 builds for the same Revit version?
3. Does Revit support selecting one DLL or another at load time based on the host runtime?
4. How will Autodesk App Store distinguish between Revit 2025/2026 add-ins built for .NET 8 versus .NET 10?
5. How should add-in updates be synchronized with customer Revit updates?
6. Will Autodesk provide a compatibility matrix showing exactly which Revit 2025/2026 builds use .NET 8 and which use .NET 10?
7. What safeguards will prevent customers from installing or running an add-in build that targets the wrong runtime?

Without this guidance, firms risk production disruption when Revit updates occur before add-ins are rebuilt and redeployed.

[ricaun]

I still gonna continue building my plugin using .NET 8 for Revit 2026/2025, I know for sure a plugin build with .NET 8 gonna run fine in a Revit with .NET 10.

Don't thinks rebuild to .NET 10 is the way to go, only because Revit does not have a way to select the correct .NET version.

I did a video about that, and the best approach is doing nothing about the Target Framework. You can just test in Revit 2027 that is .NET 10, if your plugin is not using any deprecated Revit API you Revit 2026 plugin should load fine.

[Sean_Page]

I mentioned this on LinkedIn, but the only things I have ran into so far with .NET 10 in general have been pretty much all WPF things. There seems to be several things that even .NET 8 would be "OK" with that cause issues in .NET 10. Granted, a lot of them have also been things that I probably should have done differently to start with, but here we are. The actual code / API seems to all be working just fine and I am managing several addins all at various stages of development, versions, and use cases.

Here are just a few items I have found that aren't truly breaking, just things I've had to hunt down or resolve.

1. System.Text.Json is now fully integrated so no need for a dated reference.

2. Stream.Read(buffer, 0, count) --> Stream.ReadExactly(butter,0,count)

3.

4. 

[naveen.kumar.t]

Hi,

Additionally, after November 2026, Microsoft will stop providing updates for .NET 8. Customers who continue using Revit 2025.4 / 2026.4 releases will still be able to work as before; however, there are two important considerations:

1. Security – Microsoft will no longer provide security or maintenance updates for .NET 8.
2. Shared Components – Updating other Autodesk products to .NET 10 may introduce compatibility issues with components shared between Revit and those products. In such cases, updating Revit would be the recommended solution.

Here is the response from the Revit Engineering team regarding your questions.

Q1: How can an add-in detect whether the running Revit 2025/2026 build is using .NET 8 or .NET 10?
A: An add-in can detect the active .NET runtime using the following line:

Version clrVersion = Environment.Version;

Q2: How should publishers package separate .NET 8 and .NET 10 builds for the same Revit version?
A: I am currently discussing this topic with the App Store team. I will provide more detailed guidance once I have a complete understanding of the recommended approach.

Q3: Does Revit support selecting one DLL or another at load time based on the host runtime?
A: The .addin file registers a fixed assembly path, so dynamic DLL selection based on the runtime environment is currently not supported.

Q4: How will Autodesk App Store distinguish between Revit 2025/2026 add-ins built for .NET 8 versus .NET 10?
A: I am currently discussing this topic with the App Store team. I will share additional information once the details are clarified.

Q5: How should add-in updates be synchronized with customer Revit updates?
A: We have communicated this migration through multiple channels, including the Revit 2027 API Update Webinar, blog posts, and the April newsletter, to help customers prepare for the transition.

Q6: Will Autodesk provide a compatibility matrix showing exactly which Revit 2025/2026 builds use .NET 8 and which use .NET 10?
A: As previously communicated, Revit 2025.5, Revit 2026.5, and all later releases will use .NET 10.

Q7: What safeguards will prevent customers from installing or running an add-in build that targets the wrong runtime?
A: In most cases, .NET 8 add-ins are expected to work in a .NET 10 environment without issues. However, if compatibility issues occur, an updated version of the add-in may need to be published through the App Store.vIt is also important to note that compatibility is not bidirectional: add-ins built specifically for .NET 10 will not load or run in a .NET 8 environment.

If you have any additional questions or need further clarification on any of the answers above, please let me know. I will continue working with the Engineering team and will get back to you with more information as needed.

[lukasz_michalskiNCGR7]

Q5: How should add-in updates be synchronized with customer Revit updates?
A: We have communicated this migration through multiple channels, including the Revit 2027 API Update Webinar, blog posts, and the April newsletter, to help customers prepare for the transition.

So answer is - no synchronization mechanism will be present on Revit side.


Q7: What safeguards will prevent customers from installing or running an add-in build that targets the wrong runtime?
A: In most cases, .NET 8 add-ins are expected to work in a .NET 10 environment without issues. However, if compatibility issues occur, an updated version of the add-in may need to be published through the App Store.vIt is also important to note that compatibility is not bidirectional: add-ins built specifically for .NET 10 will not load or run in a .NET 8 environment.

So answer is - no safeguards will be present on Revit side.

[RPTHOMAS108]

I think realistically there are two logical options:

Keep using .net 8 or upgrade to .net 10.

It isn't realistic to simultaneously support both because if you allow certain end users to use .net 8 then you've already compromised and decided to go against 'continued security support', so may as well have just stuck with .net 8 for all.

Probably the technically correct 'security' answer is to upgrade to 10 and expect end users to install 10 if they don't have it. This was always very common in the early era of .Net Framework i.e. requiring a framework to be installed to support a new installation of something (in those days an installer would prompt you to install framework as part of installation {required dependencies was part of installer creating msi files}).

Regarding third party library support you have same basic choice (use things out of update support or don't). This is part of the maintenance task right; review what you have and find things that have a certain future guaranteed to support what you are doing long term? Otherwise what was the plan for 2027 add-in and beyond, wait for someone else to do something? Easy for me to say as I hate third party dependencies mainly for that reason (and sometimes obscure licensing terms).

Also the app store could have taken a stricter view and decided that if .net 8 isn't supported we should not still be allowing the publishing of new add-in packages in .net 8 (because end user experience/security is the priority). It isn't like the old days where some were on Windows 98 and some on Vista in terms of what could and couldn't be supported for .net (anyone can choose to upgrade to 10).

I guess this will be a recurring theme as long the the Autodesk release is out of phase with the .net release. Both probably have fixed release and support cycles; so if it occurs now it will occur again (unless there was some quirk of circumstances this time around)? 

Also forces you to update your VS  2022 solutions to next version since VS 2022 doesn't support .net 10 (although that was minor change if any last time).