Global Assembly Cache(GAC) Hell

After having worked on a project involving heavy use of the Global Assembly Cache, I would like to tell you that using the GAC can be very frustrating. We had a solution that had several projects within the solution. Many of these projects referenced 1 project (utility project) which did a lot of the work which we could reuse.
 
Problems that occurred
 
I have seen DLLS added to the GAC that you can't remove - very frustrating. I have seen registered DLLs into the cache - verified everything is there ok using ILDASM only to find the DLLs are no longer in the GAC.
 
Strongly Naming the assembly
 
When doing this make sure you get the directory slashes \\ correct within the assembly file (assembly.cs). - if not you will get errors whilst the code is looking for the .snk file. If you get errors that leave you scratching your head - the best bet is to remove the .snk file and start over.
 
Project References
 
Also, be careful and watch where you build projects as the referenced DLLs can easily be built to the development instead of the release folder - sometimes even when you specify the release folder. This can be very, very frustrating.
 

Conclusion

 
My conclusion on using the GAC was to only use it if you really need to as it isn't the 'end of DLL hell' as first thought. Also only use it if you are using a DLL that is shared by other projects. Don't put it in the GAC if you don't have to.


Similar Articles