Revit add-ins on .NET 10: what breaks in Revit 2025.5, 2026.5 and 2027

Microsoft ended support for .NET 8 and .NET 9 on November 10, 2026. Autodesk moved ahead of that date. Revit 2027 shipped on .NET 10, and the 2026.5 and 2025.5 updates switched two released versions to the same runtime in the middle of their life.

If you maintain a Revit add-in, three Revit versions changed runtime under your code within one year. This guide covers what a Revit add-in .NET 10 migration really involves: what changed, what tends to break, and how to keep one codebase building for every Revit version your users run.

What changed and when

Autodesk's announcement is clear about scope. The .5 updates change the runtime and nothing in the API. Existing add-ins "should continue to work" unless a .NET 10 breaking change touches them.

The cloud side moved too. The Revit Automation engine for Revit 2026 switched to 2026.5 and .NET 10 on September 21, 2026. AppBundles are affected as well as desktop add-ins.

"Should continue to work" is not a test result

Most add-ins built for .NET 8 do load on .NET 10. The ones that fail tend to fail in the same few places.

Clipboard, drag-and-drop and old settings files. BinaryFormatter was removed from the runtime in .NET 9. Add-ins that put custom objects on the clipboard, drag custom data between windows, or read settings once saved with BinaryFormatter now fail at run time, not at compile time. .NET 10 adds type-safe replacements such as Clipboard.TryGetData<T> and SetDataAsJson, and Microsoft documents the migration path.

Third-party dependencies. UI kits, PDF and Excel libraries, serializers and logging packages each need a version that supports .NET 10. A package pinned to an old major version is a frequent reason an add-in loads on one machine and throws on another.

Building against the updated API. After a .5 update is installed, a project that targets net8.0 and references the installed RevitAPI.dll stops compiling with error CS1705. The API assemblies now reference the .NET 10 runtime, and a .NET 8 project cannot reference them.

One-way compatibility. A .NET 8 build is expected to load on the updated Revit. A build that targets .NET 10 will not load on a Revit 2025 or 2026 that has not received its .5 update. Your users are on both sides of that line right now.

Mixed C++/CLI components. Autodesk flags this for AutoCAD object enablers: a managed C++ component that still ships a runtimeconfig.json pinned to .NET 8 needs a rebuild. Check any C++/CLI part of a Revit add-in the same way.

What is specific to Revit 2027

The runtime is only part of the 2027 story. The Revit 2027 SDK notes list changes that hit deployment as much as code.

• New all-users add-in folder. Revit 2027 looks in C:\Program Files\Autodesk\Revit\Addins\2027, not in C:\ProgramData\Autodesk\Revit\Addins\2027. An installer that still writes the manifest to ProgramData produces an add-in that never appears. The per-user folder still works.
• Program Files is not writable at run time. If your add-in saves settings, logs or caches next to its DLL, move them to the user profile.
• More control over add-in isolation. New manifest settings let an add-in choose its load context, share named assemblies and declare dependencies on other add-ins. This is the supported way to stop two add-ins fighting over different versions of the same library.
• API clean-up. ModelPathUtils.CloudRegionUS and CloudRegionEMEA give way to GetAllCloudRegions(). Several rebar creation methods, energy settings and mechanical zone members are deprecated.
• Dynamo 4 arrives with it. PythonNet3 becomes the Python engine, so graphs with Python nodes need their own check.

One codebase for Revit 2024 to 2027

A separate branch per Revit year does not scale past two versions. The pattern that does scale is one SDK-style project with a build configuration per Revit version.

<PropertyGroup Condition="'$(RevitVersion)' == '2024'">
  <TargetFramework>net48</TargetFramework>
</PropertyGroup>
<PropertyGroup Condition="'$(RevitVersion)' == '2025' Or '$(RevitVersion)' == '2026'">
  <TargetFramework>net8.0-windows</TargetFramework>
</PropertyGroup>
<PropertyGroup Condition="'$(RevitVersion)' == '2027'">
  <TargetFramework>net10.0-windows</TargetFramework>
</PropertyGroup>

Keeping 2025 and 2026 on .NET 8 is what lets one binary serve users on both sides of the .5 update.

Four habits make this work in practice:

1. Reference the API from NuGet packages, one per Revit version, not from whatever is installed on the build machine. This also sidesteps CS1705: the 2025 and 2026 builds keep compiling against the original .NET 8 reference assemblies.
2. Keep 2025 and 2026 builds on net8.0-windows unless you need a .NET 10 feature. One binary then loads before and after the .5 update. If you do retarget, the installer must check the Revit build.
3. Wrap version differences in conditional compilation (#if REVIT2027_OR_GREATER) and keep those blocks small and in one place.
4. Build every version on every commit. A CI pipeline that compiles the whole matrix catches a removed API call the day it is written.

For Revit 2027 itself, Autodesk's guidance is to build with .NET SDK 10.0.100 or later and pin it in global.json.

A migration test plan

Compiling is the easy half. This is the list we walk through before an add-in release is called compatible.

1. Inventory. List every dependency with its .NET 10 status. Search the code for BinaryFormatter, Clipboard, DataObject and [Serializable].
2. Build matrix. Build each supported Revit version from a clean machine.
3. Load test on real builds. Revit 2025 and 2026 both before and after the .5 update, plus the latest Revit 2027 update.
4. Command-by-command run on a real project model. Workshared, with links, at production size. Sample files hide transaction and performance problems.
5. UI pass. Modeless windows, drag-and-drop, copy and paste, embedded browser panels.
6. Installer pass. Fresh install, upgrade from the previous version, uninstall, all-users and per-user modes, and the Revit 2027 folder.
7. Neighbours. Run next to the add-ins your users commonly have installed, to surface dependency conflicts.
8. Cloud. Re-run Design Automation AppBundles against the updated engine.

How we handle it at Consedge

We maintain our own Revit products, including Views for Revit and Collision Manager, alongside client and white-label add-ins. A yearly Revit release has always meant a round of builds, tests and installers. A runtime change in the middle of a version's life is the same work on a shorter clock.

The cases that take longest are rarely about code. They are add-ins whose original developer has left, projects that still reference DLLs from a folder on someone's laptop, and installers nobody has rebuilt in three years. If that describes yours, start with the inventory step above.

If you would like a second pair of eyes, book a Feasibility Review. You get a written verdict on what your add-in needs for Revit 2025.5, 2026.5 and 2027. It is part of our plugin development work. Software vendors and BIM consultancies that need this done under their own brand can read how our partner model works.

FAQ

Do I have to recompile my Revit add-in for .NET 10?

For Revit 2025.5 and 2026.5, not necessarily. Add-ins built for .NET 8 are expected to load, but you have to test them. For Revit 2027, plan a dedicated build against the 2027 API with the .NET 10 SDK.

Will an add-in built for .NET 10 run on Revit 2026 without the 2026.5 update?

No. Compatibility goes one way: .NET 8 builds run on the newer runtime, and .NET 10 builds do not run on the older one.

What does error CS1705 mean after installing Revit 2026.5?

Your project targets .NET 8 but references API assemblies that now depend on .NET 10. Reference the original .NET 8 API assemblies from NuGet, or retarget the project.

Where do add-ins go in Revit 2027?

All-users add-ins load from C:\Program Files\Autodesk\Revit\Addins\2027. The ProgramData folder is no longer read for that version.