title: Revisiting GAC Installations
body: <p>This one goes round and round I know but I can't seem to find a satisfactory response.</p>
  
  <p>Should assemblies go in the GAC? These questions: <a href="https://stackoverflow.com/questions/498361/when-and-when-not-to-install-into-the-gac">when-and-when-not-to-install-into-the-gac</a> and <a href="https://stackoverflow.com/questions/23578/what-are-the-advantages-and-disadvantages-of-using-the-gac/23598">What are the advantages and disadvantages of using the GAC</a>, address exactly that but the answers are very much "it is recommended that..." or "you should only ...".  Why???</p>
  
  <p>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 the past with the GAC supporting side by side installation of different versions of the "same" assembly?</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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?</p>
  
  <p>Thanks for helping me see the light.</p>
  
  <p>Dan</p>