Revisiting GAC Installations

This one goes round and round I know but I can't seem to find a satisfactory response.

Should assemblies go in the GAC? These questions: when-and-when-not-to-install-into-the-gac and What are the advantages and disadvantages of using the GAC, address exactly that but the answers are very much "it is recommended that..." or "you should only ...". Why???

A lot of the GAC naysaying blogs seem to date from 5/6 years ago when .Net's star was beginning it's rise. Are we still there now? Surely DLL-Hell is a thing of th开发者_JS百科e past with the GAC supporting side by side installation of different versions of the "same" assembly?

Let me flesh-out my concerns. We have a growing suite of web apps (5 so far). These are, at their core, extensions to a third-party application via API calls and database extensions. Obviously, therefore, all these apps share a great deal of code in common and we are developing a new set of core shared libraries to improve our quality, maintainability, etc.

Surely I want this shared functionality installed once and shared. All the arguments about opening a maintenance nightmare seem based on some world of poor discipline. If you break the ABI then bumping the AssemblyVersion is sufficient to keep your existing apps working.

Is the GAC truly a honey trap for the unsuspecting? Am I being naive? Am I being unnecessarily harsh when I dismiss arguments citing the loss of 'XCopy' install as being lazy whinges? Or is it getting a bit "Religious" and I should just go with what seems right?

Thanks for helping me see the light.

Dan

I personally have never installed any assemblies directly in the GAC (except as a purely academic exercise). I've heard the argument before about using an assembly from a centralized location that is accessed from several applications, and while that seems somewhat attractive, personally, it's not worth my time. Computers come with 320GB of hard disk space these days... my measly 160K assembly isn't going to make a dent in that, even if it's copied 5 times. (Of course, some could argue the "problem of the commons"... you know: "if every developer thought that way....", but I digress). The main reason I choose not to do this is because one particular application might rely on the assembly in one way, while another might rely on it another way. While in an ideal world, updates to this assembly should never affect the applications that rely on it, in reality, it often does. If I'm fixing a problem with an assembly because a particular application has issues with it, I'm unwittingly affecting the other applications that rely on that particular assembly. On the other hand, some might argue that this kind of situation makes us better programmers and makes our GAC-Shared assembly more bulletproof. That's great, but my job as a programmer isn't primarily to make myself a better programmer, but to write programs that work, and doing so, I will become a better programmer.

So what's my vote? Keep away from the GAC. Let each application rely on the version of the assembly they're built to rely on. A bug exposed in that assembly by one application may never show up in the other applications, because they're using the assembly differently, so leave them be and you won't have to regression test 5 distinct applications every time your shared DLL gets patched.

I use following weak strategy.
Use GAC - when different programs use shared assembly + versioning.
Don't use GAC - always.

any comments are welcome.