Global Assembly Cache
From Wikipedia, the free encyclopedia
The Global Assembly Cache or GAC is a machine-wide .NET assemblies cache for Microsoft's CLR platform. The approach of having a specially controlled central repository addresses the shared library concept and helps to avoid pitfalls of other solutions that lead to drawbacks like DLL hell.
Contents |
[edit] Purposes
There are several reasons to install an assembly into the GAC:
[edit] Shared location
Assemblies that should be used by all applications can be put in the global assembly cache. For example, if all applications should use an assembly located in the global assembly cache, a version policy statement can be added to the Machine.config file that redirects references to the assembly.
[edit] Requirements
Assemblies residing in the GAC must adhere to a specific versioning scheme which allows for side-by-side execution of different code versions. Specifically, such assembles must be strong named.
[edit] Usage
gacutil.exe is the .NET utility used to work with the GAC.
One can check the availability of a shared assembly in GAC by using the command:
gacutil.exe /l <assemblyName>
One can register a shared assembly in the GAC by using the command:
gacutil.exe /i <assemblyName>
Other options for this utility will be briefly described if you use the /? flag, i.e.:
gacutil.exe /?
[edit] Example of use
A computer has two .NET assemblies both named AssemblyA, but one is version 1.0 and the other is version 2.0. Since it is required that both be compiled to a file named AssemblyA, they cannot exist in the same directory within the FAT32 file system. Instead, the virtual file system of the GAC can be used by programs that need to use each version of the assembly specifically.
[edit] Implementation
The GAC as a construct does not actually exist within the Windows OS. It is implemented and managed by the .NET Framework. The folder within %systemroot% named assembly contains all globally-available assemblies with managed filenames so that the version and public key tokens can be 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. 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 specific versions of an assembly when referencing them, so the Common Language Runtime can simply refer to the filename to use the correct one.
[edit] Pitfalls
The Global Assembly Cache mechanism helps to avoid older DLL hell, but it still has some drawbacks, as for example[1]:
- 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" could be quite painful in some situations. For example, if an assembly depends on another assembly that is not strongly named, it can not be registered in the GAC. In cases where the code of the 3rd party assembly is not in the programmer's propriety, transforming the assembly to be strongly named can in fact be impossible.
[edit] See also
[edit] References
- ^ John, Mueller (2005-02-11). "Ten Managed Application Pitfalls that Kill Version Compatibility". devsource.com. http://www.devsource.com/c/a/Techniques/Ten-Managed-Application-Pitfalls-that-Kill-Version-Compatibility/. Retrieved on 2008-01-26.
