C# Plugin system - same interface in two different assemblies...

[WTH]

I am now aware (I am primarily a C++ developer) that in C# if you reference
the same interface from the same file in two different projects the types
are actually incompatible.

I found this out because I have written a generic plugin system for my
current and future C# needs. I defined a base plugin system interface named
IPlugin (original, I know...) which contains some basic plugin infomration
all plugins of this system must expose (name, friendly name, author,
version, GUID, et cetera) and this interface is defined in the plugin
system's C# file and in its namespace (Common.Utilities.PluginSystem.) Then
I have an application, let's call it host.exe which references the plugin
system's namespace and (of course) the 'host' project references the plugin
system's file. The other project is called 'MyPlugin' and it also
references the plugin system's namespace and its project also references the
plugin system's file.

When you compile and build both projects (we haven't even defined an
interface which inherits from IPlugin yet, lol) and run the host.exe
application, the host creates an instance of the plugin manager and tells it
to load the dll produced by the MyPlugin project. No problems. The plugin
manager loads the assembly, checks to see if there are any types of the
interface type requested (host asks the plugin manager to find the interface
type 'IPlugin') and it does. It then makes sure there's a class type which
implements the same interface, and it finds that as well. So far,
everything looks good. The plugin system has found a class that implements
the 'correct' interface in the newly loaded assembly, so it creates an
instances of that type using the activator to create an instance of the type
found in the assembly which matched the criterial we specified ('a class
implementing an interface called IPlugin'.)

Here's where the problem beings. The activator succeeds and returns a type
implementing 'IPlugin' but the returned object handle cannot be case to
IPlugin in host.exe because it throws an exception stating the this is an
invalid cast. Looking at the returned object handle during debugging shows
everything I would expect, and object that implements IPlugin as I had
hoped.

After looking into this a bit I've discovered that the runtime does more
than it appears to when validating types. The assembly name is taken into
account. This means that the runtime considers the interface IPlugin, which
is of course defined in both assemblies so that each assembly can use it, to
be different in each assembly.

Apparently the 'solution' (it really seems like a hack honestly) is to put
IPlugin (and presumably the plugin manager as well while we're at it) in its
own assembly and ensure that the product/tool/whatever remembers to include
it during deployment, and ensure that every developer that wishes to write a
plugin has a copy of that assembly as well.

That's bad enough, but because this plugin system should be generic, a
developer would want to be able to define a new interface in their
tool/product/whatever that derived from IPlugin, for instance
ISuperCoolProductPlugin, and then allow some other developers (potentially
3rd party developers) to be able to create plugins of that type.

Sadly, this means YET ANOTHER assembly must be created, versioned,
supported, and deployed with the first developer's application and given to
the 3rd party to use.

Developer #1 can't put the new interface in the plugin manager's assembly
(which holds IPlugin) because it isn't his to modify, ergo, you have at
least 3 binaries to distribute to run SuperCoolProduct.exe one of which only
holds the interface ISuperCoolProductPlugin.

That seems ridiculous and very short sighted. Given the enormous
capabilities of reflection and the runtime, how come it can't map the
interfaces properly given that they have THE SAME NAMESPACE... lol. You
would think they would attribute this (or have they already?)

I'm relatively new to C# so I'm wondering if my approach to plugins is
outdated (pre 2.0) or I've missed something like generics and interface
covariance...?

This issue with types in assemblies (especially interfaces) always being
incompatible seems to be a very big issue in regards to code re-usability.

Anytime two assemblies plan to work together and reference the 'same type'
they can't.

Am I using the wrong approach (vanilla interfaces)?

WTH

P.S. BTW, please don't see this as my disrespecting C# because I'm not, it's
fantastic, but so is C++ and that hairy mother has some serious warts - C#
has a few bumps as well, lol. I really just want to write a generic,
re-usable plugin system that has as few deployment dependencies as possible.

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

WTH wrote:

I am now aware (I am primarily a C++ developer) that in C# if you
reference the same interface from the same file in two different
projects the types are actually incompatible.

<snip lengthy explanation>

You got one option: Make a separate assembly declaring the interfaces
you want to be common.

You say it looks like a hack, but .NET is about security and guarantees
in this regard, and the only way to ensure that two interfaces are the
same is to enforce that they are indeed the same. Not just that they
look the same.

So you need the following assemblies (at least):

1. Application host
2. Plugin types
3. Plugin

The host and the plugin both need to reference the common type assembly,
where your interfaces are declared.

Unless the plugin needs to talk to the plugin manager in any way (ie.
use its types), then you can put that in the host application. I'd
probably put that in the external assembly as well but at least here you
can choose.

Note that in .NET 3.5 there is a new plugin system that might define
these common interface for you. I have not looked into it yet though so
I can't really say what it would solve for you, but since Microsoft took
the effort to build a plugin system that supports discoverability,
extensibility, and err... unloadability..., then I think it might do
what you need.

If you use .NET 3.5 and Visual Studio 2008 that is.

--
Lasse Vågsæther Karlsen
mailto:la***@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3

[WTH]

"Lasse Vågsæther Karlsen" <la***@vkarlsen.nowrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

WTH wrote:

>I am now aware (I am primarily a C++ developer) that in C# if you
reference the same interface from the same file in two different projects
the types are actually incompatible.

<snip lengthy explanation>

You got one option: Make a separate assembly declaring the interfaces you
want to be common.

My post mentions this method.

You say it looks like a hack, but .NET is about security and guarantees in
this regard, and the only way to ensure that two interfaces are the same
is to enforce that they are indeed the same. Not just that they look the
same.

That's not even true for classes much less interfaces. You can match up,
byte for byte types in IL. C# just doesn't appear to let you do this. This
is why I'm looking for alternatives (especially given that I don't know as
much about C# as I should.)

So you need the following assemblies (at least):

1. Application host
2. Plugin types
3. Plugin

The host and the plugin both need to reference the common type assembly,
where your interfaces are declared.

You didn't bother to read my post obviously. I have already explained that
this is the problem, having to do it this way. It works programmatically,
but it results in a poor software engineering implementation. I am
currently using this method.

Unless the plugin needs to talk to the plugin manager in any way (ie. use
its types), then you can put that in the host application. I'd probably
put that in the external assembly as well but at least here you can
choose.

I've written quite a few plugin systems and it will be a great value going
forward for the plugin system to reside in the assembly that 3rd party devs
will use (especially given that quite often 3rd party developers want their
plugins to be able to communicate to each other via the 'framework' of the
plugin system.)

Note that in .NET 3.5 there is a new plugin system that might define these
common interface for you. I have not looked into it yet though so I can't
really say what it would solve for you, but since Microsoft took the
effort to build a plugin system that supports discoverability,
extensibility, and err... unloadability..., then I think it might do what
you need.

If you use .NET 3.5 and Visual Studio 2008 that is.

A new plugin system? Do you mean a new assembly loading/unloading
mechanism? Interesting. Thanks for the tip.

WTH

[Jon Skeet [C# MVP]]

On Jan 17, 4:26 pm, "WTH" <[e-mail]:

<snip>

Is it simpler for developers to (a)not use a shared assembly or (b)use a
shared assembly? a.

Look at it a different way:

Is it simpler for developers to (a) duplicate code or (b) not
duplicate code? b.

Using a common assembly avoids code duplication.

Jon

[Jon Skeet [C# MVP]]

On Jan 17, 3:49 pm, Lasse Vågsæther Karlsen <[e-mail]:

<snip>

So you need the following assemblies (at least):

1. Application host
2. Plugin types
3. Plugin

Not necessarily. The plugin types can be within the application host
assembly, which the plugin then references. This works fine, and I've
done it many times.

Jon

[Jon Skeet [C# MVP]]

WTH <wt*@nospam.comwrote:

All of those situations mean you've got the code in two places. That
doesn't sound like good practice to me.

? Do you mean it's defined twice?

Yes - the source code for the interface is present twice.

But that's the whole point.

That's duplication, which it's good practice to avoid.

Define it
where and when you need it, don't force people to have it defined all the
time like you would if they have to include an assembly to get one interface
and that assembly contains 30 other interface definitions. The code is
still there. If you simply put one interface per assembly you're only
including in the developers code once but then they have to have all the
assemblies which they 'may' use...

No, they only have to reference the assemblies they *do* use.

No need. Just put each plugin in its host's assembly, and reference
that. If you have many plugins, you have complexity whatever you do.
Duplicating source code just makes that worse, rather than better.

What on earth are you talking about? Put each plugin in its hosts assembly?
Did you mean interface?

Yes, I meant the interface.

If you meant interface, that's a very strange way
to deploy and SDK. What if you're application/host requires licensing?
What if it has a complicated configuration? Serious deployment
dependencies?

Who said anything about configuring it or installing it? You don't need
to do either of those things just to *reference* it.

Of course, if it becomes a problem for any reason, you can separate out
the interface into its own assembly - no problem.

<snip>

But code duplication is A-OK by you is it? Sorry, I really don't buy
it.

You mean multiple definitions of the interface? Do you not realize that
this happens no matter what method you choose? Are you worried about typos
or something? lol.
When somebody re-uses a class that someone else wrote, do you consider that
code duplication and you don't "buy it"?

No, I don't consider that code duplication. The source code only lives
in one place. Changes to it only have to occur in one place, then get
deployed everywhere it's used. I consider that better than having the
source code everywhere that the interface would be used. I'm rather
glad I don't have to include the interface code for IDisposable,
IEnumerable<T>, IList<Tetc in every project which uses them.

The latter is *much* better IMO.

Well, in my experience in supporting the exact scenarios I have described,
it is far easier to develop, support, and extend via the former.

Your experience which is limited in C#, by your own admission.

I'm afraid I see having to duplicate source code as a much bigger wart
than compiling against a fixed binary.

You seem to have latched onto this as your only reasoning as to why C#
cannot discern that two interfaces are identical.

Nope - it's just *one* good reason. It's a good enough one for me.
Various other reasons are also available, but I only need the one.

I'd hate to think of how
you share code with others, presumably you just send them an assembly and if
there's a problem with it, they have to ask you to fix it and ship them a
new assembly.

I suspect that most people who use my open source library only want or
need the DLL. Those who want to change the source can do so - but I'd
expect they'd usually still build to a DLL and reference that.
Assemblies are the units of code reference in .NET - not source code.

Hopefully you're sitting around with nothing to do when this
happens. Here we can't do that. If there's a bug in an SDK client helper
class, the sdk developer can modify it because he has the file, not the
assembly. He doesn't have to wait for a new version of the SDK to come out
in 6 months to a year.

No, but he then has to patch it every time there's a new release of the
SDK. Meanwhile, he may have introduced other bugs. The whole thing's a
versioning nightmare.

I don't expect to convince you, to be honest.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Jesse McGrew]

On Jan 17, 3:10 pm, "WTH" <[e-mail]:

"Jon Skeet [C# MVP]" <[e-mail] in messagenews:MP********************@msnews.microsof t.com...

[...]

No need. Just put each plugin in its host's assembly, and reference
that. If you have many plugins, you have complexity whatever you do.
Duplicating source code just makes that worse, rather than better.

What on earth are you talking about? Put each plugin in its hosts assembly?
Did you mean interface? If you meant interface, that's a very strange way
to deploy and SDK. What if you're application/host requires licensing?
What if it has a complicated configuration? Serious deployment
dependencies? Et cetera.

Er... how is the plugin developer going to *test* his plugin if he
doesn't have the host application installed? I would think that
licensing, configuration, and deployment are issues that you need to
solve anyway, if you want to actually write a plugin that works.

Jesse

[WTH]

No need. Just put each plugin in its host's assembly, and reference

that. If you have many plugins, you have complexity whatever you do.
Duplicating source code just makes that worse, rather than better.

What on earth are you talking about? Put each plugin in its hosts
assembly?
Did you mean interface? If you meant interface, that's a very strange
way
to deploy and SDK. What if you're application/host requires licensing?
What if it has a complicated configuration? Serious deployment
dependencies? Et cetera.

Er... how is the plugin developer going to *test* his plugin if he
doesn't have the host application installed? I would think that
licensing, configuration, and deployment are issues that you need to
solve anyway, if you want to actually write a plugin that works.

Generally speaking you have a test harness. You write one to help offload
work from the always understaffed and overwrought QA team to developers who
can use it to run regression tests. Now, you don't need a test harness, I'm
just prone to making QA happy, and most enterprise products are distributed.
For example, I wouldn't install the middleware layer on my development box
so I could build a plugin for it. I'd build a plugin for it, and install it
on one of the development installations (we have several and QA has dozens.)
Personally, I do the test harness method when I can.

WTH