Dynamo, pyRevit or a C# add-in: how to choose your Revit automation path

Dynamo, pyRevit and a compiled C# add-in all call the same Revit API. Almost anything one can do, the others can do too. The real choice is about who maintains the tool, how many people run it, and what happens when it meets a 600 MB workshared model.

The short version: Dynamo for exploration and one-off jobs owned by one person. pyRevit for a firm toolbar of small scripted tools. A C# Revit add-in when the tool runs daily, needs a real interface, or has to survive staff turnover and Revit upgrades.

Three ways to reach the same API

Dynamo is the visual programming environment that ships with Revit. You wire nodes into a graph, drop into a Python node when nodes run out, and let colleagues run the result through Dynamo Player.

pyRevit is an open-source environment that turns Python scripts in a folder into ribbon buttons. There is no compile step. A BIM team can publish a toolbar by sharing a folder or a git repository.

A C# add-in is a compiled .NET assembly that Revit loads at start-up. It has the whole API: commands, events, updaters, dockable panels, and any interface that WPF or an embedded web view can draw. It ships with an installer.

Side by side

When Dynamo is the right answer

Dynamo is the right tool when the problem is geometric or exploratory, the job is done a few times, and the author sits near the people who run it. It is also the cheapest way to find out whether a rule can be automated at all.

Two things wear Dynamo graphs down over time:

• Packages. A graph that relies on community packages needs the same package versions on every machine. One update on one laptop gives different results.
• Python engines. Dynamo 4, which arrives with Revit 2027, makes PythonNet3 the Python engine. The older CPython3 engine is marked obsolete and IronPython 2.7 is no longer maintained. Graphs with Python nodes need a review before an office moves to 2027. For offices that run several Revit versions at once, the Dynamo team recommends installing the PythonNet3 engine package on Revit 2025 and 2026 as well.

When pyRevit fits

pyRevit fits a firm that wants dozens of small tools: rename, check, tag, export. The BIM team writes Python, changes go live without a build, and users see ordinary ribbon buttons. It is free and open source.

What to plan for:

• You depend on a volunteer project's release calendar. Revit 2025 moved to .NET 8 in April 2024. The full pyRevit release that supported it arrived in February 2025. That is impressive work for a community project, and still ten months in which an office could not upgrade.
• Two Python engines. IronPython and CPython scripts have different library support. Tools often end up tied to one of them.
• Open source code on every machine. Anyone can read and edit a script. That is a feature for a BIM team and a problem for a product.
• Licence terms. Read them before you sell tools built on top of pyRevit.

When you need a C# add-in

These signals point to compiled code:

• Daily use by more than a handful of people. The cost of one bad run multiplies.
• Large workshared models. You need filtered collectors, one transaction per logical action, failure handling, and checks on element ownership before you write.
• A real interface. Dockable panels, modeless windows, previews, progress and cancel.
• Reaction to the model. Updaters that keep parameters in step, checks on save or sync.
• Integration. ERP, Autodesk Construction Cloud, a pricing service, a licence server.
• Deployment at scale. An installer, silent updates, version numbers, logs you can ask a user to send.
• Intellectual property. The logic is your advantage and should not ship as readable text.

The price is real. You need a developer, a build per Revit version, and a release process. Our guide to Revit add-ins on .NET 10 shows what that upkeep looks like this year.

The upgrade path: from graph to command

A Dynamo graph or a pyRevit script that has proved its value is not wasted when it moves to C#. It becomes the specification. The rules are settled, the edge cases are known, and the old tool gives you expected results to test against.

What changes in the rewrite is everything around the rule:

1. Collectors with category and parameter filters replace "all elements, then filter the list".
2. One named transaction per user action, so Undo shows one entry and a failure rolls everything back.
3. Warnings and failures are handled in code instead of stopping the run with a dialog.
4. Settings are stored with the project or the user, not typed in each time.
5. Units, shared parameters and linked models are handled explicitly.
6. A log records what was changed and what was skipped, and why.

Each step up is triggered by who depends on the tool, not by the language; the rewrite to C# is where the six habits above come in.

The usual trigger for a rewrite is not a missing feature. It is the day the graph's author goes on holiday.

Five questions that decide it

1. How many people will run it, and how often?
2. What does a wrong result cost: a misplaced tag or a wrong rebar schedule?
3. What is the largest model it must handle?
4. Who maintains it in two years?
5. Does it only run on demand, or must it react to the model?

One person, occasionally, low cost of error: stay in Dynamo. A team, weekly, moderate cost: pyRevit. A whole office, daily, high cost, reacting or integrating: a C# add-in.

Where AI coding assistants change the picture

AI assistants now write passable Dynamo Python, pyRevit scripts and C# commands. That lowers the cost of a first version in all three. It does not change the rows of the table above: distribution, upkeep, large models and testing still decide which form the tool should take. We cover that gap in what it takes to ship an AI-built Revit plugin.

Since 2021 Consedge Tech has shipped more than 200 tools for Revit and other engineering platforms. If you are unsure which of the three paths fits your task, book a Feasibility Review. We look at the workflow and a sample model and tell you which form fits, including when the answer is to keep the Dynamo graph. More on how we build is on the plugin development page.

FAQ

Is Dynamo slower than a C# add-in?

On large element counts, usually yes. Dynamo wraps elements, converts geometry and processes lists in ways compiled code can avoid. For a job that touches a few hundred elements the difference does not matter.

Can a pyRevit script be converted to C#?

Yes. Both call the same Revit API, so the logic ports directly. The interface, error handling and packaging are written again.

Do Dynamo graphs survive a Revit upgrade?

Often, but check two things each time: the packages the graph uses and its Python nodes. The move to PythonNet3 in Revit 2027 makes the second check necessary.

Do we need a developer to maintain a C# add-in?

Yes. Someone has to build it for each new Revit version and fix what the release breaks. That is the trade for speed, reliability and control.