Tuesday, February 15, 2005

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?


Jake Good said...

my $0.02

Why not create a folder in your project that references the DLL , name it something like ReferencedAssemblies... then when you check it in or out, you have fresh copies of the DLL and references in your projects..

If you know you're going to update the DLL, then compile the DLL, check out the dll , copy it to the folder, check in and send a message out to get latest...

Somewhere you have to draw the line between ease of development and ease of deployment... you CAN switch eventually.. DLL references aren't as big of an issue as core framework changes... just remember that :)


Mike H said...

First, I think it depends on how related the dependent projects are. If the dependent projects are all a part of the same system, then you could probably keep using project references. Otherwise if they are not a part of the same system, use the GAC.

I don't share your concerns about difficulties using the GAC. Sure there is some overhead in getting it started, but once it's done it's done.

Problems strong naming/signing assemblies? Never had that problem. Need to move a web app to a different server? If the web app is packaged up in a deployment project then it's easy because the referenced web controls will be included as a dependency in the package.

I'd recommend extracting the common web controls into their own project, then create a setup package for them. Treat the web controls as their own system. If another developer or project needs them, then they'll just need to run the setup package to install them into the GAC. The setup package can also automatically create a local machine copy for developers for file referencing. We did all that at Nextel Partners and it worked great. The setup package installation could be included as part of an on-demand or overnight build process if necessary.

The downside is that you now have a separate web controls system to manage - but if they're truly "shared" then you'll realize the long term gains. There will be continuous short-term problems by trying to get your shared assemblies to act as non-shared assemblies with project references, in my opinion.

This MSDN article describes in detail how to structure systems, solutions, and projects with shared or project-based assemblies:


stefan demetz said...

avoid GAC hell

ashley said...

Found a lot of useful info on your site about Msdn - thank you. Haven't finished reading it yet but have bookmarked it so I don't lose it. I've just started a Msdn blog myself if you'd like to stop by

Roberto Iza Valdes said...
This comment has been removed by a blog administrator.
Roberto Iza said...
This comment has been removed by a blog administrator.