动态加载用户控件 [英] Dynamically Load User Controls

问题描述

我正在尝试开发一个面向插件的应用程序，我基本上希望第三方开发人员向我发送一个DLL，而我的应用程序将在DLL的新tabPage的tabContainer中加载该DLL所具有的用户控件.

基本上，我扫描工作目录中的DLL，并为每个目录创建一个新的tabPage，然后向其中添加该DLL的用户控件.

不仅仅是一个特定的问题，这还是关于如何对其进行归档的快速指南，摒弃了可能存在的安全问题(我知道这些问题)，但是我确定我怎么知道用户名是什么控件，或者我如何访问控件可能公开的基本属性，例如名称"或作者"，控件是否需要实现任何接口或标准属性?如果可以，我如何检查其是否有效?

到目前为止，例如，我有以下代码，但是对于特定的Type是硬编码"的，我需要更通用的东西.有什么好的方法呢?

I''m trying to approach to a plugin oriented application where i basically want 3rd party developers send me a DLL and my application will load the user control that DLL has in a new tabPage of a tabContainer.

Basically, i scan the working directory for DLL''s and for each one i create a new tabPage and i want to add the user control of that dll to it.

More than a specific question this is a quick guidance on how to archive this, discarding the security issues this may have (I''m aware of these) but I''m sure how do i know what could be the name of the user control or how i can access basic properties that the control may expose, like "name" or "author", is there any interface or standard properties the control has to implement? and if so, how do i check if its valid?

so far, for example, i have the following code, but it''s "hard coded" for the specific Type, i need something more generic... what is a good approach to this?

Dim a As System.Reflection.Assembly = System.Reflection.Assembly.LoadFrom(.\mycontrol.dll)
Dim t As Type = a.GetType("UserControl.Control1")
Dim c As Control = CType(Activator.CreateInstance(t), Control)
tc.TabPages.Add("Name of the Plugin")
tc.TabPages(tc.TabPages.Count - 1).Controls.Add(c)

推荐答案

好吧，这是一个非常糟糕的策略-按名称查找任何类型或成员.您永远不需要它来实现插件.

请执行以下操作:

1)创建一个插件接口，供主机项目和插件项目引用.

2)使所有属性成为您接口的一部分，或者仅使用装配体属性.您可以开发专用的版本控制系统和版本兼容性规则.主机和插件实现都可以执行检查.

3)在某些插件类中实现此接口.这样，您无需按名称搜索任何内容；查看所有类并选择一个实现该接口的类；如果有一个以上的类，那么做一下-例如，对它进行一些处理，只使用找到的第一个，但发出警告.

4)进一步.为什么要搜索所有类(甚至所有公共类都没有关系)?使它更有效.使用目标程序集"创建一些属性以声明实现某些插件接口的类，该参数可以是System.Type或两个参数System.Type —一个参数声明该插件接口程序集中实现了某种类型的(因此您可以使用多个接口类型)，第二个参数将声明实现此接口的类/结构.如果实时执行反射，您会发现不匹配-抛出异常或类似的东西.

请参阅我过去描述插件体系结构的解决方案:
创建使用可重载插件的WPF应用程序... [ ^ ]，
AppDomain拒绝加载程序集 [
有什么问题吗?

祝你好运，

—SA

Well, a very bad strategy — to find any type or member by name. You never need it to implement plug-ins.

Do the following:

1) Create a plug-in interface, reference it by both host-and plug-in projects.

2) Make all attribute you need either a part of your interface or just use assembly attributes. You can develop a dedicated versioning system and the rules for version compatibility. Both host and plug-in implementation can perform the check-up.

3) Implement this interface in some plug-in class. In this way, you don''t need to search anything by name; look at all classes and pick one which implements the interface; if more then one classes do — do something about it, for example, use just first one you found but issue warning.

4) Make a step further. Why searching through all classes (even all public, does not matter)? Make it more effective. Create some attribute with the target "assembly" to claim the class(es) implementing certain plug-in interface(s), the parameter could be System.Type or two parameters of System.Type — one parameter claims that the plug-in interface of certain type is implemented in the assembly (so you may use more than one interface type), second parameter will claim the class/structure implementing this interface. If in real time doing Reflection you will find mismatch — throw exception or something like that.

See my past solutions describing plug-in architecture:
Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^].

Some part of these solution can be too complex for your purposes. You may want to ignore the requirement for the plug-ins to be reloadable and hence working with additional Application Domain — this is the most difficult part. If you need "just plug-ins", not reloadable, it''s nearly as simple as what you already done.

Any questions?

Good luck,

—SA

这篇关于动态加载用户控件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！