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 which 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.

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 which 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 which leave you scratching your head - 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 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.