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

"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message news:MPG.21f9b7c6d11199b7c1@xxxxxxxxxxxxxxxxxxxxxxx
WTH <wth@xxxxxxxxxx> wrote:
>> 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.

What duplication are you referring to? A developer cutting and pasting an
interface from your SDK documentation? A developer using a skeleton plugin
project you've made available? Worst case, a user typing out the interface
definition?

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? But that's the whole point. 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...

It is always important to think of engineering choices in the simple,
moderate, and complex usage choices, not just the simple.

Imagine that you've got a team of 20 developers developing a large networked
product suite (as I recently did) and they are broken up into basically 3
groups, each group with many subcomponents (services, client applications,
tools, open integration points - i.e. plugin options, for each group), each
of these groups wants to use a common plugin system for all the basic
engineering reasons (testing/debugging/extending all simpler.) Suddenly you
find yourself with DOZENS of assemblies that simply exist to hold interface
definitions so that people can write plugins for the different parts of the
product. You can't put them all in one big interface assembly because then
whenever you add a new interface your QA team must run regression tests on
the entire product suite and their plugins.

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. You're now forcing a plugin developer to install each application component (a service for example) which has a plugin capability on his development box. Simultaneously, you have then forced each application component to have its own access to the base plugin interface assembly, ergo, if you don't plan to force the plugin developer to install absolutely every component on his/her box in order to simply build a plugin, you have to include the binary as a dependency with each component you offer as available for individual installation.

It's totally unwieldy in the case above, and an all or nothing approach. I can see how in some cases that can be fine, and there are cases where I wouldn't care about this, but there are lots of cases where it makes things worse than if you didn't have to do it.

You also can't do it because if
you update a deployment or migration in the field you're potentially
affecting the entire product suite instead of just the component which has
changed. There's a bunch of reasons why using a single assembly for
anything shared in commonality between assemblies is a poor idea instead of
there being a method of equanimity.

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

I personally find it much more attractive to simply tell somebody working at
corporate research in Princeton "The interface is published in the SDK
documentation you can reach online" rather than "you need to download this
assembly, reference it, and make sure it's in your path, oh, and if you want
to use that other interface, download this other assembly, reference it, and
make sure it's in your path... Et cetera."

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.

Now, the 20 developer example I give is a complex usage example, but it is a
very real example for me.

Again, I'm not bagging on C#, this is just something I have strong
engineering reasons to see as a 'wart.' All languages have them, especially
C++ (which is my primary background.)

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. 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. 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.

WTH

.

Relevant Pages

  • Re: C# Plugin system - same interface in two different assemblies...
    ... "add a reference to the appropriate assemblies to each and every project"? ... You don't have each plugin project deciding what ... its idea of the interface is. ... can't by forcing people to include them in assemblies as I've explained. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: C# Plugin system - same interface in two different assemblies...
    ... That's duplication, which it's good practice to avoid. ... At least by letting the developer define the interface you can accomplish things you can't by forcing people to include them in assemblies as I've explained. ...
    (microsoft.public.dotnet.languages.csharp)
  • C# Plugin system - same interface in two different assemblies...
    ... I am now aware 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. ... 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. ... 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. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Plugin Architecture Problem
    ... You can define the interface in a single assembly but you need to manage how ... they are housed in different assemblies. ... > I'm trying to implement a Plugin architecture where I have a single UI ... > CreatePluginInstance - when I cast to the plugin interface type. ...
    (microsoft.public.dotnet.framework)
  • Re: OOP design question
    ... class that implements an interface -- there's no way to 'plug-in' a base ... class without having a proxy to delegate to the plugin, ... > some way of for plug-in assemblies to register themselves with it. ... it is passed to the FileExporterManager object. ...
    (microsoft.public.dotnet.languages.csharp)