To GAC or not to GAC?
Chris and Ted are going back and forth on whether to use the GAC. Chris' conclusion is:
“1. Fixing critical bugs without touching the affected apps (and without breaking anything!) 2. Sharing types at run-time between assemblies deployed separately “ [1]
Ted's is:
“the GAC isn't for making silent upgrades of libraries that apps depend on--it's the side-by-side versioning story, first and foremost, that demands the GAC's existence. Yes, I could go ahead and put those third-party libraries into my private application directory, but why? If I start looking to bundle everything I depend on as part of my application's footprint, why not include certain key libraries like KERNEL32.DLL or USER32.DLL, as well? If we take this "avoid the GAC" idea far enough, we're back to Joel's request for a static linker again, and I just don't want to see us go back to the pre-Win16 days all over again.“ [2]
Well, there is at least one very good reason to always GAC DLLs: ASP.NET doesn't support strong named assemblies. There is this nasty little bug whereby if you place strong named DLLs in your bin directory, indexing services will lock up the DLL every once and a while and the web app goes down. However, outside of that (or other similar scenarios that require GAC usage to function), there really isn't a good fixed definition of when to use the GAC. The simple fact is that the GAC's sole purpose of existance is to ease application matinence. Things like System.Xml.Dll belong in the GAC because when you have 500 .NET apps on your machine, applying patches to every one individually would be a nightmare (even if you did patch every copy, if someone installed a new .NET app after you applied the patches, its DLLs would be out of date). Since the GAC is to aid in application matinence, you should only GAC something when it is actually going to save you time. In the situations where GAC'ing is optional, GAC'ing is only useful when the standard machine your app is going to be deployed will have a significant number of applications installed that reference your assemblies. As a result, you probably will never run into a valid reason to make use of GAC'ing unless:
1) You run into a scenario where GAC'ing is an obvious requirement.
2) You write a lot of apps for the same organization.
3) You work for a very large software company.
[1] http://www.sellsbrothers.com/spout/#Avoid_the_GAC
[2] http://www.neward.net/ted/weblog/index.jsp?date=20040330#1080641913997