Managing the Global Assembly Cache

for RuBoard

One of the advantages to working with ASP.NET is that code you write is compiled for you seamlessly and transparently . This is a useful feature; however, you may find yourself in a situation where you want to reuse the functionality found in one application in another. You may even want to share software functionality across two radically different types of applications. A Web application and a thick-client application on the Windows desktop, for example, might share a common set of code that performs a set of operations specific to your business. You can accomplish this through the use of components. (Because corporate application developers often use components to share standard business-specific code functionality across multiple applications, components are sometimes also referred to as business logic components.)

A component is a piece of software designed to be used by another piece of software. Windows has had components throughout its history. Initially, components were packaged in the form of procedural dynamic link libraries (DLLs), but for ease of programming and interoperability, application developers eventually came to package their DLLs in the form of Component Object Model (COM) libraries. Although these libraries do provide the capability to reuse code, they also suffer from limitations that .NET attempts to overcome .

As we've mentioned earlier in this book, one of the major problems with COM DLLs is that COM requires you to register a DLL on a machine before you can use it. This means that with a COM component, you can have only one version of a component installed on a machine at a time. This is a problem because there's no guarantee that future versions of a given component will provide the same functionality as the version you deploy your application with. (This is one aspect of the problem known as "DLL Hell.")

NOTE

Components and assemblies aren't technically the same thing. However, for the purposes of this (and most) discussions of components in Microsoft.NET, they are pretty close to the same thing. So we'll refer to components and assemblies more or less interchangeably in this section.

Microsoft.NET attempts to get around DLL Hell problems by encouraging developers to deploy dependent components in a subdirectory under their application directories. For ASP.NET applications, this means that components will be installed in a subdirectory called \bin under the application directory. But a problem occurs here. Component code that is accessible based on its physical location in the file system can't be shared across multiple applications. You could deploy multiple copies of the component to each application that required it (in fact, in the .NET world this may be preferable for compatibility reasons), but you may find yourself in a situation where you develop a tool or library whose functionality is so generically useful that you may want to provide access to that library in a global fashion.

Microsoft.NET provides a way do to this, called the Global Assembly Cache (GAC). Components that are installed into the GAC are available from any .NET application running on that computer. (Note that this includes other types of .NET applications, including Windows Forms applications, not just ASP.NET applications.)

You can install a component into the GAC using a command-line tool called gacutil. To install a component into the Global Assembly Cache, use the command

 gacutil -i mycomp.dll 

in which mycomp.dll is the name of your component. Note that this command will only work if the assembly has been signed; you sign an assembly using the sn.exe utility.

NOTE

You can create .NET components in Visual Studio. To do this, create a project using the "Class Library" project type.

To uninstall a component from the GAC, use the command

 gacutil /u mycomp.dll 

Be careful when using this command, because applications that rely on the component will break when it is removed from the GAC.

To see a list of the components in the GAC, use the command

 gacutil /l 

You'll see a list of all the components that have been installed on the system. Initially, this list will just be composed of Microsoft.NET assemblies (which you typically don't want to mess with).

Numerous configuration files and attributes can be configured quite easily and in a prompt manner. The Web.Config and Machine.Config files are the two most commonly used configuration files, and any changes to these files can be easily distributed by using the XCOPY functionality.

for RuBoard