IanG on Tap

Ian Griffiths in Weblog Form (RSS 2.0)

Blog Navigation

April (2018)

(1 item)

August (2014)

(1 item)

July (2014)

(5 items)

April (2014)

(1 item)

March (2014)

(1 item)

January (2014)

(2 items)

November (2013)

(2 items)

July (2013)

(4 items)

April (2013)

(1 item)

February (2013)

(6 items)

September (2011)

(2 items)

November (2010)

(4 items)

September (2010)

(1 item)

August (2010)

(4 items)

July (2010)

(2 items)

September (2009)

(1 item)

June (2009)

(1 item)

April (2009)

(1 item)

November (2008)

(1 item)

October (2008)

(1 item)

September (2008)

(1 item)

July (2008)

(1 item)

June (2008)

(1 item)

May (2008)

(2 items)

April (2008)

(2 items)

March (2008)

(5 items)

January (2008)

(3 items)

December (2007)

(1 item)

November (2007)

(1 item)

October (2007)

(1 item)

September (2007)

(3 items)

August (2007)

(1 item)

July (2007)

(1 item)

June (2007)

(2 items)

May (2007)

(8 items)

April (2007)

(2 items)

March (2007)

(7 items)

February (2007)

(2 items)

January (2007)

(2 items)

November (2006)

(1 item)

October (2006)

(2 items)

September (2006)

(1 item)

June (2006)

(2 items)

May (2006)

(4 items)

April (2006)

(1 item)

March (2006)

(5 items)

January (2006)

(1 item)

December (2005)

(3 items)

November (2005)

(2 items)

October (2005)

(2 items)

September (2005)

(8 items)

August (2005)

(7 items)

June (2005)

(3 items)

May (2005)

(7 items)

April (2005)

(6 items)

March (2005)

(1 item)

February (2005)

(2 items)

January (2005)

(5 items)

December (2004)

(5 items)

November (2004)

(7 items)

October (2004)

(3 items)

September (2004)

(7 items)

August (2004)

(16 items)

July (2004)

(10 items)

June (2004)

(27 items)

May (2004)

(15 items)

April (2004)

(15 items)

March (2004)

(13 items)

February (2004)

(16 items)

January (2004)

(15 items)

Blog Home

RSS 2.0

Writing

Programming C# 5.0

Programming WPF

Other Sites

Interact Software

GAC Not Completely Useless

Wednesday 17 March, 2004, 11:27 AM

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:

  1. 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.

  2. 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.

  3. 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.

Copyright © 2002-2018, Interact Software Ltd. Content by Ian Griffiths. Please direct all Web site inquiries to webmaster@interact-sw.co.uk