What are the advantages and disadvantages of using the GAC?
Solution 1:
- 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.
Solution 2:
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.
Solution 3:
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.
Solution 4:
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.