(1 item) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(6 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(4 items) |
|
(2 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(5 items) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(8 items) |
|
(2 items) |
|
(7 items) |
|
(2 items) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(3 items) |
|
(2 items) |
|
(2 items) |
|
(8 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(6 items) |
|
(1 item) |
|
(2 items) |
|
(5 items) |
|
(5 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(16 items) |
|
(10 items) |
|
(27 items) |
|
(15 items) |
|
(15 items) |
|
(13 items) |
|
(16 items) |
|
(15 items) |
Chris Sells recently wrote an article suggesting that we should avoid the GAC. I think in general this is good advice, but I think there are items missing from his list of reasons to use the GAC. He mentions critical bug fixes, and sharing types between seperately deployed assemblies (mostly for remoting).
I was originally going to post this in Chris's comments, but once again my verbosity got the better of me, and this message got large enough that I decided to put it up here instead.
Here are some more reasons:
Making standard components part of the environment. If it weren't for the GAC, how would you use system
components? Would you embed a copy of System.Windows.Forms.dll in every application you
install?
On the face of it, this might seem like a feature that is there only for Microsoft's benefit, and therefore something that didn't require them to expose the GAC as anything more than internal CLR magic providing special treatment for the assemblies making up the FCL. However, there are scenarios in which this is useful to parties other than Microsoft.
Lots of corporations put a load of extra software onto their desktop PCs. I've worked in many places where a
'standard build' for PCs would include many components that the company wanted to have deployed ubiquitously but
which are not part of the standard Windows install. For example, a lot of companies put the .NET Framework onto all
their PCs, to enable things like no-touch deployment. If you're doing that, you can also put stuff in the GAC at the same
time. This enables application developers in the company to just presume that certain company components are always
there. For small components, this may not be worth the gain - you can just deploy them to the web server alongside the
application. But consider some of the UI libraries available in .NET today - these can be vast. (And some have non-trivial
installation procedures involving NGEN.) If you've bought a sitewide license for [insert your favourite control vendor
here]'s toolkit, it might make great sense to make it a part of your standard desktop build. At that point, the GAC is a good
place to put such things, because then developers can just use these components without having to worry about
deploying them, any more than they would have to worry about deploying System.Xml.dll.
Load time for strongly-named assemblies. This is actually a big deal for a lot of GUI applications - the time between launching an app and being able to use it can be annoyingly large, and is an area that tends to need a lot of work to keep users happy. The gulf between CPU speeds and hard disk speeds gets ever greater, so the amount of stuff that has to come off disk is almost always the limiting factor for startup times.
Why does the GAC have an impact here? The signature for an assembly is checked when it is added to the GAC, and is never checked again.(The thinking here is that to modify the contents of the GAC you need to have admin privileges. If a malicious party has obtained admin privileges, all bets are already off - the machine is no longer yours, so checking signatures is pretty futile at that point.) But for an xcopy-deployed assembly, the signature must be checked every time. Checking the signature involves reading every single byte in the file - the whole thing has to come off disk before any part of it can be used. By contrast, assemblies in the GAC can be demand-loaded.
Working set in ASP.NET systems. I almost didn't put this one on because I think it won't apply in a lot of cases, and in the areas where it is applicable, it offers marginal benefit. But for the sake of completeness I may as well mention it. (For the system DLLs it is actually hugely significant. But again, it's one of those things they could probably have fixed by special casing system DLLs if there were no GAC.)
The JIT compiler treats assemblies in the GAC differently from local assemblies in ASP.NET. GAC assemblies are JIT compiled in such a way that the code can be reused across AppDomains. But any other assemblies get their own AppDomain-specific JIT compilation. This means that if the same component is in use in 4 different web applications, 4 copies of any code in use will be loaded if it is xcopy deployed. This goes down to 1 copy if you deploy it in the GAC, thus reducing the working set of the server.