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