Setting References - What Happens Behind The Scenes?

[Smithers]

The "big picture" here is that I'm wondering what it is *specifically* about
[setting a reference] that enables my application (e.g., Project_A.exe) to
recognize and consume the types located in referenced assemblies.

Suppose I have Project_A (Windows Forms application) opened in Visual Studio
and I set a reference to two other assemblies:

1. Project_B (which is a class library project included in the same solution
as Project_A)

2. Library_C (which is a .NET class library on the local machine, but for
which we do not have the VS project)

What changes happen in the assembly or project metadata for Project_A for
each of the two references described above?

I understand that I can open the .csproj and/or the .sln files and see
additional entries per the references ---> but what is different about the
compiled assembly (Project_A.exe) for having the references (vs not having
the references)?

Thanks.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

The "big picture" here is that I'm wondering what it is *specifically*
about [setting a reference] that enables my application (e.g.,
Project_A.exe) to recognize and consume the types located in referenced
assemblies.

Suppose I have Project_A (Windows Forms application) opened in Visual
Studio and I set a reference to two other assemblies:

1. Project_B (which is a class library project included in the same
solution as Project_A)

2. Library_C (which is a .NET class library on the local machine, but for
which we do not have the VS project)

What changes happen in the assembly or project metadata for Project_A for
each of the two references described above?

Simply it indicate to the compiler to include those assembly at compile
time. Where the references being used is kept is not really important, and
it changes depending of the version/type of project.
IIRC by default it's kept in the project file (.csproj) but for example in
2.0 web sites it's kept in the config file.

I understand that I can open the .csproj and/or the .sln files and see
additional entries per the references ---> but what is different about the
compiled assembly (Project_A.exe) for having the references (vs not having
the references)?

There is no difference, remember, the referenced assembly MUST BE compiled
when is being used. What the IDE does is compile the referenced assembly
BEFORE compile the assembly that uses it.

 

[Smithers]

Thanks Ignacio,... now RE:
<< Simply it indicate to the compiler to include those assembly at compile
time.>>

Does this mean that the compiled Project_A.exe file will contain (within the
..exe file), each referenced .dll in its entirety?

Or does the compiled Project_A.exe file simply contain metadata about each
referenced .dll?

-"Smithers"

Hi,

The "big picture" here is that I'm wondering what it is *specifically*
about [setting a reference] that enables my application (e.g.,
Project_A.exe) to recognize and consume the types located in referenced
assemblies.

Suppose I have Project_A (Windows Forms application) opened in Visual
Studio and I set a reference to two other assemblies:

1. Project_B (which is a class library project included in the same
solution as Project_A)

2. Library_C (which is a .NET class library on the local machine, but for
which we do not have the VS project)

What changes happen in the assembly or project metadata for Project_A for
each of the two references described above?

Simply it indicate to the compiler to include those assembly at compile
time. Where the references being used is kept is not really important, and
it changes depending of the version/type of project.
IIRC by default it's kept in the project file (.csproj) but for example in
2.0 web sites it's kept in the config file.

I understand that I can open the .csproj and/or the .sln files and see
additional entries per the references ---> but what is different about
the compiled assembly (Project_A.exe) for having the references (vs not
having the references)?

There is no difference, remember, the referenced assembly MUST BE compiled
when is being used. What the IDE does is compile the referenced assembly
BEFORE compile the assembly that uses it.

 

[Guest]

Smithers,
Download Lutz Roeder's "Reflector" product, load an assembly that you have
built after adding a reference, and examine the metadata section to see it
for yourself.
Peter

 

[Jon Skeet [C# MVP]]

Thanks Ignacio,... now RE:
<< Simply it indicate to the compiler to include those assembly at compile
time.>>

Does this mean that the compiled Project_A.exe file will contain (within the
.exe file), each referenced .dll in its entirety?

Or does the compiled Project_A.exe file simply contain metadata about each
referenced .dll?

The exe file contains assembly references, and each use type which is
involved in the exe says which assembly it should come from. The
references are then resolved at execution time.

It definitely *doesn't* contain the whole dll.

 

[Smithers]

Wonderful - thanks!

-"Smithers"

Smithers,
Download Lutz Roeder's "Reflector" product, load an assembly that you have
built after adding a reference, and examine the metadata section to see it
for yourself.
Peter
--
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
bogMetaFinder: http://www.blogmetafinder.com

The "big picture" here is that I'm wondering what it is *specifically*
about
[setting a reference] that enables my application (e.g., Project_A.exe)
to
recognize and consume the types located in referenced assemblies.

Suppose I have Project_A (Windows Forms application) opened in Visual
Studio
and I set a reference to two other assemblies:

1. Project_B (which is a class library project included in the same
solution
as Project_A)

2. Library_C (which is a .NET class library on the local machine, but for
which we do not have the VS project)

What changes happen in the assembly or project metadata for Project_A for
each of the two references described above?

I understand that I can open the .csproj and/or the .sln files and see
additional entries per the references ---> but what is different about
the
compiled assembly (Project_A.exe) for having the references (vs not
having
the references)?

Thanks.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Thanks Ignacio,... now RE:
<< Simply it indicate to the compiler to include those assembly at compile
time.>>

Does this mean that the compiled Project_A.exe file will contain (within
the .exe file), each referenced .dll in its entirety?

Or does the compiled Project_A.exe file simply contain metadata about each
referenced .dll?

just the references, if you go to the debug folder you will see that along
your .EXE you will find the dll you use. If you delete the dll and double
click the exe you will get an error.