You want to know the pros and cons of registering your DLL assemblies in the GAC.
The pros of registering are 1. The .NET runtime finds GAC assemblies more quickly and loads them faster because it doesn’t have to check their integrity. 2. Assemblies in the GAC are protected from accidental deletion because only an administrator can access the GAC directory. The cons of registering are 1. More complicated deployments since you can’t rely on XCOPY to automatically register the assembly for you. 2. Having to uninstall the previous version from the GAC each time you recompile.
You don’t want to use the GAC if your sole purpose is to share types among different applications; there are better ways to accomplish this goal. You can share an assembly, including private ones, among different applications if all applications’ executable files are deployed in the same directory. Or, using a different approach, you can reference a strong-named assembly that is located outside the application’s main directory by using the element in the application’s configuration file.
There are ways to make GAC registration simpler. There’s a utility named Gacutil that comes with the Windows SDK and is automatically installed with Visual Studio. If you’re not a Visual Studio user like me, you can simply get it with the Windows SDK. You can configure Gacutil to run as a post-build event. In Visual Studio, you can configure the command to run in the Project Properties dialog box. Otherwise, you can add it to the .csproj file like so:
<Target Name="AfterBuild"> <Exec Command="Path to SDK\...\Gacutil.exe" /i $(TargetPath)" Condition="" /> </Target>