GAC (Global Assembly Cache) Versus Local Assemblies

function OpenWin(url, w, h) { if(!w) w = 400; if(!h) h = 300; window.open(url, "_new", "width=" + w + ",height=" + h + ",menubar=no,toobar=no,scrollbars=yes", true); }

Deploying any .NET application, or any .NET assembly for that matter, requires determining where the physical assemblies will be installed. One of the major advantages of the .NET platform is the capability for xcopy-style deployment of applications and components.

Note

For those of you who don't remember the days of DOS, xcopy-style deployment means to simply copy the application and its dependencies to a target destination. No registration of components is required, except changes to the operating system itself. In Microsoft's words, it just works.


With classic COM, all COM servers require registration before the COM object can be used by client applications. This registration process involves creating entries within the registry that identify the location of the COM server along with the various co-classes, Prog-Id's, and version information. The various entries are used by the COM runtime to locate and create an instance of a particular COM server co-class.

With .NET, there is no need to register assemblies for use because the runtime searches specific locations to locate the required assemblies for any given .NET application. The runtime first searches the directory containing the client application and then, if it's not found, continues the search using the system PATH environment variable and the Global Assembly Cache.

The question still remains, should the assemblies be located within the application directory or within the Global Assembly Cache? The answer to this question depends on the intended use of a given assembly. Application-specific assemblies should be stored within the application's home directory, whereas system-wide assemblies, or assemblies that will be used by multiple applications, might be better located within the GAC. In addition, to provide side-by-side versioning of assemblies, GAC deployment is necessary. The next section explores component versioning and describes side-by-side versioning.

Assembly Versioning

Versioning ofcomponents, or DLL hell as it is often referred to, has always proven to be somewhat troublesome in nature. One of the design goals of .NET was to enable assemblies to run side-by-side based on version. This versioning system allows assemblies to be updated without breaking existing clients who depend on an earlier version of the assembly.

The only caveat about supporting versioning is that the versioned assembly must be signed. That is, a public-private key pair that identifies the assembly must be provided. The process of signing an assembly is covered in the .NET SDK documentation, as well as other books, including C# and the .NET Framework, by Sams Publishing.



    .NET Windows Forms Custom Controls
    User Interfaces in VB .NET: Windows Forms and Custom Controls
    ISBN: 1590590449
    EAN: 2147483647
    Year: 2002
    Pages: 74

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net