included. Each version can therefore exist within the same location and be called without requiring subsequent versions to preserve code entry point locations as usual. Windows Explorer allows the drag-and-drop installation of assemblies into this folder only if they would otherwise be permitted to be installed from the command line. A calling application may specify a version of an assembly when referencing it, so the run-time can simply refer to the filename to use the correct one. Pitfalls The Global Assembly Cache mechanism helps to avoid older DLL hell, but it still has some drawbacks, such as: By default, applications will only run with the version of the .NET Framework used to compile it, which can cause the application to fail on machines with newer versions of the .NET Framework installed — even when the application would normally run properly with the newer version. It is sometimes necessary to use conditional compilation if some of the core .NET calls (used in the application) are only supported for some versions of the framework. .NET applications that rely on native code risk incompatibilities, even with the GAC mechanism. Every assembly that is added to the GAC must be strongly named. The process of making an assembly "strongly named" can be quite painful in some situations. For example, if an assembly depends on another assembly that is not strongly named, it cannot be registered in the GAC. In cases where the code of the third-party assembly is not in the programmer's possession, transforming the assembly to be strongly named can in fact be impossible. Browsing for files using standard Windows APIs doesn't allow selection of DLLs located under the "assembly" folder when Explorer is showing the user-friendly view of the GAC. See also Download Cache .NET Framework References External links .NET Framework Developer's Guide Global Assembly Cache Tool (gacutil.exe) Demystifying the .NET Global Assembly Cache .NET terminology Common Language Infrastructure Windows administration