GAC-blocked: Access denied for assembly _XXXX_

As with most of my blog discoveries, this one was born the hard way:  on the ragged slopes of insanity, amid the dying cries of a thousand savage deadlines... much like the fabled Robot al'Thor.

Many of you have created assemblies to be used in the Global Assembly Cache (GAC).  Though often maligned -- sometimes rightly so -- the GAC does serve a legitimate purpose, and recently, I had a very low-function, read-only DLL that needed to be accessible by all SharePoint applications... so to the GAC I went.

For the local dev server, installation was a piece of cake:  drag and drop in C:\Windows\assembly, reset IIS, and away we go.  The problem came when we hit a publicly-accessible web server (same Windows 2008, etc).  "Access denied", I was told.


There are a number of circumstances that can result in a block like this.  The Indexing Service -- or w3wp service, et cetera -- could be holding a DLL hostage, at which point a cycle (or, in some extreme cases, a reboot) will release it.  There may be a genuine permissions issue, at which point the CACLS utility can help you out with the following simple command:

 CACLS c:\WINDOWS\assembly /e /t /p [DOMAIN|MACHINENAME]\useraccount:F

However, sometimes you get no satisfaction from either of these methods.  At this point -- assuming you actually are an Admin user and that you started Windows Explorer by selecting "Run as Administrator" -- you've probably run smack into Server 2008's secret police force:  User Access Control.

UAC, ostensibly, exists to minimize the risk of malicious (or unwittingly dangerous) alterations to the system.  If you click Start->Settings->Control Panel->User Accounts, you'll see a couple of options:  namely, Turn UAC on/off, and Manage User Accounts.  I've had no success with the latter, no matter how much power I give my account.  The only way I found was to click the first item and TEMPORARILY turn UAC off completely.  Of course this necessitates a restart of the system, but why would you be deploying code to a critical production system during normal business hours? 

Don't answer that.

After your server comes back up, you should be able to install your file(s) to the GAC.  Once you have everything in, go back to User Accounts, re-enable UAC, and reboot again.  It's not a perfectly smooth process, but since GAC changes mean an iisreset anyway, you're going to have some disruption one way or another.

To recap:

 1)  Whether you're using the GUI or command-line GACUTIL, be sure you've opened your command prompt/Windows Explorer using Run as Administrator.

 2)  If you are denied access, try the CACLS utility.

 3)  If that doesn't work, try stopping all Indexing and web services to ensure that nothing is holding your DLL.

 4)  Finally, if you're still denied access, TEMPORARILY turn off UAC to let you into the GAC.


1 Comment

  • Did you try using GACUTIL from a command line that was running as administrator?

    You might also be able to get around it by running the windows explorers as administrator.

Comments have been disabled for this content.