Plugin init fails with "System.Exception: No PlugIn subclass found."

I’m developing a plugin that has started to have the problem summarized in the title. The infuriating thing is that it’s not consistent; one some machines, the init fails, and on others, it works fine. It works on all of our development machines, which might be a clue, but I can’t think of how. It’s such a weird problem. When I rename the .rhp to a .dll and load it in an Object Browser I can see the plugin class (with appropriate ancestry) fine. I have been able to establish that when it doesn’t work the plugin constructor isn’t being called.

It might matter that the plugin doesn’t directly inherit from Rhino.PlugIns.PlugIn; there’s an intermediate class in the way. But I that system hasn’t changed since the last time this worked.

Any ideas?

My simple example of a plug-in that does not directly inherit from Rhino.PlugIns.PlugIn seems to work here. (3.5 KB)

We will probably need more information and details as to what you doing. Just curious, why are you not inheriting directly from Rhino.PlugIns.PlugIn?

Is your intermediate class abstract? If it isn’t, then there will most likely be problems since the plug-in loading routine is looking for the definition of a single public class that is derived from PlugIn, has a default constructor, and is not abstract. If it finds more than one, then you should get a message about this error.

The intermediate class is abstract, and as I said, it’s worked before and it still works sometimes.

The reason we don’t inherit directly is essentially convenience; our collection of plugins all had a set of things that they needed to do and it was easier to write up an abstract class and send it to individual plugin developers to inherit from than to say “and make sure your plugin does all these things.” However, I guess it’s no longer worth the trouble, so I can just take that layer out. I’m still curious about the indeterminism of the problem, but hopefully it can be made academic at this point.

I don’t know. I’ve never heard of this issue before.

We’ve found the problem. It was…the Visual Basic Power Packs, which include a handful of WinForms controls. Apparently when the assembly is missing from the plugin directory, rather than emitting the standard error you’d expect to see, I got this. I still have no idea why, but supplying the assembly seemed to fix the problem.

The Power Packs are included transparently with VS 2010, which is why we didn’t notice that we had an external reference we weren’t accounting for.

Thanks for the update.