Joshua Flanagan

At DevDays-Austin, Stephen Fulcher said “Code Access Security is the most least understood part of .NET”.  I agree.  Especially after reading this article by Keith Brown in the latest MSDN Magazine.

So what is the second most least understood part of .NET?  My vote would be the Global Assembly Cache.  It seems pretty straightforward on the surface: it is a central location to store assemblies shared by applications across your machine.  Ok, so the answer to my title question is easy: use the GAC when you have an assembly that is used by more than one application.  Not so fast.  There are a couple reasons I can think of off the top of my head why this might be a bad idea:

1) To install an assembly in the GAC, it must have a strong name.  When an assembly has a strong name, it is locked down to a specific version number.  Every client application that uses that assembly will be compiled to use that specific version number.  So how do you release a bug fix for your assembly, without having to re-compile all of your client applications?  Not very easily.  In fact, I don't know how to do it.  But I'm pretty sure it can be done.  I vaguely remember reading something about editing an assembly's manifest so that it only requires a “minimum” version number, instead of a specific version.  I will have to research further (feel free to aid my research by letting me know if you have the answer).

2)  Once you start sharing “bits“ between distinct applications, you create a superficial inter-dependency.  If you make a change to the common assembly, it will be reflected in each of the dependant applications.  Put another way, if you wish to make a change to the common assembly, you will have to TEST each of the dependant applications - even if only one of the applications cares about the change.  With the price of hard drive space so low these days, there seems little reason to share actual bits and therefore increase your regression testing responsibilities.  Sharing code is great - designing assemblies to be reusable is great.  But why not store the bits in the private directory of each application and save yourself the testing headache?

3) This may not be a valid reason, as it is purely gossip at this point... but during his DevDays presentation, Michaels Stuart, of Application Block fame, mentioned that he has heard rumors that the GAC will be deprecated in future versions of .NET.  How far in the future isn't clear.  I don't expect it to be gone with Whidbey, since it has already shown evolving signs of life in the PDC builds.

I understand that these are not rock-solid arguments for avoiding the GAC.  You might be able to offer me a rebuttal for each of them.  My point is there is “doubt” about its usefulness, or rather when it should be used.  Others have doubts about it too.  So does anyone have a good answer?  When should I use the GAC?