Share via

Per-User GAC

  • Article

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.

Comments

  • Anonymous
    May 23, 2005
    The comment has been removed
  • Anonymous
    May 23, 2005
    Per user GAC would be very useful.
    You could do it so the system GAC is search first, and then the user GAC.

    Many computers are used only by one user, and on windows, usually only one user run at the same time.

    It would allows the user to install software more easily.
  • Anonymous
    May 23, 2005
    From a security perspective, a user-level GAC would probably be a bit of a nightmare. In fact, allowing non-admins to modify any program files is a pretty big problem since it exposes those files to unintended modifications by malware running in a non-admin context. Adding user-writability to the GAC scheme at the expense of increased attack surface seems like a bit of an odd trade-off...

    To be honest, I have to wonder who is asking for non-admin GACing. It's unlikely to be large enterprise customers since most of them wouldn't allow users to install software in the first place. It's unlikely to be ISVs since they would mostly be quite accustomed to producing installation packages that are meant to run under admin accounts, and their customers (home or business) would be accustomed to using these installers. So... Who is that wants a user-writable GAC?
  • Anonymous
    May 24, 2005
    Good question Nicole. It is mostly, cough, developers.
  • Anonymous
    May 24, 2005
    Well, consider this:

    1. Sharing. Per-computer GAC enables sharing of the assemblies among all applications for one computer only. If a different computer's user wants to run the application, the shared assemblies will have to be re-installed to his/her GAC. This is very undesirable.

    2. Servicing. Since the assemblies still lives in multiple places, [...]

    Every time an application is started on a computer that is not owned by Microsoft, does the application connect to Microsoft and automatically download the latest patches for GAC'ed assemblies? Or does it accept the versions that were installed by the administrator (for system GAC) or the user (for user GAC)? Whatever the solution is, the solution applies equally to per-computer as it does to per-user.

    Per-user GAC is almost as important as per-computer GAC. Why not exactly equally important? Here's why:

    Tuesday, May 24, 2005 6:07 AM by Ayende Rahien

    > Many computers are used only by one user

    True. On computers where we don't need to worry about letting one user run as admin all the time, we don't need to allow for per-user stuff. (Of course that wasn't Ayende Rahien's intention, as we can see from other wording. I'm being a bit abusive taking these particular words out of context, but my purpose is to show that that is the only case where per-user installations are not needed.)
  • Anonymous
    May 24, 2005
    Norman,

    The industry is still talking about patching per Operating System.

    Since you are talking about patching per universe, you beat me:)
  • Anonymous
    May 24, 2005
    Is shared servicing the only perceived benefit on the part of the requesters, or are they assuming that other special treatment offered under the machine-level GAC (e.g.: strong name verification skipping, guaranteed full trust on 2.0, etc.) would also be available for assemblies in a user-level GAC? Would they still be likely to want a user-level GAC if these other features weren't allowed?
  • Anonymous
    May 25, 2005
    Since per-user GAC is user modifiable, those features (strong name verification skipping, full trust) will definitely not be there.

    I can't say for everyone but I suspect some people may still buy this without the extra benefits.