What are you doing is a very bad way of getting the code out of an assembly using Reflection. It is based on the string, which you could misspell; or the profile of the method could be different, of something else. Even one of the methods
InvokeMembers
is not a best invocation technique, by far. In all cases, the compiler won't be able to detect a problem if you do something wrong.
Why doing all that, if a perfect technique exists? If you do it right, a compiler won't allow you to make a wrong invocation or a wrong call. The good technique is the best for maintenance.
You should do it based on interfaces. First, you should create some plug-in interface or a set of interfaces. You can define the interface in a separate assembly referenced by both host application and all valid plug-ins. You can also simply put it in the host assembly, but then you will need to reference you host assembly by the plug-in. Don't: worry: this is not a circular reference, because host assembly does not reference plug-ins, the dependency is created only during run time. So, this is perfectly legitimate technique which works.
Now, you expect the interface to be implemented by one of the classes of the loaded assembly. You can find out if some class implements your interface using
GetInterface
or
GetInterfaces
method to get implemented interfaces and compare it with the type of the interface you expect. Note that the name of interface type does not have to be involved, and even if you use it, you calculate it out of interface type, never hard-code (as you did in your code sample), which is critically important.
By the way, the type does not have to be public. More over, keep it
internal
. In this way, Reflection can access it, but direct referencing — not. Unless you need it, too, of cause.
On next step, you find out a constructor of expected signature and invoke it using
System.Type.GetConstructors
and invoke it using one of
System.Reflection.ConstructorInfo.Invoke
methods.
Finally, you cast the obtained class instance to the required interface. You can safely do it, as you already checked up that this interface is implemented by your type.
You are done! You got the interface referenced which is guaranteed to be valid and work. As you are calling interface methods only, they cannot be wrong or having wrong signature.
Please see:
http://msdn.microsoft.com/en-us/library/system.type.aspx[
^],
http://msdn.microsoft.com/en-us/library/system.reflection.constructorinfo.invoke.aspx[
^].
I use a bit more advanced method. The problem that in the previous steps, you have to scan all type. This is not so good. I add a special assembly-level attribute which tells me what types should be examined by the host as those implementing some interface. The host code gets this type (or types) from the attribute object and examine it (them) only.
I described this and other technique in my past answers:
Create WPF Application that uses Reloadable Plugins...[
^],
AppDomain refuses to load an assembly[
^],
code generating using CodeDom[
^].
See also my other solutions on related questions:
Create WPF Application that uses Reloadable Plugins...[
^],
Dynamically Load User Controls[
^].
—SA