Reference problem

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

Edward Diener

I have a class Y in assembly B which is derived from a class Z in assembly
C. So I correctly add a reference to assembly C in assembly B, build
assembly B and everything builds fine. Now I create an assembly A which
refers to class Y in assembly B. So I add a reference in assembly A to
assembly B, and attempt to build. I get an error message, C3264, saying that
it could not find the type Z, and that it is in assembly C to which I have
no reference.

Is this a bug in VC++ 7.1 of VS .NET 2003 ? It is hard for me to believe
that referring to a type in an assembly means that I must also add a
reference not only to that type but to the assemblies which contain the base
class and/or interfaces of that type right up the hierarchy of all bases,
even when the assembly which has the type already has references to these
other assemblies. Is this really how .NET works ? Grrr !
 
Thanks for your feedback. I think it is a good suggestion but a hard one to
fix.
A solution could be that we pull in all types Y depends on in B.dll. Say Z
depends on A. Now A also comes in automatically for you when you just
referenced Y in B.dll.

There can be a lot of issues like these when we "automatically" pull in the
types. We have followed a header file scheme where you include all the files
you are referencing types in explicitly.
Plus, you just have to reference the assemblies explicitly the first time,
never again.

It can be worse if we include all the assemblies for you and then the
customer be surprised that he never referenced the type explicitly but the
type was pulled in anyway. Also imangine the size of our assemblies if we
pull in all the types which "might" be used. At compile time, we dont know
what types might be used.

Hope this helps
Thanks,
Kapil

In your example, say Z derived from A which is
 
Kapil said:
Thanks for your feedback. I think it is a good suggestion but a hard
one to fix.
A solution could be that we pull in all types Y depends on in B.dll.
Say Z depends on A. Now A also comes in automatically for you when
you just referenced Y in B.dll.

There can be a lot of issues like these when we "automatically" pull
in the types. We have followed a header file scheme where you include
all the files you are referencing types in explicitly.
Plus, you just have to reference the assemblies explicitly the first
time, never again.

It can be worse if we include all the assemblies for you and then the
customer be surprised that he never referenced the type explicitly
but the type was pulled in anyway. Also imangine the size of our
assemblies if we pull in all the types which "might" be used. At
compile time, we dont know what types might be used.
Click to expand...

You seem to have misunderstood. Assembly A only references class Y in
assembly B. Why does the linker then complain that I have not referenced
assembly C when building assembly A ? The reference in assembly A says
nothing about class Z in assembly C. If assembly B already has a reference
to assembly C, and I am referencing assembly B, why must I manually
reference assembly C also.

The analogous situation is standard Windows DLLs. If I have class Y in DLL B
that references class Z in DLL C, I import class Z in DLL C into DLL B. If I
then have DLL A that references class Y in DLL B, I import class Y in DLL B
into DLL A. I do not need to import class Z in DLL C into DLL A.
 
We are currently costing work to eliminate this issue in the cases where you
don't actually use any references to anything in assembly C. If you do
reference something directly you will still need to explicitly reference
assembly C. The reason for that is the fact that assembly location at
runtime is totally independent of assembly location at build time. And in
the case of a default VS install, they are different. Assembly B only
contains an assembly identity for assembly C, not the actual built time
location. And assembly binding is only useful for finding the runtime
version of assembly C.

Ronald Laeremans
Visual C++ team
 
Ronald said:
We are currently costing work to eliminate this issue in the cases
where you don't actually use any references to anything in assembly
C.
Click to expand...

I do not understand what you mean by "costing work".
If you do reference something directly you will still need to
explicitly reference assembly C.
Click to expand...

Of course. But in my example I was not referencing anything in assembly C
but in assembly B, yet the IDE required me to create a reference for
assembly C.
The reason for that is the fact that
assembly location at runtime is totally independent of assembly
location at build time.
Click to expand...

That is understood.
And in the case of a default VS install, they
are different. Assembly B only contains an assembly identity for
assembly C, not the actual built time location. And assembly binding
is only useful for finding the runtime version of assembly C.
Click to expand...

Understood. But as I stated above, the issue was that I correctly added a
reference to assembly B from assembly A but was still required to add a
reference to assembly C from assembly A even though I was not referencing
anything in assembly C and assembly B, which was referencing something in
assembly C, already had a reference to assembly C. If I use assembly A I
would assume that since I am referencing assembly B, assembly B is loaded
into my application domain, and once assembly B is loaded, since assembly B
is referencing something from assembly C, that assembly is loaded into my
application domain. But there should be no need for assembly A to reference
assembly C in this scenario just to get assembly C loaded into my
application domain. That is the issue which I have brought up, and which I
hope you will fix.
 
Costing == estimating the dev and test cost of changing the design here.
Step 2 in getting it shipped. Step 1 is determining whether we think we
should do it in the first place if we can, and that is already done, the
answer there is yes, if we can fit it in, we will.

Ronald
 
Ronald said:
Costing == estimating the dev and test cost of changing the design
here. Step 2 in getting it shipped. Step 1 is determining whether we
think we should do it in the first place if we can, and that is
already done, the answer there is yes, if we can fit it in, we will.
Click to expand...

I hope you can. Logically a programmer should only have to worry about
referencing an assembly where references are actually made, but I am sure
 
Back
Top