Re: Pulling my hair out, I need some help

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

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.

On Tue, 24 Mar 2009 07:28:00 +0100, "Michel Posseth [MCP]"
<MSDN@xxxxxxxxxxx> wrote:

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

"Jack Jackson" <jjackson-nsp@xxxxxxxxxxxxxxxx> schreef in bericht
news:8h4gs4tqs693u437pgjbnm6rv2oui4d5lr@xxxxxxxxxx
On Mon, 23 Mar 2009 15:30:13 -0700, John Wright <John
Wright@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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

.

Relevant Pages

  • Re: Interface question
    ... This is the beauty of interfaces: you don't inherit from something ... interface, and make all of the classes implement it. ... ListViewModel, which is the brains behind managing item selection, ... to make another control that could interact with any control that was ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Plugin Enabled Applications
    ... > I want to include plug-in support into my application. ... http://jvcl.sourceforge.net/ has plugin stuff as well ... e.g. DLL has to export a function of name GetPlugin that ... returns an interface reference of type IPLugin. ...
    (borland.public.delphi.language.objectpascal)
  • Re: Interface question
    ... The interface it uses is IAnimal. ... in C# a class can only directly inherit one other class. ... Not all animals do make sounds, and so by doing it this way, all animals would have a common shared base class "Animal" that really is universal to all animals, while those that can intentionally make sounds would _implement_ the "IVocalize" interface themselves in whatever way was appropriate to that particular animal. ... it essentially enters into a contract with any code that might use an instance of a Student that it will implement the methods in those interfaces: ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why Java interface?
    ... In C++, there are multiple inheritances; but in Java, a class can ... inherit only one super class. ... interface is ...
    (comp.lang.java.programmer)
  • Re: Request all implementors of an interface
    ... > Basically what I want to do is create a top level shell that can query dlls ... > in its directory for a certain interface. ... > plug-in. ... Use one of the forms of Assembly.Load* to load the DLL, ...
    (microsoft.public.dotnet.framework)