Click here to Skip to main content
15,740,620 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:

I have developed an application with a plugin architecture using interfaces. I realized that when I release the API for 3rd party plugin development, someone would be able to create a loader program to replace my main program quite easily. Is there any way I can make the plugin dependent on my main program? All my main program does is get an icon and a description of the plugin from the DLL plugin (using the interface) and then calls the dll's interface function to create and display the plugin's form. I guess I have to put the interface in it's own dll and add it as a reference for both the main program and the plugins. If I did that, I thought of sending a key to the display function but even that can be easily replicated through disassembly of the plugin interface dll.

Any ideas?


I think the Managed Extensibility Framework[^] provides you with the features you require based on a standard .Net implementation.

Best regards
Espen Harlinn
Share this answer
Yes, you can do it. Here is the method:

First of all, the plug-in architecture has the dependencies on the following functional units: 1) host application, 2) an interface or a set of interfaces (optional or not) which a plug-in should implement; 3) a in interface or a set of interfaces which the host application should implement (mandatory) and pass the interface reference(s) to the instance of a plug-in; it could be as simple as WriteLine, for example; 4) one or more plug-in implementations.

I hope you can show by yourself what depends on what. Basically, both plug-in and host code depend on all interfaces.

Now, the trick is, in its simplest variant: you can put all parts except (4) in one assembly: the host application!

The question is how? Do you think a project can only reference an object library assembly? No, there is no essential difference between EXE, DLL or anything like that. An assembly is an assembly. Any assembly can referenced by any other assembly. In your case, you should put all interfaces and host-side implementation is the assembly of the host application (if can reference any number of other assemblies, of course, but not with the interfaces mentioned above) and each plug-in should add a reference to the entry assembly of your host application.

In case you still did not get it, here is the note: It won't create any circular dependencies. In this scenario, each plug-in depends only on the entry assembly on the host application. The host application itself does not depend on plug-ins; only it run-time depends on them, but it does not ruin anything. This really works, I did it in a few projects.

Now, the only missing piece is: how to prevent replacing of the host assembly by a forged one? The solution is well-known: make an entry assembly of the host application strongly named by giving it a digital signature; don't pass a private key and the source code to the user.

Of course, almost nothing can prevent reverse engineering. But even with the reverse engineering, no one can reverse engineer just the main system and then use the plug-ins without limitations. This person would need to reverse engineer each plug-in, no less, so she or he won't be able to create a "final" solution and, say, cell it — this solution won't be able to work with legitimate or new plug-ins.

Please see my past solutions on plug-in architecture:
Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^],
code generating using CodeDom[^],
Create WPF Application that uses Reloadable Plugins...[^],
Dynamically Load User Controls[^],
how to Catch an unhandled exception thrown from a sub domain when calling a method by inkove(reflection)[^].

Share this answer
JBenhart 26-Jan-12 0:47am    
OK so you are saying put the interface into my main app and then 3rd party developers will have to reference the main app to access the interface. If I understood that correctly, that is brilliant!

The part about the digital signature is confusing though. Can you explain that in more detail,step by step?

JBenhart 27-Jan-12 23:44pm    
Now that isn't three in the morning, I may make more sense. I can put the everything but the plugin interface implementation in the host application. I can also pass the host mandatory interface by reference to the plugin but I am not sure how that would prevent someone from not replicating the host program since they will have the interface in the plugin. I understand that an official plugin will have a reference to the host plugin but can't that also be forged? Or have I completely missed your point. I am guessing I have.

Either way, thank you very much for the explanation!
JBenhart 28-Jan-12 0:07am    
Oh, I see. It's amazing how deep the rabbit hole goes... lol

Do you have any other helpful posts or links about strongly named assemblies with digital signatures?

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900