Pulling my hair out, I need some help

[John Wright]

I am trying to come up with an architecture to support snap-in/extensibility.
I have a host program that uses common functions for all the plug ins. I
understand I would need an interface (iPlugin or something similiar) that all
DLL need to inherit to use. What I need is a good example. I need to load
usercontrols into this program and show them and interact with them and allow
the usercontrols to call the hosted functions as well as there own. I have
looked at the System.Addin, but this is much to convoluted for what I need, I
have looked at reflection with little success and Managed Extensibility
Framework. All of this just seems so complex. Is there anyone that can
point me to a good VB example of a host program dynamically loading
components (both visual and non-visual applications)? Thanks.

John

 

[Jack Jackson]

On Mon, 23 Mar 2009 15:30:13 -0700, John Wright <John

I am trying to come up with an architecture to support snap-in/extensibility.
I have a host program that uses common functions for all the plug ins. I
understand I would need an interface (iPlugin or something similiar) that all
DLL need to inherit to use. What I need is a good example. I need to load
usercontrols into this program and show them and interact with them and allow
the usercontrols to call the hosted functions as well as there own. I have
looked at the System.Addin, but this is much to convoluted for what I need, I
have looked at reflection with little success and Managed Extensibility
Framework. All of this just seems so complex. Is there anyone that can
point me to a good VB example of a host program dynamically loading
components (both visual and non-visual applications)? Thanks.

John

You will need two interfaces, one implemented (not inherited) by the
plug-in classes, and the other implemented by your hosting class.

Here is a very simple example:

Public Interface IMyPlugin
Sub Initialize(host As IMyHost)
End Interface

Public Interface IMyHost
Function GetStatus() As String
End Interface


To create a plug-in, build a project that derives from UserControl.
Add:
Implements IMyPlugin

and add a method like:

Private m_host As IMyHost = Nothing

Private Sub PluginInitialize(host As IMyHost)
m_host = host
End Sub

After this method gets called, you can access methods and properties
in the host via m_host:

status = m_host.GetStatus()


In the host you need to implement the IMyHost interface. You could do
this either in the form class, or in a special class you build just
for this purpose.

To instantiate a plug-in, given the name of its DLL, you can either
force the plug-ins to all have a class with a known name, or you can
use reflection to look through the classes in the DLL and find the one
marked with an Attribute that you define.

Dim assem as System.Reflection.Assembly
Dim obj As Object
Dim plugin As IMyPlugin

assem = System.Reflection.Assembly.LoadFrom(pluginname + ".dll")
obj = assem.CreateInstance("classname")

plugin = TryCast(obj, IMyPlugin)
If plugin Is Nothing Then
' Class does not implement IMyPlugin
Else
plugin.Initialize(host)
' If the plug-in is visual,
' you need to add it to some visual container
Me.Controls.Add(plugin)
...
End If

 

[Michael Cole]

<

OK. Take a firm grasp of a small quantity of your hair low down on the
shaft towards the scalp, and then give a sharp tug...

Oh, you don't actually want help with pulling your hair out. Perhaps a more
informative subject line would have been better...

 

[Michel Posseth [MCP]]

Hello Jack

Just curious , why not "inherited" , after a few weeks of coding with my
interface i had the lightbulb moment of creating a base class
wich implemented my interface , it works since early 2005 flawless on my
production systems .

by the way i created a multithreaded queued windows service for my company
wich is capable of starting anny assembly as long as it has my interface
or base class implemented or inherited in the invoker class .

But after your comment i am curious if i missed something with the
inheritance thingy

regards

Michel

 

[Cor Ligthert[MVP]]

Right

 

[Cor Ligthert[MVP]]

Michel,

I don't know how it is in other natural languages then ours, interfaces
sounds in my idea often a little bit mystic (and it is)

While it is a contract to make it easily possible to use different classes
which are made by independend people in the same way. Is it often used in my
idea for things which are simple to make those difficult. This is certainly
not a rule forever, however in my idea are there persons who first look how
you can use an interface and then start programming, in my idea it should be
the other way around.

jmo

Cor

 

[Jack Jackson]

The reason I said not Inherited was that the OP said "an Interface
that all DLL need to inherit to use". If an Interface is to be used,
then it is Implement not Inherit.

Rather than use an Interface, a base class that the plug-ins would
inherit from could be used. When you do that you are limiting how the
plug-ins can be built, which might be either a good thing or a bad
thing depending on your circumstances.

Inheritance also makes it less clear to developers what the contract
is that the plug-in must meet. With an Interface, it is clear that
you must provide the methods and properties of the Interface. With
Inheritance, it is less clear which methods and properties of the
class are required. On the other side, Inheritance allows you to
supply default behavior for methods.

There are advantages to both methods. I was not advocating one
approach over the other.

For access to the host from the plug-in, it is much clearer to me that
an Interface is the only way to go. If you give the users your whole
form class so they can call methods, you are not only giving them
source code you might not want them to have, but you are making it
much more likely there will be a breaking change in the future.

 

[Michel Posseth [MCP]]

Hello Jack

Thank you for your clear response , as i said my reasson to switch to a
base class was just that i noticed that a base class saved me more typing
as using the interface , to the other programmers in my company i made both
availlable so they can choose wich one they prefer .

Inheritance also makes it less clear to developers what the contract
is that the plug-in must meet. With an Interface, it is clear that
you must provide the methods and properties of the Interface. With
Inheritance, it is less clear which methods and properties of the
class are required. On the other side, Inheritance allows you to
supply default behavior for methods.

I have actually never thought about that fact , but indeed you are right as
the interface is encapsulated by the base class you must know it is there ,
it doesn`t force you to actually override the methods , so you can end up
with a partiall implementation ( empty methods ) without noticing this.

There are advantages to both methods. I was not advocating one
approach over the other.

And i was just curious what your motivation was

For access to the host from the plug-in, it is much clearer to me that
an Interface is the only way to go. If you give the users your whole
form class so they can call methods, you are not only giving them
source code you might not want them to have, but you are making it
much more likely there will be a breaking change in the future.

True , well you have given me something to think about

Thank you verry much

Michel Posseth

 

[Michel Posseth [MCP]]

Cor,

I mostly use interfaces to provide an invocation interface to mimic the
behavior of good old late binding through reflection
but indeed there are people who create an interface for every class they
made mostly this are the wannabe VISIO pilot programmers

Michel