Hansleman's List: The GAC

More from Scott Hansleman's list of what great developers should know: "What is the GAC? What problem does it solve?" The Global Assembly Cache allows multiple versions of an assembly to exist and be used side-by-side with each other. Assemblies must be strong-named, then registered against the GAC. (Side note: Strongly-named assemblies stored outside the GAC require validation each time they're loaded. GAC-registered strongly-named assemblies only get validated when they're installed, so there's a performance gain by using the GAC.) According to Serviced Component Example from the .NET Framework Developer's Guide, assemblies for server apps must be GAC'd, along with any dependent assemblies they rely on. This is because assemblies in the CAG can't use dynamic registration. While the GAC may sound like it gets rid of the DLL Hell problem with older versions of Windows (different versions of the same-named DLL scattered all over a system, thereby wreaking more havoc than a baby loose in the cat food), the GAC merely shoves off DLL Hell issues to the developers responsible for building and deploying the software. Dependency issues can cause significant heartburn, as does the policy of how to handle publishing of version updates. Two good blog posts talk about this. The first, from Hansleman himself post from Hansleman himself talks about how developers get impacted. The second post, from Alan Shi, talks about updating GAC-registered assemblies and has some very good discussion in the comments.