473,323 Members | 1,547 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,323 software developers and data experts.

Why do I need Base class DLL?

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/micro...4879b878b0f351

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

Mar 8 '06 #1
8 3462
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

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Mar 8 '06 #2
Brett Romero <ac*****@cygen.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 8 '06 #3
>>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

Mar 8 '06 #4
Brett Romero wrote:
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.


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?

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

Mar 8 '06 #5
>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

Mar 8 '06 #6

"Brett Romero" <ac*****@cygen.com> wrote in message
news:11**********************@j52g2000cwj.googlegr oups.com...
| >>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.

Mar 8 '06 #7
Brett Romero <ac*****@cygen.com> wrote:
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.


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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 8 '06 #8
>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

Mar 8 '06 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Gabriel Genellina | last post by:
Hi In the following code sample, I have: - a Worker class, which could have a lot of methods and attributes. In particular, it has a 'bar' attribute. This class can be modified as needed. - a...
8
by: Bryan Parkoff | last post by:
I find an interesting issue that one base class has only one copy for each derived class. It looks like that one base class will be copied into three base classes while derived class from base...
9
by: justanotherguy63 | last post by:
Hi, I am designing an application where to preserve the hierachy and for code substitability, I need to pass an array of derived class object in place of an array of base class object. Since I...
7
by: Baski | last post by:
Base class: class AssetBase { string _clli; public string CLLI { get
5
by: Dennis Jones | last post by:
Hello, I have a couple of classes that look something like this: class RecordBase { }; class RecordDerived : public RecordBase {
26
by: nyathancha | last post by:
Hi, How Do I create an instance of a derived class from an instance of a base class, essentially wrapping up an existing base class with some additional functionality. The reason I need this is...
15
by: Bob Johnson | last post by:
I have a base class that must have a member variable populated by, and only by, derived classes. It appears that if I declare the variable as "internal protected" then the base class *can*...
19
by: jan.loucka | last post by:
Hi, We're building a mapping application and inside we're using open source dll called MapServer. This dll uses object model that has quite a few classes. In our app we however need to little bit...
15
by: Juha Nieminen | last post by:
I'm sure this is not a new idea, but I have never heard about it before. I'm wondering if this could work: Assume that you have a common base class and a bunch of classes derived from it, and...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.