What are the advantages and disadvantages of using the GAC?

Question

And on top of that, are there cases where one has to use the global assembly cache or where one cannot use it?

Answer 1

The GAC can also be used by assemblies that require elevated permissions to perform privileged operations on behalf of less trusted code (e.g. a partial trust ASP.NET application).

For example, say you have a partial trust ASP.NET application which needs to perform a task that would require elevated privileges, i.e. Full Trust. The solution is to put the code that requires elevated privileges into a separate assembly. The assembly is marked with the AllowPartiallyTrustedCallers attribute and the class that contains the privileged logic is marked with the PermissionSet attribute, something like this:

[PermissionSet(SecurityAction.Assert, Unrestricted=true)]

Our assembly would be given a strong name (signed) and then deployed into the GAC.

Now our partially trusted app(s) can utilise the trusted assembly in the GAC to carry out a specific and narrow set of privileged operations without losing the benefits of partial trust.

Answer 2

If you're shipping a reusable library consisting of multiple assemblies, but only few of them form a facade, you can consider installing the assemblies into GAC, if the package is installed to developer's PCs.

Imagine, you ship 6 assemblies, and only one of these 6 assemblies contains a facade - i.e. other 5 are used only by the facade itself. You ship:

• MyProduct.Facade.dll - that's the only component intended to be used by developers
• MyProduct.Core.dll - used by MyProduct.Facade.dll, but not intended to be used by developers
• MyProduct.Component1.dll - the same
• MyProduct.Component2.dll - the same
• ThirdParty.Lib1.dll - third-party library used by MyProduct.Component1.dll
• ThirdParty.Lib2.dll - the same
• etc.

Developers using your project would like to reference just MyProduct.Facade.dll in their own projects. But when their project runs, it must be able to load all the assemblies it references - recursively. How this can be achieved? In general, they must be available either in Bin folder, on in GAC:

• You may ask the developers to locate your installation folder and add references to all N assemblies you put there. This will ensure they'll be copied into Bin folder to be available in runtime.
• You may install VS.NET project template already containing these 6 references. A bit complex, since you should inject the actual path to your assemblies into this template before its installation. This can be done only by installer, since this path depends on installation path.
• You may ask developers to create a special post-build step in .csproj / .vbproj file copying the necessary dependencies to Bin folder. The same disadvantages.
• Finally, you may install all your assemblies into GAC. In this case developers must add the reference just to MyProduct.Facade.dll from their project. Everything else will be available in runtime anyway.

Note: last option doesn't make you to do the same while shipping the project to production PCs. You can either ship all the assemblies within Bin folder, or install them into GAC - all depends all your wish.

So the solution described shows the advantage of putting third-party assemblies into GAC during the development. It doesn't related to production.

As you may find, installation into GAC is mainly intended to solve the problem of location of required assemblies (dependencies). If an assembly is installed into GAC, you may consider it exists "nearby" any application. It's like adding path to .exe to your PATH variable, but in "managed way". - of course, this is rather simplified description ;)

Answer 3

Advantage:

• Only one place to update your assemblys
• You use a little less hard drive space

Disadvantage:

• If you need to update only one website, you can't. You may end with the other websites in the webserver broken

Recommendation: Leave the GAC to MS and friends. The gigabyte is very cheap now.

Answer 4

• Loading assemblies from GAC mean less overhead and security that your application will always load correct version of .NET library
• You shouldn't ngen assemblies that are outside of GAC, because there will be almost no performance gain, in many cases even loss in performance.
• You're already using GAC, because all standard .NET assemblies are actually in GAC and ngened (during installation).
• Using GAC for your own libraries adds complexity into deployment, I would try to avoid it at all costs.
• Your users need to be logged as administrators during installation if you want to put something into GAC, quite a problem for many types of applications.

So to sum it all, start simple and if you later see major performance gains if you put your assemblies into GAC and NGEN them, go for it, otherwise don't bother. GAC is more suitable for frameworks where there is expectation for library to be shared among more applications, in 99% of cases, you don't need it.

Answer 5

The GAC runs with Full Trust and can be used by applications outside of your Web App. For example, Timer Jobs in Sharepoint HAVE to be in the GAC because the sptimer service is a separate process.

The "Full Trust" Part is also a possible source for security issues. Sure, you can work with Code Access Security, but I do not see too many Assemblies using CAS unfortunately :( The /bin Folder can be locked down to Medium which is normally fine.

Daniel Larson has a post on CAS as well which details the differences a bit more.

Answer 6

I think one of the biggest advantages of using the GAC is that you can have multiple versions of the same assembly registered and available to your applications. Personally, i don't like how it restricts movement from machine to machine (i don't like having to say, check out source on a new VPC and go through a bunch of steps to get it running because I have to register stuff in the GAC)

Answer 7

In all my life, I have had maybe one application where I had to put an assembly in the GAC, simply because these assemblies were part of a framework that a number of applications would use it, and it seemed right to put them into the GAC.