Thursday, December 1, 2011

Failed to create receiver object from assembly and System.ArgumentNullException: Value cannot be null for solution deployment

We ran into an error when reinstalling a webpart WSP package which has a new feature receiver in new version. The Central Administration has the following error:

SPSERVER11 : Failed to create receiver object from assembly ", Version=, Culture=neutral, PublicKeyToken=c5b8095908c623e3",
class "xxxxx.sp.web.webparts.Features.QualcommWebParts.QualcommWebPartsEventReceiver" for feature "QualcommWebParts" (ID: 94487eef-bc72-4034-8f5f-3f03f8676647).: System.ArgumentNullException: Value cannot be null. Parameter name: type at System.Activator.CreateInstance(Type type, Boolean nonPublic) at Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject()

After looking at the message and we realized that this is similar to what we faced to timer service cleanup. Here is the explanation and solution.

The new webpart DLL has been deployed to GAC and the SharePoint timer service which handles solution installation caches DLL is still holding the old one. The cached old  DLL has no feature receiver. As a result, the error is Failed to create receiver object from assembly for event receiver.

The best way to resolve this is to clean up the SharePoint timer service configuration cache and rebuild them on ALL your servers as James mentioned. However, it’s kind of tedious and my college Curtis McDonald developed a script that will clean the configuration cache on all servers and restart it.

Although SharePoint timer service will rebuild the configuration cache after it restarts, it may take several minutes to complete the cache rebuild. In our case, it took about five minutes to rebuild the cache. Your WSP deployment will fail if the new SharePoint timer service configuration cache has not be rebuilt. You could go to the cache directory to verify the timestamp of the caches. The location of the cache is similar to C$\ProgramData\Microsoft\SharePoint\Config\d29cacae-41fc-4aad-a61d-83f43bfdf35d. The last part is the GUID of the process as indicated in blog.

Well, if you redeploy the solution after the cache rebuild, you should be able resolve the issue as mentioned in different blog.