What is the purpose of Global Assembly Cache?

  • Thread starter Thread starter Guest
  • Start date Start date
G

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?
 
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.


Simon Wallis said:
I know the general purpose for the GAC is to share a component among many
Click to expand...
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?
 
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.
Click to expand...

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?
 
Simon Wallis said:
That does answer my question, thanks. But why is it bad if a copy is made
Click to expand...
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
Click to expand...
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.
 
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.
Click to expand...

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.
 
Simon Wallis said:
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
Click to expand...
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
Click to expand...
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.
 
Scott M. said:
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.
Click to expand...

<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
 
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!
 
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.


Dennis said:
I always thought the advantage of using a GAC was to conserve disk space
Click to expand...
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,
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
 
Back
Top