Global Assembly Cache (aka GAC) is a Misnomer: How "global" is it?
In every .NET programmer's life, he/she must come to terms with (at least one would hope) the Global Assembly Cache, aka the GAC. Simply put, the GAC is place for strongly named .NET DLLs to be placed so that they may be shared across multiple applications. This provides developers a way to place their DLL once on a machine and have multiple applications using it without the fear of name conflicts or problems with different versions of the DLL. In theory, the GAC should also help avoid Windows programmers every having to remember the days of “DLL Hell” although the term “Assembly Hell” has already been dubbed.
Problem is how global is the GAC anyway? Well there's a simple answer to that question; not global at all. The GAC is only appropriate for machine-wide distributions of DLLs which still makes it a problem for deployment on a enterprise-wide level. In some ways I think that the Global Assembly Cache was named as such because Microsoft is still not over their fixation with workstations being isolated. In today's work place environment however calling anything that only scopes a single workstation “global” is a major lack of understanding of what is going on around you. Maybe I'm paying too much attention to a name which maybe a marketing department made up but in truth this leads to the bigger issue of deployment.
How can one deploy an assembly network-wide? Bad new is it's not “built in”; good news is it's possible albeit jumping through some serious hoops. I think this is something that Microsoft should really consider further development in. Enterprise-wide deployment doesn't seem to be a forte of the Windows platform in general but I think it's in .NET's best interest to find a way around it. Most companies with a reasonable sized network would prefer single point of deployment rather than having to contend with deploying DLLs to each and every machine. .NET doesn't make it easy to deploy your shared DLLs to a shared network drive where they can truly be more global.
This also brings me to the point that the publisher policy that .NET enforces seem somewhat flawed. Who should have the final say in what version of a DLL which I wrote is used by an application, me or the application developer? While I can argue both sides of the coin, I think the real answer is it depends. If I'm using a third party DLL and I don't want to break my application, I should be able to use any version of the DLL I damn well please. If I want to take the risk of having using a buggy old version well that's my prerogative. Maybe I'm not using any feature effected by the bug fix and maybe I just don't have the time to get my code to work with the new version. But what about the corporate world? If one team releases a new version of Foo.DLL which other developers in the enterprise use, shouldn't they have the ability to say "you can't use my old DLL any longer"? A good example of the need for this is if the new Foo.DLL now enforces something such as a fix to a bug that runs the possibility of bringing the network down. This issue came to mind when I first read Applied Microsoft .NET Framework Programming by Jeffrey Richter (if you haven't read it yet stop reading my blog and go buy yourself a copy). At the time I thought “oh well it doesn't effect me” and moved on but I think I'm now seeing why I had to reread the publisher policy section to believe that the author of a DLL had no power in this matter.
These are arenas which I now consider to be a strong weakness in .NET and issues which are important for Microsoft to address. For .NET to ever be a real enterprise application contender deployment and policy issues cannot be thought of as secondary. Smart clients are not the solution for everything and neither are web apps.