There are lots of posts out there dealing with the various troubles you can run into when trying to get your sandboxed solutions to work as they should. Most focus on getting the User Code Host to start and they do a pretty good job explaining that.
However, there is one scenario that doesn't appear to get as much attention as it should; what happens when you don't use the farm account for the sandbox service. By default, SharePoint uses the farm account for the User Code Service. However, Microsoft advises us wisely to use separate accounts for separate services. This allow for a better management of privileges. Never is this requirement more clear then when you are configuring a sandbox. Using the farm account, which has a lot of privileges, partially defeats the purpose of having sandbox has in the first place.
So, we see more and more production servers with separate accounts for the user code service, which is a good thing. However, developers are also exposed to this and get errors they don't understand:
When deploying by hand you might see the following in the ULS:
Failed to load receiver assembly "-------------, Version=1.0.0.0, Culture=neutral, PublicKeyToken=-----------------" for feature "-----------------" (ID: ------------------------------).: System.IO.FileNotFoundException: Could not load file or assembly '-------------, Version=1.0.0.0, Culture=neutral, PublicKeyToken=-----------------' or one of its dependencies. The system cannot find the file specified. File name: '-------------, Version=1.0.0.0, Culture=neutral, PublicKeyToken=-----------------'
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
Or when deploying from visual studio:
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.
I wrote this up because I found a lot of posts online which advised you to change the service account for the sandbox service (by hand, through services.msc no less!). Don't do this. The solution is the easiest part of this post: Grant the sandbox service account full control on the webapplication(s) you wish to deploy your sandboxed solutions to. No reboots, recycles or any wait required.
