First an example:

"ClassA" is defined in A.dll
public class ClassA
{...}

"ClassB" is derived from "ClassA" and has a reference to A.dll, and all of
this is defined in B.dll
public class ClassB: ClassA
{...}

"ClassC" is derived from "ClassC" and has a reference to B.dll, and all of
this is defined in C.dll
public class ClassC: ClassB
{...}
ERROR!! --- I need to also include a reference to A.dll !!!

Now when I create "ClassC" and it is derived from "ClassB", why do I also
need to include a reference to "ClassA"?

I'm I doing something wrong...shouldn't B.dll have everything that "it"
needs in order to run?
Why does every app/dll need to include ALL references that the other dlls
(assemblies) are using??

In a very large system with about 40 developers it makes it impossible to
efficiently reuse other classes that are defined in other assemblies.

Can someone please give me some helpful directions?

Thanks

Adding a reference never directly imports the IL; so just because B has a
class that inherits from A in A.dll, it doesn't have the actual
implementation. Indeed, post-implementation you can update A.dll and your
app will pick up the changes without needing a rebuild (versioning
permitting).

So: to instantiate a "B", it needs the base-class implementation (for the
fields etc), so it needs A.dll; and to instantiate a C it needs A.dll and
B.dll.

Re your 40-devs issue I'm nto sure that this directly is the problem; it
sounds like you've got a hugely fragmented assembly base, which is going to
be a nightmare any way you manage it. I'd stick with a small number of
utility libraries, and a few project-specific assemblies... I wouldn't worry
about not using "all" of an assembly... the JIT means that anything surplus
that you never use in your app is largely just fluff and ignored...

Marc

"Marc Gravell" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Adding a reference never directly imports the IL; so just because B has a
> class that inherits from A in A.dll, it doesn't have the actual
> implementation. Indeed, post-implementation you can update A.dll and your
> app will pick up the changes without needing a rebuild (versioning
> permitting).
>
I wouldn't expect it to import it, but at least know where to get it i.e.
assembly.namespace.class...

I just expected it to work like a regular C++ dll, where each DLL is
self-suffient.

> So: to instantiate a "B", it needs the base-class implementation (for the
> fields etc), so it needs A.dll; and to instantiate a C it needs A.dll and
> B.dll.
I understand that, but I would have expected .NET with all of it's discovery
and reflection technics
would have provided a much better solution to this.

> Re your 40-devs issue I'm nto sure that this directly is the problem; it
> sounds like you've got a hugely fragmented assembly base, which is going
> to be a nightmare any way you manage it.

I'm not sure if you have ever developed a very large system with this many
developers,
but just the nature of it being large with well over 200 different modules
(modules meaning types of applications),
and most of those modules do cross boundries and share classes.
So to have to pull in all of the assemeblies that each module uses for each
module needed is absolutely insane!!

So I don't think it's an issue of over-fragmentation, because the system
works fine as a C++ product and is NOT a nightmare,
I think the issues is short-sightedness on the .NET teams implementaion of a
system that clearly has the capability to
make this part of the system MUCH better.


>I'd stick with a small number of utility libraries...
That would just create more assemblies that would need to be referenced!