Failure adding assembly to the cache
Issue
When copying files to the GAC I occasionaly get the following message in the Visual Studio OutPut window on my development VPC:
Failure adding assembly to the cache: Access denied. You might not have administrative credentials to perform this task. Contact your system administrator for assistance.
Also I cannot see any assemblies in the GAC through Windows Explorer, while it is this state.
Background
When developing features for SharePoint, it is common practice to deploy only the Signed Assembly to the GAC, rather that re-deploying the whole SharePoint solution. Personally depending on the project I use one of two mechanisms:
WSPBuilder – Copy to GAC
WSPBuilder is my tool of choice for increasing productivity while developing SharePoint Solutions. One of the functions of WSPBuilder is Copy to GAC, which does exactly as the name suggest:
PostBuild Task
Some clients don’t allow WSPBuilder to be installed or they prefer a more custom project structure. In these cases I tend to use Project Post Build Tasks. You can use the Edit Post Build… function to add parameters to your post build command, as shown below. I tend to use the GACUtil command to copy the assembly to the GAC and the iisapp.vbs to recycle the application pool. A sample script is show below. This is required to ensure that the Just In Time (JIT) compilation occurs again.
"%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\GacUtil.exe" /if "$(TargetPath)" /nologo
"%systemroot%\system32\iisapp.vbs" /a "SharePoint – 9000" /r
Resolution
Although I cannot actually explain what is causing this issue, I found that if you restart the Indexing Service through the Windows Services Management Console, the problem is resolved.
If anyone has an explanation as to why this occurs I would be grateful.
Thanks for the tip.
I had switched off the Indexing Service (set to manual startup). When I stumbled on this issue (only with VS2010 and not with VS2008), I started the indexing service and the problem went off.
I guess I spoke too soon. Restarting indexing service did help, but appears that I have to it every time! That’s insane
I discovered that the service “.NET Runtime Optimization Service v2.0.50727_X86″ was disabled in my machine. When I set the startup option to manual, the problem went away.
Thought it would help someone…