Rhino Inside Revit fails to load

[sobon_konrad]

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.

[Japhy]

Hi Sobon_Konrad,

Try launching RiR with no other Revit Addins.

Help Us Help You - Rhino.Inside.Revit Edition

3. Additional Troubleshooting Methods You can Cntl+Shift on the Rhino start button on the Rhino Ribbon in Revit to get this dialog. [image] If you are experiencing odd behaviors it could be a Grasshopper plugin. You can troubleshoot by opening grasshopper via the Rhino command line with the GrasshopperLoadOneByOne command. Its also easy to move grasshopper plugins out of their folder temporarily so they won’t load.

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.

[sobon_konrad]

@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?

[will (Will Pearson)]

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.

.NET multi targeting for yak packages

I have a question related to Moving to .NET 7 and the plugin package manager. Is it possible to create packages which contain a .NET FrameWork 4.8 as well as a .NET 7 build, such that Rhino can choose whatever is best according to the runtime chosen with SetDotNetRuntime?

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

[sobon_konrad]

@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.