TL;DR
Revit 2027 ships on .NET 10, which makes the IronPython 2.7.12 currently embedded in RBP unusable: IronPython 2's dynamic-type-generation (NewTypeMaker.ImplementCustomTypeDescriptor) does reflection-emit against runtime APIs whose signatures changed in .NET 10, so any IronPython 2 add-in fails on engine init under Revit 2027.
Supporting Revit 2027 isn't possible without migrating RBP's scripting host to IronPython 3. I've done that migration and have it working end-to-end — sharing as a starting point in case it's useful.
This also resolves the long-standing request in #111.
Working fork
https://github.com/robmintzes/RevitBatchProcessor/tree/feature/revit-2027-support
Two commits, logically separable:
-
615bfd1 — Add Revit 2027 support. Pure additive changes: a Revit2027 entry in SupportedRevitVersion and the three sibling dictionaries in RevitVersion.cs; one entry in BatchRvt.BATCHRVT_ADDIN_FILENAMES; one entry in the UseRevitVersion enum in BatchRevitDynamo; a new BatchRvtAddin2027 project mirroring BatchRvtAddin2026; and the matching solution-file registration. (Plus a Directory.Build.props that adds Microsoft.NETFramework.ReferenceAssemblies so the net48 projects build without a system-wide Developer Pack install.)
-
ec5e34e — Migrate IronPython 2.7 → 3.4 for Revit 2027 / .NET 10 support.
This is the substantive change. Bumps IronPython to 3.4.2, adds IronPython.StdLib 3.4.2 for the Py3 stdlib, retargets the 2027 addin to net10.0-windows, patches ScriptHostUtil.cs to register the stdlib's lib/ folder on sys.path and skip the now-unparseable python_27_lib.zip loader, and modernizes the bundled scripts in BatchRvtUtil/Scripts/ to Py3 syntax (49 except X, e: → except X as e: across 21 files, plus execfile/xrange/exceptions-module and a couple of .None reserved-keyword fixes).
What I've verified end-to-end
Full chained sweep across Revit 2023, 2024, 2025, 2026, and 2027 of two real .rte templates (~91 MB each), processed via a single PowerShell driver invocation through BatchRvt.exe. 20m 5s wall time, two saved outputs per year, no manual intervention required.
The migration is mostly mechanical; the trickiest part was bypassing IronPython 3's codec registry for source-file reading (the bare interpreter
doesn't ship codec modules and the StdLib package isn't on sys.path yet when script_util.ExecuteScript first runs — easiest workaround is to read via System.IO.File.ReadAllText with System.Text.Encoding.UTF8).
Compatibility considerations
The fork's 2027 addin is the only build that targets net10.0-windows / IronPython 3.4.2. The 2025 and 2026 addins are unchanged and continue working with IronPython 2.7.12 on .NET 8. This intentionally lets users on older Revit versions keep their existing setup.
If you're interested in merging this, happy to split the work into smaller reviewable PRs — for instance:
- Just the
BatchRvtAddin2027 project addition + enum/dictionary entries (the 615bfd1 commit, minus the parts that assume IronPython 3).
- The IronPython 3 migration as a separate, opt-in path.
- The Py2→Py3 script modernization, which arguably stands on its own as a general cleanup even for the IPy 2 codepath since
except X as e: is valid in both.
Or as one PR, whichever you prefer. Let me know how I can help move this along.
Refs #111
TL;DR
Revit 2027 ships on .NET 10, which makes the IronPython 2.7.12 currently embedded in RBP unusable: IronPython 2's dynamic-type-generation (
NewTypeMaker.ImplementCustomTypeDescriptor) does reflection-emit against runtime APIs whose signatures changed in .NET 10, so any IronPython 2 add-in fails on engine init under Revit 2027.Supporting Revit 2027 isn't possible without migrating RBP's scripting host to IronPython 3. I've done that migration and have it working end-to-end — sharing as a starting point in case it's useful.
This also resolves the long-standing request in #111.
Working fork
https://github.com/robmintzes/RevitBatchProcessor/tree/feature/revit-2027-support
Two commits, logically separable:
615bfd1— Add Revit 2027 support. Pure additive changes: aRevit2027entry inSupportedRevitVersionand the three sibling dictionaries inRevitVersion.cs; one entry inBatchRvt.BATCHRVT_ADDIN_FILENAMES; one entry in theUseRevitVersionenum inBatchRevitDynamo; a newBatchRvtAddin2027project mirroringBatchRvtAddin2026; and the matching solution-file registration. (Plus aDirectory.Build.propsthat addsMicrosoft.NETFramework.ReferenceAssembliesso the net48 projects build without a system-wide Developer Pack install.)ec5e34e— Migrate IronPython 2.7 → 3.4 for Revit 2027 / .NET 10 support.This is the substantive change. Bumps
IronPythonto 3.4.2, addsIronPython.StdLib3.4.2 for the Py3 stdlib, retargets the 2027 addin tonet10.0-windows, patchesScriptHostUtil.csto register the stdlib'slib/folder onsys.pathand skip the now-unparseablepython_27_lib.ziploader, and modernizes the bundled scripts inBatchRvtUtil/Scripts/to Py3 syntax (49except X, e:→except X as e:across 21 files, plusexecfile/xrange/exceptions-module and a couple of.Nonereserved-keyword fixes).What I've verified end-to-end
Full chained sweep across Revit 2023, 2024, 2025, 2026, and 2027 of two real .rte templates (~91 MB each), processed via a single PowerShell driver invocation through
BatchRvt.exe. 20m 5s wall time, two saved outputs per year, no manual intervention required.The migration is mostly mechanical; the trickiest part was bypassing IronPython 3's codec registry for source-file reading (the bare interpreter
doesn't ship codec modules and the StdLib package isn't on
sys.pathyet whenscript_util.ExecuteScriptfirst runs — easiest workaround is to read viaSystem.IO.File.ReadAllTextwithSystem.Text.Encoding.UTF8).Compatibility considerations
The fork's 2027 addin is the only build that targets
net10.0-windows/ IronPython 3.4.2. The 2025 and 2026 addins are unchanged and continue working with IronPython 2.7.12 on .NET 8. This intentionally lets users on older Revit versions keep their existing setup.If you're interested in merging this, happy to split the work into smaller reviewable PRs — for instance:
BatchRvtAddin2027project addition + enum/dictionary entries (the615bfd1commit, minus the parts that assume IronPython 3).except X as e:is valid in both.Or as one PR, whichever you prefer. Let me know how I can help move this along.
Refs #111