468,242 Members | 1,626 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,242 developers. It's quick & easy.

What is the purpose of Global Assembly Cache?

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?

Nov 22 '05 #1
10 3424
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" <Si*********@discussions.microsoft.com> wrote in message
news:F8**********************************@microsof t.com...
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?

Nov 22 '05 #2
> 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?

Nov 22 '05 #3

"Simon Wallis" <Si*********@discussions.microsoft.com> wrote in message
news:2B**********************************@microsof t.com...
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?

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.


Nov 22 '05 #4
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.

Nov 22 '05 #5

"Simon Wallis" <Si*********@discussions.microsoft.com> wrote in message
news:34**********************************@microsof t.com...
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.


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.
Nov 22 '05 #6
"Scott M." <s-***@nospam.nospam> wrote in message news:<OZ*************@TK2MSFTNGP12.phx.gbl>...

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
Nov 22 '05 #7
If that is the case, then what is the advantage of the GAC?
"Cecil Howell" <ce***@ceciltech.com> wrote in message
news:65**************************@posting.google.c om...
"Scott M." <s-***@nospam.nospam> wrote in message news:<OZ*************@TK2MSFTNGP12.phx.gbl>...

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

Nov 22 '05 #8
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!
--
Dennis in Houston
"Scott M." wrote:
If that is the case, then what is the advantage of the GAC?
"Cecil Howell" <ce***@ceciltech.com> wrote in message
news:65**************************@posting.google.c om...
"Scott M." <s-***@nospam.nospam> wrote in message

news:<OZ*************@TK2MSFTNGP12.phx.gbl>...

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


Nov 22 '05 #9
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" <De****@discussions.microsoft.com> wrote in message
news:5C**********************************@microsof t.com...
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! --
Dennis in Houston
"Scott M." wrote:
If that is the case, then what is the advantage of the GAC?
"Cecil Howell" <ce***@ceciltech.com> wrote in message
news:65**************************@posting.google.c om...
"Scott M." <s-***@nospam.nospam> wrote in message

news:<OZ*************@TK2MSFTNGP12.phx.gbl>...
>
> 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


Nov 22 '05 #10
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

"Scott M." <s-***@nospam.nospam> wrote in message news:<uZ**************@TK2MSFTNGP11.phx.gbl>...
If that is the case, then what is the advantage of the GAC?
"Cecil Howell" <ce***@ceciltech.com> wrote in message
news:65**************************@posting.google.c om...
"Scott M." <s-***@nospam.nospam> wrote in message

news:<OZ*************@TK2MSFTNGP12.phx.gbl>...

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

Nov 22 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Simon Wallis | last post: by
26 posts views Thread by Lasse Edsvik | last post: by
2 posts views Thread by George Durzi | last post: by
6 posts views Thread by Terrance | last post: by
reply views Thread by Z | last post: by
6 posts views Thread by Piotrekk | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by kermitthefrogpy | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.