Anyone, who works with Visual Studio knows that referencing an assembly in the project paves the way towards code reusability. On the other hand, in order to achieve this same thing while in the production environment, we need to install assemblies in the Global Assembly Cache(GAC) . There are a lot of advantages of using GAC as a shared repository, but this post is not an effort towards that as there are a bunch of articles already available on the internet. What I want to share here are the concerns which I have listed below, which may come to minds before deciding on to go down this route of using GAC for our projects.
- Let's consider a scenario where we want to share a DLL say ExceptionHandler.dll between two applications HelloWorld and HelloUniverse. We have signed the assembly (DLL) using a strong name key and installed it in the GAC on the production server so that it would be utilized by both the applications. We have deployed the applications where they seem to be accessing the DLL from GAC. So far so good. Now assuming, the ClassLibrary project (ExceptionHandler.dll) is part of a solution which also contains either of the applications let's say HelloWorld, there is a possibility while building the application someone from the team can unintentionally do a FULL Debug of the solution, leaving the version number (build + revision) changed. Now, a week later our HelloUniverse application which is also pointing to the same DLL project undergoes a change and is deployed alone to the server assuming it will pick the same DLL that was deployed earlier and eventually he gets this:
Could not load file or assembly 'ExceptionHandler, Version=184.108.40.206, Culture=neutral, PublicKeyToken=a2e77a5f9a0ce598' or one of its dependencies. The system cannot find the file specified.
- Let's assume for the time being that the situation above will never happen as there is no room for an unintentional behavior in your team. But, You will agree with me on the fact that using GAC as a shared repository motivates one towards having multiple versions of the same DLL as there is a native support for that. When it was designed to overcome problems like DLL HELL, then why not to use it. It is a very valid point to support applications still relying on the older version. One of the concerns is that if I come back to my GAC after a year, I will find it cluttered with multiple copies of the DLL with same name but with different version numbers.
- If the above scenario proves to be true, will it not become a manageability issue to keep a track of assembly versions on both production as well as development ends considering we have a reasonably big number of applications.
I am in no way trying to discourage anyone from using GAC, rather giving my point of view on the issues that get in our way whenever we decide to use it as a shared folder for assemblies. I may be wrong and may be these issues will never come for someone or they may not be a big concern for a few, but I believe sometimes it is good to be paranoid of implementing new technology or suggesting it over an existing one. This may give us an opportunity to think left, right and center before we get our hands dirty with it.
Before I finish, I would like to briefly comment on the way I believe above issues can be addressed. For the first point, each application or set of applications can point to their own copy of the shared DLL leaving no room for errors. The second and the third issues can be tackled by building applications targeting a single stable version of DLL at some point in future, which then can be replaced with all of the older DLLs with multiple versions in the GAC.