To GAC or not to GAC, that is the question

  • Thread starter Thread starter Wayne
  • Start date Start date
W

Wayne

During building of one of my applications for deployment it occurred to me
that I was using a common assembly, that most of our future applications
will be using. So I started to wonder if the assembly shouldn't be placed
into the GAC.

I currently have the task of deciding if our common assemblies should reside
in the GAC or should we deploy the assemblies with the application and have
them reside in the application directory. Or some combination of both
depending on the situation, with knowing that if assembly A goes in the GAC
it always goes into the GAC, and if assembly B is private it will always be
private.

What I would like to get as a response is other peoples experience with the
GAC, why to use it and why not to use it. I understand how it works in
theory, but experience is a much better teacher than theory.


Thanks
Wayne Sepega
Jacksonville, Fl

"When a man sits with a pretty girl for an hour, it seems like a minute. But
let him sit on a hot stove for a minute and it's longer than any hour.
That's relativity." - Albert Einstein
 
Since you will have multiple applications using the same DLL, the GAC would
be the right place for it.

Annoyances with the GAC are things like having to strong name your
assembly - which then means recompiling anything that uses the dll when the
version changes. You also might run into issues with multiple version of the
same DLL being in the GAC, and figuring out which one your app is trying to
use, etc.

So in situations when the DLL will only be used by one app, it is overkill
to place it in the GAC. However, in your situation it is probably worth it,
so you don't have multiple copies of your dll floating around the machine.
 
Marina said:
Since you will have multiple applications using the same DLL, the GAC
would
be the right place for it.
Click to expand...
I don't agree that this is a hard rule. Having multiple copiues of a DLL
"floating around on the machine" may be *just* what you want. Disk space is
cheap. Maintaining complete and total independence between two applications
is also valuable. The simplicity of private assemblies is also nice.

Imagine a scenario where you have 2 apps, both using "the same DLL".
Except the 2 apps get updated and re-deployed at different, independent
intervals. Would you want to run the risk of an update of App A causing
changes in behavior in App B, based on a shared GAC'd DLL, just to save
200kb of disk space? Oh, you're going to rev the version number of the
GAC'd assembly, you say? Then why GAC it in the first place?? If each app
gets its own version, then there is no benefit to the GAC, and there is a
big management cost.

In general, people tend to over-use the GAC. My advice is to Keep it
simple. Avoid the GAC unless you really really need it.

http://www.gotdotnet.com/team/clr/when_to_use_the_gac.aspx

-Dino
 
Marina wrote:

Annoyances with the GAC are things like having to strong name your
assembly - which then means recompiling anything that uses the dll when the
version changes.
Click to expand...

Isn't this handled through publisher policies?
 
Well, theoretically, if you updated your DLL, you would want it to available
to all the apps that use it. If this is so, now you have to go searching
for all instance of this DLL on the machine, and find all of your apps, and
update each one of these - instead of just updating it in the GAC and being
done with it.
It really depends on the situation you are in.
 
I guess it can be, now there is another level of complexity and another
thing you have to do to make the transition to the new version - and another
opportunity for something to go wrong and not work.
 
I tend to side with Dino - don't use the GAC unless you need to. You should
consider the following:

How are your assemblies installed?
What versioning policy will you use?
How will the assemblies be updated?
How do you plan to use Publisher Policy?
Is the assembly really shared amongst many different, unrelated
applications?
How will the assembly evolve? Once you put it into the GAC you may be stuck
with it living there. If you leave it private now you will always have the
option of putting into the GAC in the future.

One problem with using the GAC are that you cannot xcopy deploy your
assemblies - a special routine to install the assembly into the GAC is
needed. Another potential problem is that if you update the assembly in the
GAC and force all applications to use it you run the risk of breaking a
working application.

Hard disk space is cheap - avoiding unnecessary duplication is not a valid
reason to install into the GAC.

Bottom line for me - the GAC has the feel to me of the NT registry - it was
originally touted as the best place to store all app-specific data, but in
practice it turned out to be a nightmare and led to DLL hell. I think there
will be a tendency to put all sorts of assemblies into the GAC that have no
business being there. IMO only system level shared assemblies that undergo
rigorous regression testing for backwards compatibility should go there
unless there's a darn good reason for ignoring that constraint.

Dave
 
Back
Top