Per-User GAC

GAC gives you three advantages in terms of deployment:

 

  1. Sharing. Assemblies in GAC are shared among all applications for all users.
  2. Versioning. Multiple versions of the same assemblies can co-exist in GAC.
  3. Servicing. When you install a service version of the assembly to GAC, every application will pick up the fix.

 

Today .Net framework has only one system GAC. It is required to have Admin privilege to update GAC.

 

People like what GAC offers. But you can’t take advantage of GAC if you don’t have Admin privilege. A natural ask is, can we have per-user GAC so that we can have all the advantages of GAC without the restriction of Admin privilege?

 

The ask is very reasonable. The problem is, when you add per-user GAC to the picture, the deployment model becomes much more complicated.

 

  1. Sharing.  Per-use GAC enables sharing of the assemblies among all applications for one user only. If a different user wants to run the application, the shared assemblies will have to be re-installed to his/her user GAC. This is very undesirable.
  2. Servicing. Since the assemblies still lives in multiple places, in order to make sure every application use the patched assemblies, you either have to install the patch to every user’s GAC, or you install it to the system GAC. Having to install patch to system GAC for assemblies in per-user GAC defeats the purpose of per-user GAC.

 

From a model’s view, Per-User GAC defeats many benefits of GAC. Whether it will be in future version of .Net framework will remain to be seen.