Cannot add the specified assembly to the global assembly cache

This is part of my continuing series on debugging SharePoint and PowerPivot. In this case, I do not expect any PowerPivot users to ever encounter this error in the context of PowerPivot. However, the general SharePoint developer who is in the early stages of building and testing his custom solutions might hit this and since so many people on our team have been confused by it, I thought I would throw out some help for other developers. This error is hit when trying to deploy a SharePoint solution package to the farm. It could be an ApplicationServer solution or a WebFrontEnd solution, the important part is that it has an assembly marked to be deployed to the GAC:

<Solution SolutionId=”94BE5F4C-D227-4981-A725-95ABC706364A” DeploymentServerType=”ApplicationServer” ResetWebServer=”TRUE” xmlns=”http://schemas.microsoft.com/sharepoint/”>
  <Assemblies>
    <Assembly DeploymentTarget=”GlobalAssemblyCache” Location=”MyAssembly.dll” />
  </Assemblies>
  …
</Solution>

The above solution, when deployed via either stsadm or the new PowerShell commandlets in SharePoint 2010 will attempt to put the assembly “MyAssembly.dll” into the GAC on every ApplicationServer in the farm. There are two possible reasons for this deployment to fail with the above error:

1) The assembly is already in the GAC. For the initial deploy, it appears the SharePoint uses “/i” and not “/if” and so it could fail if the assembly is already there. Most of the time, I find that this is not the issue but it could be for you. You can test if this is the issue by simply removing the version of the dll which is already there. If that is causing it, you need to figure out why you are trying to GAC the same version of the dll more than once.

2) You have not disabled strong name verification. For us … this was always the issue. Signing your assemblies is a time consuming process for a large product and so often you mark your assemblies for delay signing and then only sign “special” builds. In those cases, you need to disable strong name verification in order to add un-signed assemblies to the GAC. The tool for doing this is sn.exe which can be found in your Windows SDK directory. Using the –Vr option you can mark classes of assemblies to be skipped when it comes to verification. The classic command is “sn.exe –Vr *,*” which is indicating that any assembly with any public key token should be skipped. You might also chose to just skip verification for assemblies with your public key token with something like: “sn –Vr *,89845dcd8080cc91”. Whatever method you chose, there are a couple of key things you need to understand to make sure sn has “worked” for you:

• Deploying a solution will deploy the solution to every appropriate machine in your farm. If you install an msi on MachineA in the farm and on that machine run sn.exe, but then deploy a solution and MachineB is also a member of the farm, you had to have run sn.exe on that machine also.
• Sn.exe comes in a 32 and 64 bit flavor. It is difficult to tell which version you are running if someone just gave you the bits in a random folder (in the SDK folder the bits are under “architecturely” marked folder names). If you run the 32 version of sn.exe it will not help you when trying to GAC the binary on the 64-bit SharePoint server. There are a number of ways to try and figure out what is marked for “skipping” using the sn.exe tool, but I like to go directly to the registry because there is very little room for confusion there. Sn.exe is adding entries to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\ and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification\ hives of the registry for whatever parameters you pass into the call to “sn.exe –Vr”. If you look in your registry and find that you only see an entry under the Wow6432Node, then you have only run the 32 bit version of sn. You will need to find the 64-bit version of sn.exe to get your skip registrations in the appropriate place (you can actually add them manually if you feel confident enough to edit the registry by hand).
• THIS IS THE MOST OFTEN OVERLOOKED STEP – The list of what to skip when it comes to verification is actually cached. Normally, when you run gacutil.exe by hand, the process starts, loads the skip list, verifies, fails / succeeds and shuts down. Hence, if it fails and you then run sn.exe, the next time you run gacutil.exe it will succeed. This is *not* how it works with SharePoint. Solution deployment is done within the context of their timer service. This is an nt service which is not shutdown after a failed / successfull deployment of your solution. Hence, if your solution fails to deploy because of a strong name verification issue, you run “sn –Vr *,*” to enable skipping verification, and then try to deploy your solution again … *it will fail again*. You must recycle the SharePoint 2010 Timer service on every machine on which your solution is going to be deployed (specifically on which you just ran sn.exe) in order to get the skip list reloaded. I have seen people get frustrated and so reboot their machines which will obviously work, but all you really needed to do was recycle the timer service.

Hopefully this will help some SharePoint developers avoid wasting too much time figuring out why this was failing.

HTH
Lee