Rhino Inside Revit fails to load

I got Revit 2025.3 installed along with Rhino Inside Revit 1.25.9063.15948. When I try to launch RIR it just hangs and spins forever consuming more and more memory. It tapped me out at 20+GB of RAM used and I just had to terminate it but Rhino never loaded. The same version of RIR works fine in Revit 2024.3. I am using Rhino 8 8.13.24317.13001.

I have checked the Event Viewer for errors but nothing gets logged in there. Again, it just hangs as opposed to throwing any particular exceptions.

I am not sure if this is going to be enough to recreate so please let me know if I can provide any other info.

1 Like

Hi Sobon_Konrad,

Try launching RiR with no other Revit Addins.

If its still not launching properly we should look at Rhino plugins, Revit 2025 runs in netcore 8 and we typically run in netcore 7.

@Japhy you were right. Climate Studio it was. I am guessing the overlap there is around Eto. That’s been causing a lot of grief not just for me but also for Pollination folks in the past. I guess it’s also an issue for you guys now with the RIR and Climate Studio Eto versions clashing.

I know I sent that question in private but I will repeat it here for posterity. The thing that I am looking into here is being able to load different versions of my plugin into Rhino depending on the Runtime that it launches in. My thinking is the following here:

Option 1:
Build two plugins with different GUIDs and install both. One that supports the .NET Framework and one that supports .NET7. Now if a user opens RIR in R2025 it will force Rhino to launch in .NET7 and the .NET Framework plugin fail to load.

The issue here is that one of these plugins fails to load and shows an error:


Not ideal. Can we hide it?
Option 2:
Build two plugins but load them dynamically. If there was some kind of “per session” plugin loading method that would be ideal. All I can see in the Plugin https://mcneel-apidocs.herokuapp.com/api/rhinocommon/rhino.plugins.plugin class for Rhino Common though is that there is indeed a load method, but it functions as an install so I am guessing it sticks for longer than a single session. Is there a way to work around that?

Rhino 8 supports .NET multi-targeting for plug-ins. If you place the .NET 7, etc. and .NET Framework assemblies in separate subfolders named according to the runtime (e.g. net7.0 and net48) then rhino will load the right one. I don’t believe the two versions would need different plug-in GUIDs, since only one is loaded at a time.

https://mcneel.myjetbrains.com/youtrack/issue/RH-76604/LoadPlugin-Added-support-for-multi-targeting-plugins-to-have-specific-assemblies-for-.NET-Core-vs.-.NET-Framework

@will is the same true for the old RHI packages? Just nest these into sub-folders like so:

  • Rhino 8
    • net7.0
      • plugin contents
    • net48
      • plugin contents
  • Rhino 7
    • net48
      • plugin contents

etc.