Adding references: the details

[_DS]

The two obvious methods for ref'ing assemblies are:

Add a reference and 'Browse' for the actual DLL

OR

Add existing project to the solution, then add a ref to 'Project'.

1: I'd like to find out what the latter method is doing.
I'm assuming that it makes sure that debug exe gets matched to
debug DLL, etc. What else is going on? (I couldn't locate much
info in MSDN)

2: This method induces a couple glitches: If assembly A refs
assembly B, then the project for assembly A works as expected:
Just add assembly B to A's solution, then set a reference to B.

Now what about the final exe that uses assembly A: Add A to
the exe's solution, then set a reference to A. You'd expect that
B would be automatically ref'd by A's project. No such luck. The
build generates an error as if A can no longer find assebly B.

I hope that was understandable. Any way to simplify that, or must
the top solution go through the add-to-project and add-ref-to-project
for every sub-sub-sub-assembly that's referenced?

[Frans Bouma [C# MVP]]

_DS wrote:

The two obvious methods for ref'ing assemblies are:

Add a reference and 'Browse' for the actual DLL

OR

Add existing project to the solution, then add a ref to 'Project'.

1: I'd like to find out what the latter method is doing.
I'm assuming that it makes sure that debug exe gets matched to
debug DLL, etc. What else is going on? (I couldn't locate much
info in MSDN)
the second option adds a reference to project\obj\assembly.dll for
compilation and in the csproj file it adds a reference to the project
instead of the dll, that's it.

It doesn't matter if you reference the debug or release build @
compilation time, as long as an assembly with the same assembly version
is available at runtime when the application is deployed.
2: This method induces a couple glitches: If assembly A refs
assembly B, then the project for assembly A works as expected:
Just add assembly B to A's solution, then set a reference to B.

Now what about the final exe that uses assembly A: Add A to
the exe's solution, then set a reference to A. You'd expect that
B would be automatically ref'd by A's project. No such luck. The
build generates an error as if A can no longer find assebly B.
what does 'add A to the exe's solution mean, adding the project to the
solution or adding a reference to the compiled assembly?
I hope that was understandable. Any way to simplify that, or must
the top solution go through the add-to-project and add-ref-to-project
for every sub-sub-sub-assembly that's referenced?

That shouldn't be necessary. My exe references assembly A, which
references assembly B and B is placed inside the bin folder of the exe
without a problem, automatically.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[_DS]

On Tue, 17 Jan 2006 01:42:55 -0800, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

_DS wrote:

Add existing project to the solution, then add a ref to 'Project'.

1: I'd like to find out what the latter method is doing.
I'm assuming that it makes sure that debug exe gets matched to
debug DLL, etc. What else is going on? (I couldn't locate much
info in MSDN)

the second option adds a reference to project\obj\assembly.dll for
compilation and in the csproj file it adds a reference to the project
instead of the dll, that's it.
It could ref either the debug or the release version. Since the
project was now being referenced as a whole, I assumed that the
correct match for given compilation mode (debug vs release ) would be
chosen. Sounds like the answer is No. So which DLL would be chosen?
It doesn't matter if you reference the debug or release build @
compilation time, as long as an assembly with the same assembly version
is available at runtime when the application is deployed.

2: This method induces a couple glitches: If assembly A refs
assembly B, then the project for assembly A works as expected:
Just add assembly B to A's solution, then set a reference to B.

Now what about the final exe that uses assembly A: Add A to
the exe's solution, then set a reference to A. You'd expect that
B would be automatically ref'd by A's project. No such luck. The
build generates an error as if A can no longer find assebly B.

what does 'add A to the exe's solution mean, adding the project to the
solution or adding a reference to the compiled assembly?

Add A's project to the Exe's project, then set a reference to A.
I hope that was understandable. Any way to simplify that, or must
the top solution go through the add-to-project and add-ref-to-project
for every sub-sub-sub-assembly that's referenced?

That shouldn't be necessary. My exe references assembly A, which
references assembly B and B is placed inside the bin folder of the exe
without a problem, automatically.

Then something is not right. The Exe is never referring to B
directly. The Exe refers only to A, which in turn refers to B.
You'd think that compile references would handle this. But though A
and B are compilable on their own, adding assembly A to the exe file
will generate an error message about unresolved items in B.

What could cause or fix that?

[Frans Bouma [C# MVP]]

_DS wrote:

On Tue, 17 Jan 2006 01:42:55 -0800, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

_DS wrote:

Add existing project to the solution, then add a ref to 'Project'. >> 1: I'd like to find out what the latter method is doing.
I'm assuming that it makes sure that debug exe gets matched to
debug DLL, etc. What else is going on? (I couldn't locate much >> info in MSDN)

the second option adds a reference to project\obj\assembly.dll for
compilation and in the csproj file it adds a reference to the
project instead of the dll, that's it.
It could ref either the debug or the release version. Since the
project was now being referenced as a whole, I assumed that the
correct match for given compilation mode (debug vs release ) would be
chosen. Sounds like the answer is No. So which DLL would be chosen?

the one belonging to the current action. So if you build a debug
build, the debug version is referenced. THough that doesn't matter. In
debug or release, the assembly names are the same, which is what
matters.

I hope that was understandable. Any way to simplify that, or must
the top solution go through the add-to-project and

add-ref-to-project >> for every sub-sub-sub-assembly that's
referenced?

That shouldn't be necessary. My exe references assembly A, which
references assembly B and B is placed inside the bin folder of the
exe without a problem, automatically.

Then something is not right. The Exe is never referring to B
directly.

No of course it isn't doing that. but B is ending up in the bin\debug
or bin\release folders and when you try to run the exe it will run.

If the exe is referring in code to types in B, B has to be referenced
manually.
The Exe refers only to A, which in turn refers to B.
You'd think that compile references would handle this. But though A
and B are compilable on their own, adding assembly A to the exe file
will generate an error message about unresolved items in B.

What could cause or fix that?

Please remember that 'an error message' is a statement which doesn't
help, please state the error message you get, I'll now assume what
happens and I think it's because you have a base type in B, you derive
a class from that in A and you use that type in the .exe, correct? The
..exe then needs a reference to B if you in your code use public
methods/properties from the type which are actually defined in the base
class in B. This is logical, as the methods/properties aren't known in
A, they're defined in B.

This indeed isn't done automatically, the error description suggests
what to do to fix it.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------