I could use a little advice to help prevent me making a possible mess of a
project.

In VB6, I once created a project that exposed a public interface class. I
then Implemented this in various plug-in DLLs so that I could early-bind to
the plug-ins by declaring objects of the interface class type.

This worked fine, until one day I found that I needed to add a new method to
the interface class. Of course, everything broke immediately after I had
done this as adding a new method changed my class's interface. All the
plug-ins that implemented the old interface no longer recognised the new one
and I made a big mess that took a lot of time to clear up.

This was all based around COM and CLSIDs, neither of which are relevant in
VB.NET. Will I have similar problems if I try to change an interface class
in a VB.NET project (assuming that I get the plug-ins to bind to the new
version and not the old)?

In addition to this, I've also been trying to achieve the same objective
with inheritance in VB.NET. I have a base class that has a variety of
functions that are declared either Overridable (where the function has a
default implementation in the base class) or MustOverride (where the derived
class has to implement its own functionality). I then get my plug-ins to
inherit this class. Code that uses the plug-ins can early bind by declaring
objects of the base class type.

My assumption is that I can then add new methods to the base class,
providing I make them Overridable instead of MustOverride, and the derived
classes will continue to function when bound to this modified version of the
class. Any calls to the new functions that are unrecognised by the plug-ins
will fall through to the base class implementation. Am I correct here, and
are there are problems that I may encounter by doing this?

My thanks in advance,

--

(O) e n o n e

I think the generally accepted method of creating new interfaces without
breaking existing ones is to create an entirely new interface that derives
from the existing one. Say instead of PlugMeIn_Interface, derive a new one
called PlugMeIn_Interface2, deriving from PlugMeIn_Interface. Now, you add
the new methods to the new interfaces without changing the way the old
interface works. Any new plug-ins you make will utilise the new interface,
but old ones obviously cannot (because they don't know about it).


"Oenone" <(E-Mail Removed)> wrote in message
news:mNZ3e.8839$(E-Mail Removed)...
>I could use a little advice to help prevent me making a possible mess of a
> project.
>
> In VB6, I once created a project that exposed a public interface class. I
> then Implemented this in various plug-in DLLs so that I could early-bind
> to
> the plug-ins by declaring objects of the interface class type.
>
> This worked fine, until one day I found that I needed to add a new method
> to
> the interface class. Of course, everything broke immediately after I had
> done this as adding a new method changed my class's interface. All the
> plug-ins that implemented the old interface no longer recognised the new
> one
> and I made a big mess that took a lot of time to clear up.
>
> This was all based around COM and CLSIDs, neither of which are relevant in
> VB.NET. Will I have similar problems if I try to change an interface class
> in a VB.NET project (assuming that I get the plug-ins to bind to the new
> version and not the old)?
>
> In addition to this, I've also been trying to achieve the same objective
> with inheritance in VB.NET. I have a base class that has a variety of
> functions that are declared either Overridable (where the function has a
> default implementation in the base class) or MustOverride (where the
> derived
> class has to implement its own functionality). I then get my plug-ins to
> inherit this class. Code that uses the plug-ins can early bind by
> declaring
> objects of the base class type.
>
> My assumption is that I can then add new methods to the base class,
> providing I make them Overridable instead of MustOverride, and the derived
> classes will continue to function when bound to this modified version of
> the
> class. Any calls to the new functions that are unrecognised by the
> plug-ins
> will fall through to the base class implementation. Am I correct here, and
> are there are problems that I may encounter by doing this?
>
> My thanks in advance,
>
> --
>
> (O) e n o n e
>
>

Robin Tucker wrote:
> I think the generally accepted method of creating new interfaces
> without breaking existing ones is to create an entirely new interface
> that derives from the existing one.

Hi Robin,

Thanks for your reply. That was the conclusion we came to too in the end
(back in VB6), but we decided it was more trouble than it was worth in the
end and just late-bound to the components.

Do you (or anyone else) have any comments on the inheritance method I
described? This it the one I really want to go with in VB.NET but I'm not
quite at the point of being able to test it yet...

Thanks,

--

(O)enone