Gallery

Managing assemblies

Posted on 20 Mar 2006 at 12:18

Thomas Lee delves deeper into the world of .NET assemblies and their deployment management in the enterprise

The GAC is stored as a series of folders arranged below the %systemroot%\assembly folder, and if you use Explorer to view this folder tree a shell folder extension kicks in to display a friendlier view of the GAC. Alternatively, you can use cmd.exe or Monad to explore the GAC in more detail. Using the Explorer interface, you can drag and drop strongly named assemblies into the GAC, but alternatively you can manage the GAC using the gacutil.exe command included with the .NET SDK2 SDK.

The purpose of the GAC is to enable you to share components among many applications, but at the same time, by using the GAC, you limit your flexibility to change a particular assembly, as there might be multiple applications depending on it. In general, the GAC tends to be used mainly for system-type assemblies with very generic functionality. The GAC is a great idea for core system assemblies, such as the CLR itself, and if you're using a large .NET-based application suite there may well be some common assemblies you can also install into the GAC.

From a deployment point of view, one great feature of .NET is what's known as Xcopy deployment, which means that because an application's assemblies all live in the same single folder, you deploy your application simply by Xcopying these files over to the client machine. In the case of our client application and the external DLL, you'd simply Xcopy them to the target folder on a user's machine and possibly add a shortcut to the main application file. Deployment no longer requires COM registration or any updating of the Registry, which makes deployment much simpler. And with .NET 2's ClickOnce Deployment, deployment becomes simpler still. I'll be covering ClickOnce in more detail in a future column.

The best way to install modules into the GAC is to use an installer package that does it for you, which makes life a lot simpler - just run the installer program and that's it. You can, of course, manage the GAC yourself, adding an assembly to the GAC either by dragging and dropping from Windows Explorer or by using the gacutil.exe utility with the /I switch. For example, to add maths.dll to the GAC and check that it's been installed, the command lines would look like this:

[C:\PCPRO]: gacutil /i maths2.dll

Assembly successfully added to the cache

[C:\PCPRO]: gacutil /l maths2

The Global Assembly Cache contains the following assemblies:

maths2, Version=1.1.1.100, Culture=neutral, PublicKeyToken=0285050ae0693328, processorArchitecture=MSIL

Number of items = 1

[C:\PCPRO]:

When GACUTIL completes successfully, as above, the assembly is now in the global assembly cache and can be accessed by any application that needs this specific DLL.

When the .NET CLR needs to find this DLL (that is, whenever you execute a client application that calls this DLL), it first attempts to load the assembly from the GAC. Only if it's not found there will the CLR look for the DLL in the client application's own folder. You can demonstrate this order by deleting the DLL from the local directory and re-running the client.exe application, a sequence that looks like this:

[C:\PCPRO]: ls

Directory: Microsoft.Management.Automation.Core\FileSystem::C:\PCPRO

Mode LastWriteTime Length Name

---- ------------- ------ ----

-a--- 2/3/2006 2:19 PM 314 client.cs

-a--- 2/4/2006 4:12 PM 3584 client.exe

-a--- 2/4/2006 4:11 PM 311 compile.bat

-a--- 2/3/2006 3:25 PM 270 maths2.cs