Vb.net, external dynamic dlls, and calling their respective functions

Question

1.44/5 (2 votes)

See more:

Hey all,

Seems there is a lot of info on this topic but none that actually solve my problem. I am writing a plugin based program with external dlls. My program loads the dlls dynamically (loading from a specific directory) and I do not know what they are prior to compiling.

I need to be able to call a function from that dll. I can specify the name of the function for each plugin (aka, GetInfo or whatever) but I am not sure how to create an instance of the function in the plugin.

Here is what I have so far.

VB

For Each dll In dlls
           Try
               extAssembly = System.Reflection.Assembly.LoadFrom(dll.FullName)
               extForms(index) = extAssembly.CreateInstance("myPlugin.frmMain", True)

           Catch ex As Exception
           End Try
       Next

And then later I can do a simple...

VB

extForms(index).Showdialog()

But how do I create an object that I can link to a specific function either in my form or a separate class dynamically?

Thanks! :)

Posted 1-Jun-11 8:19am

JBenhart

Add a Solution

2 solutions

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 · Answer 1 · 2011-06-01T11:13:00

Solution 2

OK, I've done this in different variants. Please see my sketch of design here:

Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^].

Correct way of recognition of plug-ins is by some plug-in interface. Doing it by name is absolutely unsupportable.

—SA

Posted 1-Jun-11 11:13am

Sergey Alexandrovich Kryukov

Comments

Espen Harlinn 1-Jun-11 18:34pm

Good point, my 5

Sergey Alexandrovich Kryukov 1-Jun-11 18:42pm

Thank you, Espen.
--SA

JBenhart · Answer 2 · 2011-06-01T09:24:00

Solution 1

Ok, I was able to find and call a function. Question. Is there a way to directly invoke my function "Test" instead of For Each'ing through the entire dll?

VB

Dim assem As System.Reflection.Assembly =System.Reflection.Assembly.LoadFrom(&quot;myplugin.dll&quot;)
Dim ty As Type = assem.GetType(&quot;myPlugin.frmMain&quot;)
Dim class1 As Object = Activator.CreateInstance(ty)
Dim strMsg As String
Dim myMember() As System.Reflection.MethodInfo = class1.GetType.GetMethods()
For Each member As System.Reflection.MethodInfo In myMember
     If member.Name = "Test" Then
          strMsg = member.Invoke(Nothing, Nothing, Nothing, Nothing, Nothing)
          Exit For
     End If
Next

Posted 1-Jun-11 9:24am

JBenhart

Comments

Dave Kreskowiak 1-Jun-11 16:45pm

Yeah, instead of calling GetMethods, use GetMethod("name") instead.

Sergey Alexandrovich Kryukov 1-Jun-11 17:14pm

No! Don't use GetMethod by name, never! The supportable way is through interface (known by both host and plug-in).

See my solution.
--SA

Dave Kreskowiak 1-Jun-11 18:07pm

I know an Interface would be prefferable. This is just the simple replacement for his code instead of going back and recoding everything to support an interface.

Sergey Alexandrovich Kryukov 1-Jun-11 20:18pm

Sure, I understand that. I just don't want to mislead OP.
--SA

JBenhart 1-Jun-11 17:42pm

Hey SA, is there a reason to not use Dave's method? It does work. I looked over your solutions and unfortunately, once again, they are over my head. I don't understand interfaces and assemblies, etc. If I create a plugin architecture that has a basic form to load and a few methods to return data, can you tell me the drawbacks?

My plugin is a simple form. It creates an assembly of the form and then does a showdialog() on run. I just need a title, description, and bitmap from the dll.

Lastly, if you could elaborate with specific code examples, that may help. :)

Thanks to both of you! :)

Sergey Alexandrovich Kryukov 1-Jun-11 20:22pm

Sorry. The solution based on naming is not acceptable. I don't know what's over my head. It's only a bit more compared to what you already use. You use "GetInterfaces", check is the class implements your interface or not. Additionally, it's good to have an assembly attribute that simply says: "Look at this class for the plug-in implementation", to cut on looking through all classes in the assembly. Nothing is too complex.

What is complex is re-loadable and using AppDomain. But plug-ins do not have to do that unless you need them re-loadable -- that is much more difficult.
--SA

Sergey Alexandrovich Kryukov 1-Jun-11 20:24pm

You really need interface-based plug-ins. If you do not understand how to do it, I'll explain more.
--SA

JBenhart 2-Jun-11 16:26pm

Please explain more. :)

JBenhart 2-Jun-11 16:35pm

Ah, this helped a lot.
http://msdn.microsoft.com/en-us/library/cd43d244%28v=vs.71%29.aspx

I am still confused why the prior solution (easy to refine my code) is a negative thing. Is it for security purposes or better control of code (thus less chance of breaking with rouge plugin.) If I need to redesign my plugin architecture that is fine, but I would prefer to know specifically why. :)

Vb.net, external dynamic dlls, and calling their respective functions

2 solutions

Solution 2

Solution 1

Add your solution here

Preview 0

Vb.net, external dynamic dlls, and calling their respective functions

2 solutions

Solution 2

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us