Unable to load assembly group - The user assembly group provider threw an exception

http://andreasglaser.net/post/2011/05/31/Sandboxed-solution-Unable-to-load-assembly-group-The-user-assembly-group-provider-threw-an-exception.aspx

While developing a sandboxed solution in SharePoint 2010 using the Visual Studio 2010 SharePoint developer tools it happened that I wasn’t able to deploy the solution using F5.

The error message wasn’t exact on how to solve the problem:

Error occurred in deployment step 'Add Solution': Unable to load assembly group. The user assembly group provider threw an exception while trying to provide user assemblies for the specified assembly group.

The detailed information about the error is the following:

Unable to load assembly group. The user assembly group provider threw an 
exception while trying to provide user assemblies for the specified assembly group. 
- Assembly group id: ", GroupId = "<SOME_ID>"" 
- Inner Exception: System.UnauthorizedAccessException: Access is denied. 
(Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))    
 at Microsoft.SharePoint.Library.SPRequest.GetListsWithCallback(...)    
 at Microsoft.SharePoint.SPListCollection.EnsureListsData(...)    
 at Microsoft.SharePoint.SPListCollection.Undirty()    
 at Microsoft.SharePoint.SPBaseCollection.GetEnumerator()    
 at Microsoft.SharePoint.SPWeb.GetCatalog(SPListTemplateType typeCatalog)    
...

While doing a search I found a suggestion to change the account for the ‘SharePoint 2010 User Code Host’.
The developer image was set up by a colleague who didn’t use the farm account as the domain account for the  SharePoint 2010 User Code Host service.

Here you can see the service... while trying to debug I realized that the given account on the right side was not the one I expected.

So I used the services under administrative tools and changed the domain account to the SharePoint 2010 farm account:

Changing the account solved my problem:

At the end I was able to deploy the sandboxed solution.

SandBox Service Error

http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/ff3a5e65-dc5b-4b80-b8c9-752adcc3a903/

Hi Rick, Everybody,

I'm the customer that you referred in your post. For sake of information of the group, here are the specs of the systems that we are using:

- Three separated SharePoint Server 2010 farms (Integration, Q&A, Production), two FE + two Application each, individual instance of SQL 2010 R2 each in the SQL Cluster
- Eight different SharePoint 2010 farms (development), each one in one separated box (Win, SP, SQL, VS)
- Everything running inside the same Domain Controller
- No one has Internet access
- Everything using http (not https)

When we try to install a SandBox solution (very simple solution, just a WebPart with one button and one label: if you push the button, you get "Hello world" in the label), we get in all the twelve environments the message "The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request"

- It is possible to install the solution in the "Solutions" gallery
- This message appears at installation of the WebPart in a page (using IE or Firefox)
- The Sandbox Service is running
- The Sandbox processes run using the super-administrator account (the account used to install the farms)
- If we install the solution in a farm outside the DC, everything works perfectly

After hours making traces we found that the Sandbox solution was trying to find certificate revocations using the Microsoft certificate server (crl.microsoft.com). The solution doesn't use any certificate, and all the other functionality in the farms is running as expected.
Based in our conclusions and as Rick mentioned, we were able to make it working using two different approaches:

1 Modifying the Registry Key that controls the check "Check for publisher's certificate revocation" in Internet Explorer (HKEY_USERS\[SID OF THE SERVICE ACCOUNT]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing. The value of "State" need to be set to "0×00023e00".)
2 Using a host name in the servers: "127.0.0.1 crl.microsoft.com" (I used this solution and worked fine)

The first approaches is not desirable to be implemented in a production environment and, if the account where is applied is changed anyhow, the workaround will stop working. We are implementing right now the second approach as a temporary workarond, being not happy with it, but it works at least.

Very curious if the modification in the host name works also for the other cases described here.

Gr., Gustavo

---

Gustavo - http://www.gavd.net/ - http://geeks.ms/blogs/gvelez/