Why do I need Base class DLL?

[Brett Romero]

I have this situation:

myEXE <needs< DerivedClass <which needs< BaseClass

Meaning, myEXE is using a type defined in DerivedClass, which inherits
from BaseClass. I include a reference to DerivedClass in myEXE, which
gives this error:

The type 'BaseAssembly.SomeClass' is defined in an assembly that is not
referenced. You must add a reference to assembly 'BaseAssembly,
Version=0.1.0.0, Culture=neutral, PublicKeyToken=null'.

The only way it works is if I also include BaseClass, which I shouldn't
have to. This guy try to point it out for a few people but they all
figure including the whole chain (meaning BaseClasses) is the correct
method:

http://groups.google.com/group/micr...s+not+reference&rnum=8&hl=en#9c4879b878b0f351

Is this just the way it has to be in C# 2.0 or is there another way
without including the entire chain?

Thanks,
Brett

 

[Mattias Sjögren]

Is this just the way it has to be in C# 2.0 or is there another way
without including the entire chain?

Yes, the compiler needs to know the whole type hierarchy to know which
members are available.


Mattias

 

[Jon Skeet [C# MVP]]

I have this situation:

myEXE <needs< DerivedClass <which needs< BaseClass

Meaning, myEXE is using a type defined in DerivedClass, which inherits
from BaseClass. I include a reference to DerivedClass in myEXE, which
gives this error:

The type 'BaseAssembly.SomeClass' is defined in an assembly that is not
referenced. You must add a reference to assembly 'BaseAssembly,
Version=0.1.0.0, Culture=neutral, PublicKeyToken=null'.

The only way it works is if I also include BaseClass, which I shouldn't
have to.

Why do you think you shouldn't have to? Both the compiler and the
runtime need the assembly in order to know what members are available
and to run the code.

This guy try to point it out for a few people but they all
figure including the whole chain (meaning BaseClasses) is the correct
method:

Unsurprisingly, you're likely to get the same answer here now.

Is this just the way it has to be in C# 2.0 or is there another way
without including the entire chain?

It's just the way it is, and in my view it's an entirely reasonable
thing.

 

[Brett Romero]

It's just the way it is, and in my view it's an entirely reasonable
thing.

It seems very impractical. The compiler should know and implicitly
import the base class. All the information for the compiler is there.
The EXE explicitly includes the derived class because it uses a type
from there. By explicit, I mean some one manually went into the derived
class's project and setup the base class file reference. That should
be the end of this story. However, the compiler has to be hand held,
even though it can see this derived class uses a base class (via the
derived classes file reference to the base as setup above) and
implicitly import this base class into the EXE's output folder. Not
so.

What you are saying is that C# is doing it smarter than VB.NET. From
what I've read, VB.NET doesn't require this. Seems as though VB got it
right and the C# dev team went on vacation that week. Unless you just
like more unnecessary work, which you don't need to rationalize.

Brett

 

[Jon Skeet [C# MVP]]

thing.

It seems very impractical. The compiler should know and implicitly
import the base class. All the information for the compiler is there.

Not necessarily. The place that you reference the derived class from
isn't necessarily somewhere that actually includes the base class
assembly - quite often you build to separate directories, and only at
runtime would you put them all in the same directory. How would it know
where it should reference the base class assembly from?

What you are saying is that C# is doing it smarter than VB.NET. From
what I've read, VB.NET doesn't require this. Seems as though VB got it
right and the C# dev team went on vacation that week. Unless you just
like more unnecessary work, which you don't need to rationalize.

I don't know what VB.NET does in this situation, but I'll try to have a
look tonight.

Maybe they took the step of automatically adding a reference when one
is missing. I wonder if the reference is automatically *removed* if you
later decide you don't need to use that derived class any more... (You
might still need to use the assembly which contains the derived class,
however.)

Jon

 

[Brett Romero]

Not necessarily. The place that you reference the derived class from

isn't necessarily somewhere that actually includes the base class
assembly - quite often you build to separate directories, and only at
runtime would you put them all in the same directory. How would it know
where it should reference the base class assembly from?

When I build myEXE.exe project, it imports the derived class in the
output folder of myEXE.exe. I believe every one agrees with this. It
is always the case (from my observations). Now, go back a little in
time. I build the derived class, which imports the base class into its
output directory. Ok, now the derived and base are in the same
directory. I've never seen it do otherwise. Now move foward in time
and build the EXE. It imports the derived, which knows where its base
is and can drag the base along. How do I know it knows where the base
is? Because the derived class project imported it into the derive's
output folder. The compiler knew exactly where the base originated
(via the DLL file reference in the derived class project that some
developer setup) and knew exactly where the derived project's output
folder is for copying the base class (either setup by default or a
developer). All of this is now known. Here's what happens next.

C# compiles myEXE.exe and includes the derived class because it knows
this location as explained above. The base class doesn't come along
because the C# compiler disregards using its own information about
where the base is. Remember, all of this knowledge is readily
available as explained in the first paragraph. Why did the C# compiler
choose to disregard it? Who knows - budget, good developers left the
team before code complete, time constraints. What ever the reason, the
base is not there. Us developers are now forced to include this
entire chain of derivation explicitly since the C# compiler refuses to
help us out and simply use its own knowledge about the base class
location and import the base into the myEXE.exe project output folder.
The implicit import only goes back one DLL and no further, as many in
this group have pointed out and learned (sometimes the hard way).

Again, if you like taking time out to include your entire derived
chain, by all means, it is your privilege. I on the other hand would
rather be doing something slightly more productive and less mundane.

Brett

 

[Willy Denoyette [MVP]]

| >>It's just the way it is, and in my view it's an entirely reasonable
| thing.
|
| It seems very impractical. The compiler should know and implicitly
| import the base class. All the information for the compiler is there.
| The EXE explicitly includes the derived class because it uses a type
| from there. By explicit, I mean some one manually went into the derived
| class's project and setup the base class file reference. That should
| be the end of this story. However, the compiler has to be hand held,
| even though it can see this derived class uses a base class (via the
| derived classes file reference to the base as setup above) and
| implicitly import this base class into the EXE's output folder. Not
| so.
|
| What you are saying is that C# is doing it smarter than VB.NET. From
| what I've read, VB.NET doesn't require this. Seems as though VB got it
| right and the C# dev team went on vacation that week. Unless you just
| like more unnecessary work, which you don't need to rationalize.
|

Please, be sceptic, don't believe everything you read (don't even believe
this ), it just take a few minutes to test it out, and you will see that
it's BS.

' file b.vb
Namespace TestNamespace
Public Class BaseClass

End Class
End Namespace

'File d.vb
Namespace TestNamespace
Public Class DerivedClass
Inherits BaseClass


End Class
End Namespace

'file m.vb

Namespace TestNamespace
Module Module1

Sub Main()
Dim bc As BaseClass
bc = new BaseClass()

End Sub

End Module
End Namespace

Compile from the command line using these commands

vbc /t:library b.vb
vbc /t:library d.vb
vbc /r:d.dll m.vb
this will fail with:
..... : error BC30007: Reference required to assembly 'b, Version=0.0.0.0,
Culture=neutral, P
ublicKeyToken=null' containing the base class 'TestNamespace.BaseClass'. Add
one to your project.
while this:
vbc /r:d.dll,b.dll m.vb
will succeeds.

The reason for this is already given by Jon and Mattias...


Willy.

 

[Jon Skeet [C# MVP]]

When I build myEXE.exe project, it imports the derived class in the
output folder of myEXE.exe. I believe every one agrees with this.

Well, not quite. You need to be clear about terminology - you can't
import a class, only an assembly.

In addition, it *doesn't* do that when the CopyLocal property of the
reference is false.

Just as an example - if you build a class which uses System.String, it
doesn't copy mscorlib.dll into the output directory, does it?

It is always the case (from my observations). Now, go back a little
in time. I build the derived class, which imports the base class into
its output directory. Ok, now the derived and base are in the same
directory. I've never seen it do otherwise.

Then presumably you've never had CopyLocal set to false.

Now move foward in time
and build the EXE. It imports the derived, which knows where its base
is and can drag the base along. How do I know it knows where the base
is? Because the derived class project imported it into the derive's
output folder. The compiler knew exactly where the base originated
(via the DLL file reference in the derived class project that some
developer setup) and knew exactly where the derived project's output
folder is for copying the base class (either setup by default or a
developer). All of this is now known. Here's what happens next.

Suppose you update the base class project and build that. At that
point, because you've got a reference to a *copy* of the base class
assembly, you don't get that change until you *also* build the derived
class project. Doesn't sound ideal.

C# compiles myEXE.exe and includes the derived class because it knows
this location as explained above. The base class doesn't come along
because the C# compiler disregards using its own information about
where the base is. Remember, all of this knowledge is readily
available as explained in the first paragraph. Why did the C# compiler
choose to disregard it?

Again, just to be precise: I suspect it's an IDE issue, not a compiler
issue. I doubt whether the VB.NET *compiler* includes references
transitively - I suspect (though I haven't checked) that it just adds a
reference behind the scenes.

Who knows - budget, good developers left the
team before code complete, time constraints. What ever the reason, the
base is not there. Us developers are now forced to include this
entire chain of derivation explicitly since the C# compiler refuses to
help us out and simply use its own knowledge about the base class
location and import the base into the myEXE.exe project output folder.
The implicit import only goes back one DLL and no further, as many in
this group have pointed out and learned (sometimes the hard way).

Again, if you like taking time out to include your entire derived
chain, by all means, it is your privilege. I on the other hand would
rather be doing something slightly more productive and less mundane.

So at what point does the extra reference get removed automatically in
your ideal world?

I think I prefer the explicit references - although it wouldn't hurt to
let VS.NET *suggest* the addition of other references.

Interestingly enough, I've just tried this in VB.NET (in VS2005) and I
get the same kind of error as I do for C#:

<quote>
Error 1 Reference required to assembly 'BaseLibrary, Version=
1.0.0.0, Culture=neutral, PublicKeyToken=null' containing the base
class 'BaseLibrary.BaseClass'. Add one to your project. c:\docs
\Computing\Visual Studio 2005\Projects\Test\VBUser\Module1.vb 6 18
VBUser
</quote>

To get to this situation, I created a class library project
"BaseLibrary" and another "DerivedLibrary" which has a reference to the
"BaseLibrary" project. I then created a console app project with a
reference to the "DerivedLibrary" project, which just creates a new
instance of the derived type.

Can you tell me the situation in which VB.NET automatically adds the
reference?

 

[Brett Romero]

Can you tell me the situation in which VB.NET automatically adds the
reference?

No. As I mentioned, that's only what I've read, which may be wrong.
It seems a couple of people have already refuted it. As a middle
ground, I think there should be an option you can set to implicitly
import the base assembly.

Also, all of my discussion is around using FileCopyLocal = true.

because you've got a reference to a *copy* of the base class
assembly, you don't get that change until you *also* build the derived
class project. Doesn't sound ideal.

This is a good point and I haven't tried it. With the derived, you get
the latest copy (again using FileCopyLocal=true). However, with an
option to implicitly import the base assembly, the developer should be
aware of this or at least be made aware.

Brett