插件依赖于主程序吗? [英] Plugin Dependant On Main Program?

查看:114
本文介绍了插件依赖于主程序吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

你好,

我已经开发了一个使用接口的插件体系结构的应用程序.我意识到,当我发布用于第三方插件开发的API时,某人将能够创建一个加载程序来轻松替换我的主程序.有什么办法可以使插件依赖我的主程序?我所有的主程序要做的就是从DLL插件(使用该接口)获取图标和插件说明,然后调用dll的接口函数来创建和显示插件的表单.我想我必须将接口放入它自己的dll中,并将其添加为主程序和插件的引用.如果这样做的话,我曾想过向显示函数发送一个密钥,但即使这样也可以通过反汇编插件接口dll轻松复制.

有什么想法吗?

谢谢!

Hello,

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?

Thanks!

推荐答案

我认为托管扩展框架 [ ^ ]提供了为您提供基于标准.Net实现所需的功能.

最好的问候
Espen Harlinn
I think the Managed Extensibility Framework[^] provides you with the features you require based on a standard .Net implementation.

Best regards
Espen Harlinn


是的,您可以做到.方法如下:

首先,插件体系结构依赖于以下功能单元:1)主机应用程序,2)插件应实现的接口或一组接口(可选或不可选); 3)主机应用程序应实现(强制)的in接口或一组接口,并将接口引用传递给插件实例;例如,它可能像WriteLine一样简单; 4)一个或多个插件实现.

我希望您能自己展示什么取决于什么.基本上,插件和主机代码都依赖于所有接口.

现在,诀窍在于其最简单的变体:您可以将除(4)之外的所有零件放在一个程序集中:主机应用程序!

问题是如何?您认为项目只能引用对象库程序集吗?不,EXE,DLL或类似的东西之间没有本质区别.装配体是装配体.任何其他程序集都可以引用任何程序集.对于您的情况,您应该放置所有接口,并且主机端实现应是主机应用程序的程序集(当然,如果可以引用任何数量的其他程序集,但不能使用上述接口),并且每个插件应该添加对宿主应用程序的入口程序集的引用..

如果您仍然没有得到它,请注意以下内容:它不会创建任何循环依赖项.在这种情况下,每个插件仅取决于主机应用程序上的入口程序集.主机应用程序本身不依赖于插件;仅它的运行时间取决于它们,但它不会破坏任何东西. 这确实有效,我在几个项目中都做到了.

现在,唯一缺少的部分是:如何防止伪造的主机组件替换主机组件?该解决方案是众所周知的:通过给主机应用程序一个数字签名来为其创建一个强命名的条目程序集;不要将私钥和源代码传递给用户.

当然,几乎没有什么可以防止逆向工程.但是即使进行了逆向工程,也没有人可以对主系统进行逆向工程,然后不受限制地使用插件.这个人至少需要对每个插件进行反向工程,因此她或他将无法创建最终"解决方案,例如,将其单元化–此解决方案将不会无法使用合法或新的插件.

请查看我过去有关插件体系结构的解决方案:
创建使用可重载插件的WPF应用程序... [ ^ ],
AppDomain拒绝加载程序集 [使用CodeDom生成代码 [创建使用可重载插件的WPF应用程序... [ ^ ],
动态加载用户控件 [如何捕获从子项引发的未处理异常通过inkove(反射)调用方法时的域 [
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)[^].

—SA


这篇关于插件依赖于主程序吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆