Unable to load Plug-in: ID already in use. Rhino 6SR31


Some of our users are experiencing some issues with the plug-in we develop when they upgraded to SR30 and SR31.
Specifically we have encountered 2 issues, which I am not sure if they are related.

Issue one (happening, as far as we know, since SR30):
The reference to the document in the event arguments of EndOpenDocument is sometimes null when a new document (not previously saved) is opened. I have only been able to catch this once when using any of the 2 machines where I develop the plug-in, regardless of whether I start it from the development environment or just from Rhino’s executable directly.
This however seems to happen consistently with other machines.
This never seems to happen if I open a previously saved document.

I am not sure if this is expected behavior, a bug or a problem with my implementation. Any pointers?

Issue two (confirmed to happen only with SR31):
Since SR31 our plug-in won’t load, with Rhino showing the following message:

Unable to load Plug-in: ID already in use

I have checked in the registry for other plug-ins with the same ID, and I have also tried uninstalling any previously installed version and reinstalling, as well as removing the registry entry, but nothing seems to help.

Interestingly, the first time Rhino is opened after installing the plug-in, everything goes smoothly. But the next time is when the message pops. If Rhino is started in safe mode, and the plug-in is loaded manually everything runs smoothly too. So my guess is that there is a conflict with some other plug-in, but I can’t find any.

In the machine where I develop the plug-in this does not happen either, but it does with any other machine, even with new installations of Rhino.

Any pointers as to what can the source be or how can I troubleshoot it?

I am not too worried about about Issue 1 because it is a fringe case and there is a workaround, however Issue 2 is giving me some headaches, and I have had to ask some of our users to downgrade to SR30.

Thanks in advance.

1 Like

Hi @endika,

If we were to have your plug-in installer, can you provide us step-by-step instructions on how to repeat what you are seeing?


– Dale

Hi Dale,

Of course. What is the best way for me to share it with you?

Sent a private message!

I have the same issue, is this solved?

In the case above, the .rhi included both two copies of the plug-in assembly, one with a .rhp extension and one with the original .dll extension. Removing the .dll solved the issue. This was for a RhinoCommon (.NET) plug-in.


There is another situation that occurs (7.0.20314.3001, 11/9/2020)
The reason is found because the Rhino6 plug-in of the same name has been used, and the path of the plug-in is left in Rhino 7. Rhino7 automatically finds and loads the R6 plug-in, causing conflicts. The solution is to delete the original files in the R6 plug-in path to solve the problem.
In addition, I would like to ask where Rhino 7 saves the plugin path. Can you tell me? @will

What is puzzling is that if I put the plug-in with the same name as R6 in another adjacent folder, (R7)it was detected and loaded, and the loading failed. Is there any solution to this? (except changing the file name of one of the plug-ins)

@Easy does the Rhino 7 plug-in load successfully if the Rhino 6 plug-in is uninstalled?

On Windows, the path to the plug-in is saved in the registry. When a plug-in is installed, either via RHI or with a custom installer, its path will be registered as per this guide. When the plug-in is first loaded, the plug-in’s information is saved to HKEY_CURRENT_USER\Software\McNeel\Rhinoceros\7.0\Plug-Ins (using Rhino 7 as an example).

Is OK!


Just change the name!

@Easy, can you send me your Rhino 6 and Rhino 7 plug-ins via private message so I can try to reproduce the behaviour you’re seeing?

It has been sent.

1 Like

I would like to add, that this was my own doing; Just today, while digging in my build configurations, I realized that I had a post-build event, that would copy the plug-in assembly and rename it from *.dll to *.rhp. That is why it was duplicated.

If it is the previous problem (DLL with the same name)
After build:

Erase "$(TargetPath)"
Erase "$(TargetDir)RhinoCommon.dll" //If it exists

Just delete it.

Yap, that is what I did :slight_smile:

Can I ask why the .dll version in same location is an issue? I have been doing this for years, as I then reference that .dll in other projects of the same VS solution. VS will not reference the rhp file directly. The other projects trigger the dll to build when they build.

Maybe there is a better way to do that, but it also used to work just fine, so I assume this is a new issue.

RH-61630 is fixed in the latest Rhino 7 Service Release

Hi. So Pachyderm has just fallen into this issue as well. I don’t know why it never happened on my machine before this evening, but I tried to debug for the first time in a few months, and suddenly this issue has cropped up for me.

I normally try to keep a few versions back, just to allow some of my users some leeway in terms of updates. However, I updated just so that I could try and solve this issue. Now Rhino 6 and 7 are completely up to date. Pachyderm will debug in rhino 7, but it will not even run anymore in rhino 6.

To be frank, my employer was not ready to update to rhino 7 yet, folks, which will leave me in a difficult position with running my simulations. Will there be an update to rhino 6 to fix this issue as well?


Hi @Arthur,

Pachyderm loads and runs fine for me in Rhino 6 SR34 Are you getting a Unable to load Plug-in: ID already in use error? If not, please open a new conversation.

– Dale