Something wrong when using Microsoft.Office.Interop.Excel in Revit 2025, Dynamo 3.0.2

It can run well in previous version. But pop up the warning in Revit 2025, Dynamo 3.0.3.


My understanding was in Net Core and beyond Python was not able to use the interop tools for Excel, but commenting here in case there is actually a fix. I believe C# still has ways to package and access it, but OpenXML was getting more endorsement in my searches.

It’s going to hit my pyrevit toolbar like a nuke once we reach 2025, but I’ve been learning C# as an escape route from the Python gotchas etc. for a while now.

If you end up using CP3, look into pandas as an alternative route maybe.

Good guide on working with CP3/packages etc. here:

1 Like

Thank you for your quick reply. I also think it should be caused by the Net Core update, so I posted this issue in the forum and look forward to the latest solution (if keep using ironpython2). :grinning:

Based on the messaging I’ve been getting the likely response you will get is not to use ironpython2 in future. I’m already beginning to pivot to CPython3 where possible in Crumple (not released as such), the writing is on the wall come 2025. I was hoping to use IP2 for as long as possible but in my testing the net core change really prevents IP2 being continuable I think in current state.

I was planning to piggyback on pyrevit supporting IP2, but messaging there also leans towards CP3 or later variants of IP at the least. Time to bite the bullet I think.

Hi,

Interrop still works, but Net Core don’t have access to the Global Assembly Cache GAC

I recently updated an example here for Net 8 compatibility

Pandas, openpyxl and Openxml are also viable solutions

3 Likes

I’m curious RE how enums are built upon/maintained by MS - are these values effectively fixed in future updates of interop as far as you know? I’m always hesitant on assumed constants but have used this before as well for other purposes.

due to the change to Net 8, I recommend using IPY3, CP3 or C#. Be careful however with CP3 it does not yet include PythonNet 3

.Net 8 should in my opinion mean new package versions

1 Like

It’s just an workaround, another option is to use the same assembly version of Excel Interrop that Dynamo Team use in Dynamo 3

1 Like

Yes generally at this point I have decided to convert as much of Crumple as I can to CP3, as much work as it may be… your advice helps reaffirm my choice. Aware CP3 may be challenging, but having to suggest parallel IP package installs has been a challenge when trying to encourage and guide use of the package.

the problem is that CP3/Pythonnet2 has some bugs and .Net 8 adds others (hence my mention of IP3 and C#)

As indicated on the Dynamo roadmap, PythonNet3 integration is planned, which should correct many bugs.

2 Likes

I knwo this is not the right forum, but i still want your guys opion on it:
What is the impact of this on pyrevit?
have any thought on the sustainablity of it?

Theyre going to have to face it sooner or later, as i know many firms are beginning to reject ironpython2 due to vulnerability concerns (mine included).

Cpython3 has quite a few challenges to my understanding in pyrevit and the general stance is to avoid it in many cases, and the core tools are built in ironpython2.7 still.

Like dynamo, they will probably have to jump to pythonnet or a newer ironpython to remain a heavily used app by larger firms, but it would likely be a lot of work.

I love pyrevit for what it is, but having jumped to c# can comfortably say this should be the endgame for any firm/person looking to deploy stable, secure and scalable solutions (+ web integrations from there). Its not for everyone, and has a steeper learnint curve with a higher ceiling of opportunity.

We pushed it hard where i work initially, and had much success, but redeveloping all our tools in c# has given us an edge over what we had before in pyrevit (we have 200+ custom tools/buttons built/rebuilt in both).

Pyrevit is ultimately a dependency with no guarantee of maintenance, but for now a passionate community doing great things with/for it.

For any pyrevit users curious about c#, i have an open sourced toolbar here that is heavily inspired by pyrevit, with similar forms and toolbar structure:

In relation to this topic, my toolbar integrates the closedxml package to import/export excel which is compatible with all revit versions so far up to 2026. I abstract it into a set of functions in this library:

2 Likes

I’ll echo @GavinNicholls here. As good as the tool has been for many, it is a literal time bomb if it is in your environment - known vulnerabilities already exist, it’s just a matter of qhen and how large the exploitation will be. Sadly the development team for PyRevit doesn’t seem to have the resources needed to get beyond the core dependency on IronPython2.

I want to be clear about this next bit, so I am breaking out the bold text: I do not mean that as knock on the tool, developers, or the community. This is a HUGE lift which very few people with AEC backgrounds could do (say nothing of doing it well), and people who are from other industries who are readily able are hesitant to take on this type of project for fun (it isn’t sexy, fun, or a major portfolio piece). I am hopeful that the Dynamo team will open source a better integration which they can transition to, and that the user base will be able to manage the transition. But knowing how little firms are willing to commit resources to maintaining their tools, it wouldn’t surprise me if that last bit doesn’t happen, and if so the efforts of many may become lost to time.

5 Likes

To add to this, one way we became more aware of this is that we were literally promoting that we use pyrevit at conferences etc. It got me thinking of the risks of publically declaring organisational vulnerability to anyone trying to figure out who best to target. Food for thought…

I genuinely hope they navigate their way through the engine debacle as its an awesome toolkit and effort. It does seem that the destiny of most open software like it is to hit the shelves unlese they find backers like ladybug tools. It does suffer from not having utility that a non coder can easily grasp unlike LBT, so convincing a firm to back it at the decision maker level is tough. Doesnt help that most people just see pyrevit for its sample toolbar, as great as it is its the icing on the cake.

If for some reason that does happen i will probably attempt to rebuild what i can of its core toolkit in native c# with source code available. Im already a fair way into building its utilities as is for my own toolbar.

3 Likes