Inheritance Woes
rkozlin
"The type '<BaseClass>' is defined in an assembly that is not referenced.
You must add a reference to assembly '<BaseClass>'."
... when using a derived class where the base class and the derived class
are compiled into separate assemblies. In this case we are attempting to
reference the derived class in a project and had assumed that the base class
assembly would automatically be referenced via the derived class's assembly.
This seems to defeat the purpose of inheritance in C#! Is it at all
possible to accomplish this without having to reference both the derived and
the base class? With only one base class and a single derived class it is
not that big a deal to reference both, but the idea behind doing this is that
we could have several derived class assemblies chained together. Having to
reference the entire chain in each assembly's project .... well you get the
idea.
Thanks
Kevin Spencer
to avoid having multiple copies of the same code all over the place. The
base class has the base class code. If you don't reference its assembly,
where do you expect it to come from? You expect the derived class to copy
it? THAT would defeat the purpose of inheritance.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.
"rkozlin" <rko...@discussions.microsoft.com> wrote in message
news:F0734629-4D06-443B...@microsoft.com...
Bruce Wood
code? The error you're complaining about is a compile-time thing, at
the very beginning of the life cycle of an assembly. If I write in one
of my assemblies:
public class Derived : HaveAGoodTimeFindingThisBaseClass
{
...
}
Where is the compiler supposed to look to find the definition for
HaveAGoodTimeFindingThisBaseClass? I mean, _I_ know where it is, but
the compiler has no idea. It may be in an adjacent folder, another
drive, or somewhere on the network. It has no idea.
I suppose that it could try looking in the GAC to see if it finds
anything by that name, but not all assemblies are stored in the GAC.
So I cannot even imagine how a derived class would "automatically"
reference its base class at compile time, unless you mean that the
compiler should scan the GAC looking for likely matches.
Besides all of this, you also have to have the base class assembly
accessible at run time: either in the same directory as the executable
(or in a few other places that .NET searches automatically) or in the
GAC. This is where Kevin's objection takes over: you need both
assemblies at run time because the compiler does _not_ copy base class
code into the derived assembly, and it does not do so for very good
reasons related to versioning.
chris martin
I don't see how it defeats the purpose of inheritance. Are you sure of the
definition of inheritance?
The only way around not having to reference both DLLs into your app is to
not expose any of the base assembly's type in the public interface of the
"sub-classed" assembly.
rkozlin
projects:
BaseClass
DerivedClass
TestApp
BaseClass references nothing nonstandard. DerivedClass references
BaseClass's assembly because it inherits from BaseClass. TestApp references
DerivedClass's assembly because it is instantiating an object from it. Not
sure if I can "gump" that any further for you.
On compile we fail because the C#.Net compiler was created in such a way as
to require BaseClass's assembly referenced on TestApp!!! Now, stop there.
Think hard fellas. If you do not see the problem here then just don't bother
responding. I can only suggest you duplicate this solution/project in VB.Net.
Why? Because I did that this morning... and guess what? It works! If C#
cannot do this then I would like it explained exactly why it cannot. I want
to know why VB can go where C# cannot.
I would like a Microsoft Rep to respond to this please.