Just my opinion...

If you do a search on “to GAC or not to GAC” you’ll get mixed messages with a bias towards “not to GAC”.  I couldn’t disagree more strongly with those who urge you not to use the GAC “unless you work for Microsoft, and then only if you’re working on the .NET Framework” (quote not linked to save the writer the embarrassment).  No need to sugar-coat this one…  The folks making those recommendations clearly know very little about development on the .NET platform.  The only generosity I can muster for these people is perhaps they’ve never worked in an organization with more than 2 developers and have never had to write a shared assembly.  Perhaps we can blame Microsoft for having promoted the term “xcopy deployment”.  Perhaps they never lived the Win16 to Win32s to Win32 to COM transitions. Perhaps these people are the village idiot.

Some background first…

What is the GAC?

GAC stands for the Global Assembly Cache.  Without going into excruciating minutiae, the GAC is simply a repository of shared assemblies, managed by the operating system, and used by the Common Language Runtime (CLR) to resolve references to shared code.

How does the CLR resolve assembly references?

For a full description of how the CLR resolves references, look at the MSDN article “How the Runtime Locates Assemblies”.  The basic steps are these:

1. Determine the correct version of the required assembly.
2. Has this assembly already been bound and cached?
3. If the assembly is not already bound, look in the GAC.
4. If the assembly isn’t in the GAC, check the PATH.

Actually, “check the PATH” is grotesquely over-simplified.  The actual process is called “probing”, for full details on that process look at the MSDN article “Step 4: Locating the Assembly through Codebases or Probing”.

So for all of the pundits out there that think that just dropping your assembly into the application directory is all there is to it, I’d suggest a little reading.  As you can see, the application directory is actually checked AFTER the GAC. Unless an assembly reference has already been “bound”, the GAC is the first place the CLR will look to attempt to resolve the reference.

“to GAC”?

If we’re talking about an assembly that is shared by more than one application in your application suite then the answer is a resounding yes.  Will you ever need to maintain two versions of the same assembly in the deployed environment?  If so, another resounding yes.  Will your application implement a dynamic loading mechanism via a configuration file to load a “snap-in”?  If not yes, it’s certainly a possibly.  After all, if I’m going to specify a code base via a configuration file and call System.Reflection.Assembly.Load or System.AppDomain.Load myself, then I’d like to have the option of specifying a fully qualified assembly name.  Then again, I may want to circumvent the “standard” binding order from above so that I can implement a sort of “drop-in” deployment and implement the code to look in the application directory first.  Either way, the option of using the GAC is still totally valid contrary to prevailing net wisdom.

“not to GAC”?

There are obviously situations where you don’t want the added deployment overhead of using the GAC.  Using the GAC isn’t free after all, you need to setup your development environment to place your new assemblies in the GAC, remove the last compiled version (if you’re so inclined), etc.  I never said that there was no price to pay.  Are you deploying a “resource assembly” that is only applicable to one application?  Then don’t put that in the GAC, there’s no compelling reason to do so.  Is the assembly your deploying shared at all?  If not, then don’t put it in the GAC.  Again, no compelling reason to do so.

If you don’t want to use the GAC based on some bizarre “principle”, then use Linux or some other platform.  (Yes, one developer once told me he wouldn’t use the GAC out of principle. Huh??)  After all, I love Linux and other platforms as much as the next guy.  Stop proclaiming that the “GAC is evil” (Again, direct quote from a developer) unless you know what you’re talking about.

The point I’m trying to make is that “to GAC or not to GAC” is a more informed decision than many of the absolutist “not to GAC” stances you’re going to read out there.

Nine-ball is rotation pool, the balls are pocketed in numbered order.  The only ball that means anything, that wins it, is the 9.  Now, the player can shoot eight trick shots in a row, blow the 9, and lose.  On the other hand, the player can get the 9 in on the break, if the balls spread right, and win.  Which is to say, that luck plays a part in nine-ball.  But for some players, luck itself is an art.

Uncredited voiceover by Martin Scorsese for the movie “The Color Of Money“