What is the purpose of Global Assembly Cache?

[Guest]

I know the general purpose for the GAC is to share a component among many applications. But even when you add something to the GAC, you still have to manually create a reference to the DLL in your project (right?). So what have I gained by adding it to the GAC?

 

[Scott M.]

If you were to make a reference to a non-shared assembly (a private
assembly) from an application, you would wind up with a copy of that
assembly being placed in your application's bin folder. When you make a
reference to a shared assembly, you don't get a copy, you are working of the
one assembly registered into the GAC.

I know the general purpose for the GAC is to share a component among many

applications. But even when you add something to the GAC, you still have to
manually create a reference to the DLL in your project (right?). So what
have I gained by adding it to the GAC?

 

[Guest]

If you were to make a reference to a non-shared assembly (a private

assembly) from an application, you would wind up with a copy of that
assembly being placed in your application's bin folder. When you make a
reference to a shared assembly, you don't get a copy, you are working of the
one assembly registered into the GAC.

That does answer my question, thanks. But why is it bad if a copy is made of an assembly? There must be a greater reason than it's just rather messy to have a bunch of copies of a dll lying around in bin folders. Perhaps it is obvious but I'm new to this. Can you give me a scenario that shows why not using the GAC would be bad?

Another question: I've read in several places that Microsoft recommends against using the GAC unless you really need to share an assembly across several apps. What is the big deal in using the GAC that would cause them to make such a recommendation? Is it just a "best practice" to use it only for sharing assemblies, or can one run into certain problems if the GAC is over-used?

 

[Scott M.]

That does answer my question, thanks. But why is it bad if a copy is made

of an assembly? There must be a greater reason than it's just rather messy
to have a bunch of copies of a dll lying around in bin folders. Perhaps it
is obvious but I'm new to this. Can you give me a scenario that shows why
not using the GAC would be bad?

No one said it was "bad" to use a private (non-shared) assembly, but if you
do and changes get made to the original, your application wouldn't know
about those changes because you would be working from a copy.

Another question: I've read in several places that Microsoft recommends

against using the GAC unless you really need to share an assembly across
several apps. What is the big deal in using the GAC that would cause them to
make such a recommendation? Is it just a "best practice" to use it only for
sharing assemblies, or can one run into certain problems if the GAC is
over-used?

Well, the GAC is *only* used for sharing assemblies, there is no other use
for it. So, if you don't need a shared assembly, why go through the bother
(there is some setup and registration work needed to install an assembly
into the GAC) of doing so? Your application has to have additional overhead
added to it when it is shared (not a huge amount, but some) and if you don't
need a shared assembly, there's no reason to do it.

 

[Guest]

Thanks for your time in responding Scott, it's helping my understanding.

No one said it was "bad" to use a private (non-shared) assembly, but if you
do and changes get made to the original, your application wouldn't know
about those changes because you would be working from a copy.

True, but if I understand correctly, when you make changes to an assembly that has been registered in the GAC, then the GAC version does not get updated when you recompile. So any apps that use it to not get the updated copy either. You must re-register the udpated assembly in the GAC as a new version, and then point all the apps to the new version if you want them to use it.

Or is it possible to update the *current* version in the GAC with new code? If that were the case, then any apps using that version would automatically see the updates, and then yes the GAC would be a big time saver.

 

[Scott M.]

Thanks for your time in responding Scott, it's helping my understanding.


True, but if I understand correctly, when you make changes to an assembly

that has been registered in the GAC, then the GAC version does not get
updated when you recompile. So any apps that use it to not get the updated
copy either. You must re-register the udpated assembly in the GAC as a new
version, and then point all the apps to the new version if you want them to
use it.

Or is it possible to update the *current* version in the GAC with new

code? If that were the case, then any apps using that version would
automatically see the updates, and then yes the GAC would be a big time
saver.
Depending on how much the version has changed (you can set the version
number in the AsemmblyInfo file) the CLR will or will not treat the newly
compiled assembly as "compatible" with the older one. If you made only
minor changes to the assembly and the version number changed only in the
revision portion, then re-registered the assembly into the GAC, applications
that used the prior version should immediately begin to use the new version.

 

[Cecil Howell]

Depending on how much the version has changed (you can set the version
number in the AsemmblyInfo file) the CLR will or will not treat the newly
compiled assembly as "compatible" with the older one. If you made only
minor changes to the assembly and the version number changed only in the
revision portion, then re-registered the assembly into the GAC, applications
that used the prior version should immediately begin to use the new version.

<major version>.<minor version>.<build number>.<revision>


This is actually incorrect. If you build an app against an assembly
with a strong name (been signed) then the app will only run against
the identicall version of the assembly unless redirected to a newer
version by a config file or a publisher policy. This is a common
misunderstanding, I have read in many places that if only the build or
revision number are different then the versions should be compatible
and this is in fact how you should treat versioning, BUT the default
binding policy does not use this logic.

Cecil Howell
MCSD, MCT

 

[Scott M.]

If that is the case, then what is the advantage of the GAC?

 

[Guest]

I always thought the advantage of using a GAC was to conserve disk space which isn't really much of a problem any more. If you don't use a GAC, then each program that uses the DLL has to have it's own copy, i.e., like the Windows System DLL's. Am I wrong? One advantage of NOT use GAC's is avoiding DLL Hell!

 

[Scott M.]

The GAC was not created just to save disk space and by using it you don't
open yourself to dll Hell since the gac doesn't use the Windows Registry.

I always thought the advantage of using a GAC was to conserve disk space

which isn't really much of a problem any more. If you don't use a GAC, then
each program that uses the DLL has to have it's own copy, i.e., like the
Windows System DLL's. Am I wrong? One advantage of NOT use GAC's is
avoiding DLL Hell!

 

[Cecil Howell]

Scott,
I should have been more complete. I said that the default binding
policy does not use the newest version but what I left out is that the
binding policy can be changed at a couple different levels. Say you
bought a datagrid component from infragistics and used it your app,
during installation you put the dll for the grid in the GAC. Now lets
say months later that user downloads an app with a newer compatible
version (fixes a couple bugs) of the infragistics grid. That program
also installs the grid to the GAC. The default binding policy would
still have your app using the older buggy version, but this can be
altered! When Infragistics put out the newer grid they would include
a special DLL called a publisher policy, this DLL is placed in the Gac
along with the newer version dll and contains information on
compatibility with previous versions. This publisher policy is read
by the clr when your app tries to load the grid dll and it will be
redirected to load the newest version.
If Infragistics messed up and the newer grid broke your app you could
use the app config to override the publisher policy and continue using
the older version.

Here is a link to a much more comprehensive explanation by one of the
MS guys who actualy designed the system:

http://blogs.msdn.com/alanshi

Well now that I revisted that link I realize I should have just
skipped my explanation and just directed you to Alan's blog. Oh well
I spent all this time typing it so off it goes.

Hope this clarifies
Cecil Howell
MCSD, MCT