Dynamically Load User Controls

Question

4.00/5 (1 vote)

See more:

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?

VB

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)

Posted 22-Jun-11 12:02pm

creizlein

Updated 22-Jun-11 12:03pm

v2

Add a Solution

1 solution

Add a Solution

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

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-06-22T13:16:00

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

Dynamically Load User Controls

1 solution

Solution 1

Add your solution here

Preview 0

Dynamically Load User Controls

1 solution

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us