using GAC

[Tony Johansson]

Hello!

I have read some info on the WWW about GAC
It says the following.

"If you want to use an assembly from the GAC,
you should drop your assemblies into a local folder,
and then add a reference to the assembly from this folder.
You may want to set the "Copy Local" property to False for
that assembly if you do not want the assembly to be copied
locally to your project folders. At runtime, the application
will automatically use the assembly from the GAC. "

This GAC as I have understood is just a folder view and does not contain
any shared library dll.

At the end of the text it says "At runtime, the application
will automatically use the assembly from the GAC. " but hello the GAC
doesn't
contain any assembly so how can it then use the assembly from the GAC
when GAS just a folder view. This must be wrong.

At runtime it must use the actual shared assembly dll otherwise it shouldn't
work.

//Tony

 

[Nicholas Paldino [.NET/C# MVP]]

Tony,

When you look at the GAC in explorer, it actually isn't a folder view.
I ^looks^ like a folder view, because there a shell handler which gives it a
folder-appearance.

The reason why you set your reference to a local copy of the assembly is
so that you can compile your code. The compiler needs to see the assembly,
and it can't pull the one from the GAC.

However, when you set the "Copy Local" property to false, what ends up
happening is that it doesn't place a copy of the referenced assembly in the
bin directory with your compiled app.

When the app runs, Fusion (the name for the mechanism in the CLR by
which assemblies are located) sees that the referenced assembly is not in
the local application directory (since it wasn't copied at build-time), and
then at some point (there are a few other locations it looks) goes to the
GAC (assuming it is strong-named).

Hope this helps.

 

[Tony Johansson]

Hello!!

Here you write

When the app runs, Fusion (the name for the mechanism in the CLR by
which assemblies are located) sees that the referenced assembly is not in
the local application directory (since it wasn't copied at build-time), and
then at some point (there are a few other locations it looks) goes to the
GAC (assuming it is strong-named).

but when the app runs it must have access to actual shared assembly dll
where
the actual code exist.

As you mention GAC is used at runtime but tell me how can it access the
actual code
when there is not actual code in GAC.

I mean when you are in runtime you must have access to the actual shared
assembly code or
I'm wrong ?

//Tony

Tony,

When you look at the GAC in explorer, it actually isn't a folder view.
I ^looks^ like a folder view, because there a shell handler which gives it a
folder-appearance.

The reason why you set your reference to a local copy of the assembly is
so that you can compile your code. The compiler needs to see the assembly,
and it can't pull the one from the GAC.

However, when you set the "Copy Local" property to false, what ends up
happening is that it doesn't place a copy of the referenced assembly in the
bin directory with your compiled app.

When the app runs, Fusion (the name for the mechanism in the CLR by
which assemblies are located) sees that the referenced assembly is not in
the local application directory (since it wasn't copied at build-time), and
then at some point (there are a few other locations it looks) goes to the
GAC (assuming it is strong-named).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello!

I have read some info on the WWW about GAC
It says the following.

"If you want to use an assembly from the GAC,
you should drop your assemblies into a local folder,
and then add a reference to the assembly from this folder.
You may want to set the "Copy Local" property to False for
that assembly if you do not want the assembly to be copied
locally to your project folders. At runtime, the application
will automatically use the assembly from the GAC. "

This GAC as I have understood is just a folder view and does not contain
any shared library dll.

At the end of the text it says "At runtime, the application
will automatically use the assembly from the GAC. " but hello the GAC
doesn't
contain any assembly so how can it then use the assembly from the GAC
when GAS just a folder view. This must be wrong.

At runtime it must use the actual shared assembly dll otherwise it
shouldn't work.

//Tony

 

[Nicholas Paldino [.NET/C# MVP]]

Tony,

The location where the framework keeps assemblies in the GAC is a
private implementation detail. There is actually code there, but how it is
stored there is not of concern. Just because you can't see it in explorer
doesn't mean that you can't access it.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello!!

Here you write

When the app runs, Fusion (the name for the mechanism in the CLR by
which assemblies are located) sees that the referenced assembly is not in
the local application directory (since it wasn't copied at build-time), and
then at some point (there are a few other locations it looks) goes to the
GAC (assuming it is strong-named).

but when the app runs it must have access to actual shared assembly dll
where
the actual code exist.

As you mention GAC is used at runtime but tell me how can it access the
actual code
when there is not actual code in GAC.

I mean when you are in runtime you must have access to the actual shared
assembly code or
I'm wrong ?

//Tony

Tony,

When you look at the GAC in explorer, it actually isn't a folder view.
I ^looks^ like a folder view, because there a shell handler which gives it a
folder-appearance.

The reason why you set your reference to a local copy of the assembly is
so that you can compile your code. The compiler needs to see the assembly,
and it can't pull the one from the GAC.

However, when you set the "Copy Local" property to false, what ends up
happening is that it doesn't place a copy of the referenced assembly in the
bin directory with your compiled app.

When the app runs, Fusion (the name for the mechanism in the CLR by
which assemblies are located) sees that the referenced assembly is not in
the local application directory (since it wasn't copied at build-time), and
then at some point (there are a few other locations it looks) goes to the
GAC (assuming it is strong-named).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello!

I have read some info on the WWW about GAC
It says the following.

"If you want to use an assembly from the GAC,
you should drop your assemblies into a local folder,
and then add a reference to the assembly from this folder.
You may want to set the "Copy Local" property to False for
that assembly if you do not want the assembly to be copied
locally to your project folders. At runtime, the application
will automatically use the assembly from the GAC. "

This GAC as I have understood is just a folder view and does not contain
any shared library dll.

At the end of the text it says "At runtime, the application
will automatically use the assembly from the GAC. " but hello the GAC
doesn't
contain any assembly so how can it then use the assembly from the GAC
when GAS just a folder view. This must be wrong.

At runtime it must use the actual shared assembly dll otherwise it
shouldn't work.

//Tony

 

[Bruce Wood]

Tony,

The location where the framework keeps assemblies in the GAC is a
private implementation detail. There is actually code there, but how it is
stored there is not of concern. Just because you can't see it in explorer
doesn't mean that you can't access it.

Which leads me to point out that the missing piece in this whole
discussion is that at some point you have to install your shared
assembly into the GAC. You can't just compile your application using
the assembly in a project bin directory, without making a local copy of
the shared assembly, and then run the application and it magically
finds the shared assembly in the GAC.

You have to build the shared assembly (DLL), install it in the GAC
(which copies the intermediate code into the GAC and registers it),
then compile the application pointing to the shared assembly in its
original directory (without copying it into the application's bin
directory), then run the application, which will find the copy of the
shared assembly that you installed in the GAC.

If you don't do the install-into-GAC step, the application will fail
because it can't find one of the assemblies upon which it depends. Or,
if the version of the shared assembly in the GAC is not the same
version with which the application was compiled, it will also fail
because it can't find the correct version. (Note that this is not
strictly true... there are ways around this problem, but this is the
default behaviour.)