实现插件架构 - 动态 DLL 加载
我有一个应用程序，它基本上是一个带有预加载控件的设计器，您可以在其中使用控件设计页面。
我计划在未来发布越来越多的控件。我不想为新添加的控件发布新版本，因为它有其缺点。所以我正在考虑插件/插件类型的架构，我只是单独发布插件/插件，他们可以安装并获取设计器内的控件。
现在，我使用 xml 文件作为插件来指定控件、其行为、样式等。每个 xml（插件）代表一个控件。但我发现实现这一点非常困难，因为我必须编写一个通用解析器来读取所有插件。
相反，我可以为每个插件发布一个 dll，这给了我更多的控制权来编写代码来定义控件的行为/外观并通过主引擎动态加载它吗？如果是这样，我如何检查 dll 并将其动态加载到我的应用程序中？
I've an application which is basically a designer with preloaded controls where you can design your pages using the controls.
I'm planning to release more and more controls in the future. I don't want to release a new build for newly added controls as it has its disadvantages. So I was thinking of addon/plugin kind of architecture where I just release the addon/plugin separately which they can install and get the controls inside the designer.
Right now I'm using xml files as addons to specify the controls, its behaviors, its styles etc. Each xml (addon) represents a single control. But I'm finding it very difficult to implement this since I've to write a generic parser to read all the plugins.
Instead, can I release a dll for each addon which gives me more control to write code to define the behavior/look of the control and dynamically load it through the main engine? If so how can I check for dlls and load it dynamically in my application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能需要查看托管扩展性框架。这可能会解决您的大多数问题以及更多问题，但需要学习一些新技术...
您绝对应该按照 mathieu 的建议研究
System.Addin命名空间！如果您想采用自己的路线，我建议采用以下方法：
Assembly.Load加载 dllYou might want to look at the Managed Extensibility Framework. This will probably solve most of your issues and more, but will require learning some new tech...
You should also definitely look into the
System.AddinNamespace as mathieu suggests!If you want to go with your own route, I suggest the following approach:
Assembly.Load您应该查看 System.Addin 命名空间，因为它确实适合您的需求。开发插件后，您只需将其放入文件夹中，它就可以（在运行时）供您的应用程序使用。
请参阅此问题进行比较：在 MEF 和 MAF (System.AddIn) 之间进行选择
You should have a look at System.Addin namespace, as it really fits your need. After an addin is developed, you just have to drop it in a folder, and it is available (at runtime) for your application.
See this question for comparison : Choosing between MEF and MAF (System.AddIn)
提到的 MEF 或 System.Addins 路由可能是实现此目的的最有效方法。我只是插话说一些关于替代方案的事情。
我已经多次“手推”这种解决方案，我想说，除非有令人信服的理由从头开始，否则最好使用现有的插件框架。但如果您打算这样做，我发现依赖注入容器如 Castle 或（在此处插入您首选的 DI 容器）可以帮助处理一些机制。
另外，根据您想要做的事情的类型，嵌入宏语言的方法可能很有用。 Iron Python 很容易嵌入。 Ayende 写了一本非常有趣的书DSLs in Boo，讲述了这类事情以及更多事情。
The MEF or System.Addins routes mentioned are likely the most efficient way to go about this. I only pipe in to say a few things about the alternatives.
I have "hand rolled" this sort of solution a number of times and I would say that unless there is a compelling reason to do it from scratch it is better to use an existing addin framework. But if you are going to do so, I have found dependency injection containers like Castle or (insert your preferred DI container here) to be help handle some of the mechanics.
Also depending on exactly the sort of thing you are looking to do, the approach of embedding a macro language is potentially useful. Iron Python is easily embeddable. And Ayende wrote a very interesting book DSLs in Boo on doing this sort of thing and much more.