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

"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message news:4e813bce-3f03-4d10-92f8-5d58c184a5df@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 17, 4:26 pm, "WTH" <w...@xxxxxxxxxx> wrote:

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

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?

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

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

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

WTH

.

Relevant Pages

  • 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)
  • Re: C# Plugin system - same interface in two different assemblies...
    ... A developer using a skeleton plugin ... a user typing out the interface ... 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... ...
    (microsoft.public.dotnet.languages.csharp)
  • 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: Using .NET Component from COM Object
    ... Mike ... > interface that is used to sink the events into. ... > component it is effective hidden code, which is always very hard to debug. ... >>> name your assemblies if you're going to do COM. ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Interesting file managment feature of VS2005
    ... used amongst those assemblies. ... > to 'share' common business objects (ex. ... > PDC-2005 who basically told me sharing files in multiple projects wasn't ... > copying lead to more bugs (especially in a multiple developer environment) ...
    (microsoft.public.dotnet.languages.csharp)
Loading