To GAC or not to GAC, that is the question...

In a project with which I am involved, we have a .dll that holds common web controls. This .dll is shared by multiple web applications, however they all reside on the same server. Originally, when this .dll was shared by two web applications, we had both web projects in one solution and used project references. Then, when we deploy, we can just XCOPY the web applications’ files and bin folder. Viola.

Now we have some SharePoint sites that we want to share the common web controls. We can follow our previous architecture, and add the team sites to our solution and use project references. We can also create a new solution for the team sites, but add the existing controls project from SourceSafe to our new solution. In the latter scenario, we would have one master copy of the controls project in source safe.

However, I am not thrilled with the prospect of using XCOPY to create another bunch of instances of the controls .dll on the web server. I see an advantage that when one of our web applications goes live, we won’t have to worry about future changes to the controls .dll affecting our live web application. Having multiple copies of the same .dll on the same web server seems like a worse idea when I consider what we have to do through to address a bug fix or try to upgrade something, especially if we end up with different versions of the controls .dll in each web application’s bin folder.

I was noodling this issue and thought, “Hey, why not use the GAC? The end of .dll hell!”. All of the web applications will be on the same web server, and the GAC was created for just that purpose, right? I can still opt to have multiple versions of the controls .dll in the GAC if I so choose, or I can keep one version and have only one place to maintain it.

I have used the GAC in the past when dealing with a WinForms application, and after the initial set up, things went swell. Our team did create a utility to rebuild our GAC .dlls out of SourceSafe on demand, and we also agreed on a local structure where we published our debug .dlls so we could share each other’s projects without any headaches. We completely abandoned project references all together. There was some overhead, but I never had to restart VisualStudio because "a reference is being used by another process."

In my current situation, I am a little hesitant to use the GAC because I know that if one of the web applications gets moved to another web server, things will break. I have also read some articles where people have had trouble with strong naming and signing their assemblies. I know that changing course now will also require overhead to set it up so my teammates and I are able to work on the same projects without stepping on each other’s toes, and without requiring a manual copy of new versions of .dlls from SourceSafe to our local GACs. Putting our assemblies in the GAC will also make it difficult for another member of my company to quickly get my solution from SourceSafe and be able to compile and run my code (like our graphic designer). They would have to run an install or manually register the required .dlls to the GAC before their code would compile.

I am also still not crazy about the many versions of one .dll on the same web server, just asking to be out of synch with each other. And how will we manage which version is being used on each web application when we will keep one copy in SourceSafe?

I am undecided what to do. Do you have any experience, positive or negative, with using the GAC for web deployments? What would you do in this situation?