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

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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