Sysadmin Field Notes

December 6, 2005

Here are three reasons to use the GAC.

(For those of you not familiar, the "GAC" is Windows' global assembly cache; a place to put .NET dlls where all apps can get at them, so you only need to load one copy and different versions can be requested)

When you have a large team that works in a distributed fashion, on a bunch of web applications that share some common code and hardware, I don't think the GAC buys you much. In the above, #3 is applicable. However, if the code sharing is small, even if you have 10 copies of a 50k dll, is 1/2 MB memory savings really worth the extra pain?

The pain of either forcing people to migrate at once, or support hard-coded version numbers, or have policies all over the place is non-trivial. The versioning can become a real nightmare. What if you want just one application to use a newer version of the library? It's just a lot easier to manage if the whole app can be xcopy deployed to one place, and if you need to fix its copy, you can.

The GAC is great for commercial software, but it's quite the pain for my purposes. Just because you share code, does not mean that you have to share -instances- of that code. As long as you're not cut and pasting that shared code, using someone else's binary dll is perfectly legit. If you have a thousand web apps, the story might be different.

In fact, versioning all together is a pain for web apps that you control the deployment of. Stick everything at 1.0 and forget about it. Life's too short to have to rebuild just to update some stupid assembly reference when you know you are deploying the right version anyway. If you want a version number, but it in another field in the DLL metadata, but leave the .NET version at 1.0.