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

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.

This is not a hack. This is the way things are supposed to work. It's the only way you could guarantee that the types are compatible, without requiring fully dynamic types from the runtime. However, you're programming against an interface and you don't need the actual type definition, so all is not lost. Read on.

"This is the way things are supposed to work" - That's very apologistic. It's supposed to work that way because it does? No offense but types are already treated as if they were fully dynamic and assemblies contain entire type definitions including inheritance, ergo, it is EASY for the runtime to recursively evaluate the types. I could even write it myself in C#, matching up interfaces and then matching up methods from those interfaces on the classes which inherit those interfaces. I am even considering doing so, when I've got the time (which I currently do not.)

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?)

This isn't so ridiculous when you start to think what the runtime would have to do to ensure that what you want actually *works*. What if I define a completely different IPlugin in my assembly that occupies the same namespace? The runtime cannot just assume that everything is probably fine and then have the application crash on an incompatible object layout.

I don't care if the runtime thinks they're different, that's simply the progenitor of the problem, I care that the runtime won't let me cast two completely identical interfaces that only differ by assembly - they have the same methods, the same signatures, they take the same simple types - even if they used complex types the runtime could match the types, et cetera ad nauseum ad infinitum. Again, a user can write the C# code to do much the same thing, but the runtime can't? I think it should. Apparently in 3.5 there are changes to alleviate this shortcoming.

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

Well, it's not. The only issue here is that you always need to supply the bridging components in a shared assembly. Typically, that would be a GAC-installed assembly.

It certainly is. Software Engineering is a discipline of success through simplicity.

Is it simpler for developers to (a)not use a shared assembly or (b)use a shared assembly? a.
Is it simpler for developers using an assembly that defines an interface to (a)create another shared assembly in order to derive from the interface in the first assembly or to (b)not have to do that? b.
Is it (a)more or (b)less complicated for system deployment, configuration, support, migration to have more binary dependencies? a.
Is it (a)more or (b)less complicated for a build manager to support building/versining a product suite that has more projects rather than less? a.

It's pretty simple really. The issue is just with the 'degree' of inconvenience/complication involved. For a small team, it's not a big deal, for a large team it rapidly can become a big deal.

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

Am I using the wrong approach (vanilla interfaces)?

You can get around this by using COM. Make IPlugin a COM interface and put it a type library. Although all developers will need that type library to develop against, you won't need to distribute it along with the executable.

Ugh... I do appreciate the alternative angle (seriously :)), that introduces new complexities (not for me as I've actually help implement the COM/DCOM subsystem on Irix [don't ask].) At least, that's my initial reaction. I'll think on it more. VERY much appreciate the suggestion though.

However, you will need to write the interop wrapper yourself. The automatically generated interop wrappers are put in a separate assembly, which is just what you don't want.

The .NET documentation has plenty of information on COM interoperability. It works between .NET applications as well as it does between others.

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.

What you want would work in C++, because C++ doesn't do runtime checks of any kind. Even then, it would only work if the compilers produced compatible object files. If not, then prepare for crashes.

? I'm not sure what you mean, as GCC, Intel, and Microsoft's compilers all produce compatible plugins for several products in our product suite. They work just fine.

WTH

.

Relevant Pages

  • Re: C# Plugin system - same interface in two different assemblies...
    ... 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. ... So you need the following assemblies: ... Plugin types ... The host and the plugin both need to reference the common type assembly, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Add-ons
    ... Using micro core(common interfaces) and mutiple concrete implementation is ... One thing I'm not sure is how will the 3rd party ... | Our web solution consists only of strongly-named assemblies. ... For strong-reference, it will ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Add-ons
    ... Mantas Miliukas ... > statically reference your core interfaces assembly and develop their own ... > | Our web solution consists only of strongly-named assemblies. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Add-ons
    ... You're welcome Mantas, ... Microsoft Online Support ... |> statically reference your core interfaces assembly and develop their own ... |> | Our web solution consists only of strongly-named assemblies. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Best Practice: Interface definitions - where?
    ... > MS seems to like the first approach with 2 assemblies over the latter ... I guess that it is somewhat usage dependant but IMO having interfaces ... your client apps and server apps can share the same interface assembly, ... Oracle provider, the interface assembly that I have to include contains ...
    (microsoft.public.dotnet.languages.csharp)