Revit, Tools

Custom Revit Add-in Development Services — C# .NET & API

Posted on by Nguyen Huu Khanh
Custom Revit Add-in Development - Dynamo and Revit API

3dshouse builds custom Revit add-ins in C# on the Revit API, for BIM teams, architecture and engineering firms, and product manufacturers. Revit plugin development services covering data automation, batch tools, family and parameter management, and integrations that turn hours of repetitive Revit work into one button.

Before you judge a Revit developer on a portfolio page, install one of their add-ins. Your add-in is built by the developer of Metasheet for Revit — a free add-in that edits parameters, schedules, sheets and views in a spreadsheet grid, and loads in Revit 2022 through 2027 out of a single source tree. The workflow behind it is AI-assisted, which is what keeps delivery fast: see how we build Revit add-ins with AI.

Revit Add-in Development Pricing

Package Scope Price Delivery
Script / Single tool One well-defined command or a Dynamo script converted to a proper add-in. Source code included. from $300 3–5 days
Add-in with UI 2–4 features, WPF dialog, ribbon panel integration. Source code included. from $800 1–2 weeks
Complete add-in Full UI, multi-version support, installer, company deployment, external integrations. Source code included. from $1,500 2–4 weeks
  • Consultation and exact quote are free — describe what you need and you get a fixed quote within 48 hours.
  • 50% deposit to start, the rest on delivery. 2–3 revision rounds are included in the agreed scope.
  • You own the delivered code. Support for Revit 2022 and newer, multi-version builds available.

Which Revit releases your plugin has to load in

Scoping comes before pricing, because the .NET runtime under Revit changed twice in three releases. Autodesk states it per version in the Revit API Development Requirements page:

  • Revit 2022–2024 — “The Autodesk Revit API requires the Microsoft .NET Framework 4.8”, built with Visual Studio 2019 or later. Target framework net48.
  • Revit 2025–2026 — “The Autodesk Revit API requires Microsoft .NET 8.0”, Visual Studio 2022. Target framework net8.0-windows.
  • Revit 2027 — “Revit 2027 has been updated to use the final .NET 10 runtime for running Revit and building add-ins”, .NET SDK 10.0.100. Target framework net10.0-windows.

One compiled DLL cannot cross those boundaries. .NET Framework 4.8, .NET 8 and .NET 10 are different runtimes, not different compiler switches, so an add-in that covers Revit 2022 to 2027 is three builds behind one installer, not one build and a recompile-and-hope. The good news is that this is a build problem, not a code problem: one shared C# source tree, multi-targeting in the project file, and a handful of conditional blocks.

Two dates belong in any plan longer than a few months: Microsoft ends support for .NET 8 on 10 November 2026, and .NET 10 (the Revit 2027 runtime) is supported until 14 November 2028. An add-in written now should be structured so the next runtime bump is a rebuild, not a rewrite.

What a shipped multi-version add-in actually looks like

Metasheet, our free spreadsheet editor for Revit data, is the reference build for this service: one repository, three target frameworks compiled side by side, Revit 2022 to 2027. Four things in it are worth knowing before you commission a multi-version add-in from anyone.

  • Compile each line against its oldest API, not its newest. The net48 assembly targets the Revit 2022 reference assemblies, net8 targets 2025, net10 targets 2027. A binary built against the 2024 API can fail to load in 2022; built against 2022 it loads across the whole 2022–2024 line.
  • The Revit reference assemblies come from NuGet, so the build machine needs no Revit installed. Only the integration tests, which run inside a real Revit session, need a local installation. That is what makes building six Revit versions on one machine, or on CI, practical.
  • .NET class libraries do not copy their NuGet dependencies to the output folder; .NET Framework ones do. Port a working net48 add-in to net8 and your JSON library quietly vanishes from the payload. The add-in then runs on whatever copy Revit happens to have loaded already, until it meets a Revit that has none and shows no ribbon button at all. One MSBuild property (CopyLocalLockFileAssemblies) fixes it; finding it costs a day.
  • An Autodesk App Store bundle matches SeriesMin exactly and ignores SeriesMax. A single Components block declaring R2022 to R2027 loads in Revit 2022 and nowhere else, silently. A bundle that really covers six releases needs six Components entries, each pointing at the payload for that version’s runtime.

The same build produces both delivery channels: an .msi installer for direct download and a bundle for the Autodesk App Store. You do not have to take any of this on trust — install Metasheet free (every feature, no Pro tier, only a free 3dshouse account) and inspect the output of this pipeline in your own Revit before commissioning anything.

Revit 2026 broke two things in older add-ins

  • CefSharp is gone. Autodesk removed every CefSharp binary from the Revit 2026 install and recommends WebView2 instead. An add-in whose interface relied on Revit’s copy of the embedded Chromium browser stops rendering. Metasheet’s dialog has been WebView2 from the start, which is why one UI layer serves 2022 to 2027.
  • Add-ins can now load in their own assembly context. Set UseRevitContext to false in the .addin manifest (default true, with an optional ContextName) and the add-in is isolated from Revit and from every other add-in, which ends the classic crash where two add-ins load two versions of the same DLL. Autodesk’s caveat is the part teams miss: once isolated, you can no longer rely on Revit or another add-in having loaded your dependency for you, so the payload has to be complete.

A smaller one that bites during the .NET 8 port: System.Windows.Forms.TaskDialog exists only in .NET 5 and later. In a net48 add-in, using System.Windows.Forms; next to using Autodesk.Revit.UI; compiles fine. In net8.0-windows the same two lines make TaskDialog ambiguous and the build stops. Fully qualifying Autodesk.Revit.UI.TaskDialog is the fix.

What we can build — custom Revit add-in scope

  • Data automation: schedules and model data to Excel or Google Sheets and back, bulk parameter editing, model audits — see the landscape of Revit plugins that move data to and from Excel.
  • Batch tools: sheet and view creation, printing and export (PDF/DWG/IFC) across the whole project in one click.
  • Family automation: generate and update families and types from your product catalog or spreadsheets.
  • Dynamo to add-in: convert slow, fragile Dynamo scripts into fast, production-ready Revit add-ins your whole team can run.
  • Integrations: connect Revit to your ERP, pricing database or web service through the Revit API.

The Revit rules we design around from the first commit

Rushed Dynamo conversions turn fragile for the same handful of reasons. None of them appear in a five-element demo; all of them appear on a real model.

  • Document changes only run on Revit’s main thread. Starting a transaction from a modeless dialog’s own thread throws and can leave the journal inconsistent. Work is marshalled back to Revit through an ExternalEvent queue instead.
  • ExternalEvent, not Idling. The Idling event fires constantly, so a queue polled from it costs time for every second the dialog is open. ExternalEvent is the idiomatic way to hand work back from a modeless dialog.
  • One transaction per batch, with a failure preprocessor. A 50-row edit that trips soft warnings (room not enclosed, joined geometry, a clamped parameter) stacks 50 modal dialogs inside Commit(). A preprocessor deletes warnings, rolls the whole batch back on real errors, and reports one message instead of fifty.
  • Unique-value parameters need two passes. Sheet Number, Mark, Type Name and Family Name must stay unique, so swapping two sheet numbers, or shifting a range of them by one, fails halfway through a naive one-row-at-a-time write because the intermediate state holds duplicates. Renaming to placeholders first and to the final values second, inside one transaction, is what makes a bulk rename survivable.

Benefits for BIM teams and manufacturers

  • Hours of repetitive Revit work become one button.
  • Standards are enforced by the tool, not by training documents.
  • Manufacturers: your products become Revit families that designers actually place in projects.

How to choose a Revit add-in development company

Five questions separate a Revit API development service provider who has shipped from one who has not:

  • Which runtime lines will you build, and do I get one installer or three downloads?
  • Which API version is each line compiled against?
  • Do I own the source, and can my own developer rebuild it without you?
  • How is the move to .NET 10 for Revit 2027 handled — in scope, or a new project?
  • Is the add-in tested inside a real Revit session, or only unit tested?

Process

  • You describe requirements and goals — free consultation.
  • We confirm the scope and send a fixed quote with completion time within 48 hours.
  • 50% deposit, development starts.
  • You test the build and give feedback (2–3 revision rounds included).
  • Delivery, final payment, and after-delivery support.

Contact: get a free quote

Send what the tool should do, the Revit/SketchUp versions you use and, if you have one, a sample file. You get a fixed quote within 48 hours.

Frequently asked questions

What is the Revit API?

The Revit API is the programming interface Autodesk exposes for Revit, reached from any .NET language (C# is the common choice). An add-in references RevitAPI.dll and RevitAPIUI.dll from the Revit program folder and is registered with Revit through an .addin manifest file.

Do Revit 2026 add-ins have to target .NET 8?

Yes. Autodesk’s development requirements for Revit 2026 state that the Revit API requires Microsoft .NET 8.0, built with Visual Studio 2022; the target framework is net8.0-windows. The same applies to Revit 2025. Revit 2027 moved again, to .NET 10.

Does a Revit 2024 add-in still use .NET Framework 4.8?

Yes. Autodesk’s development requirements for Revit 2024 state that the Revit API requires the Microsoft .NET Framework 4.8, as they do for Revit 2022. An add-in for that line targets net48 and will not load in Revit 2025 or later without a separate build.

Who can build custom Revit automation tools for construction companies?

Any .NET developer with Revit API experience can, but the practical filter is whether they have shipped and maintained an add-in across several Revit releases. Ask for a tool you can install yourself; ours is Metasheet, free, covering Revit 2022 to 2027.

How much does custom Revit or BIM automation cost?

Our packages start at $300 for a single command or a Dynamo script converted to a proper add-in, $800 for an add-in with a WPF dialog and ribbon integration, and $1,500 for a complete add-in with multi-version support, installer and integrations. Source code is included in all three, and the exact quote is fixed and free.

Also need a custom SketchUp plugin? See our custom SketchUp plugin development service.

Nguyen Huu Khanh

Architect turned developer