Still here? Great. So, here’s the situation. Tell me if it seems crazy. There are things that, to me as a programmer, don’t seem crazy at all, while more seasoned SharePoint developers would look at what I was doing and scream, “Are you mad?” Like iterating through SPList.Items() in a foreach loop without first putting them into an SPListItemCollection, for example.
Anyway, I have the following situation: A project tracking list, which has a “Primary Technical Lead” field and a “Secondary Technical Lead” field, both of which are single User-type. I need to create a “Team Members” field, which is a multi-User type. Upon creation of that field, I need to populate it with both the value from the Primary and Secondary tech lead fields. Naturally, I chose to implement this one-time setup in the FeatureActivated event receiver.
Additionally, I want to make sure that whenever a tech lead is changed, that that change is reflected in the Team Members field. I also want to make sure that you can’t delete someone from Team Members if they’re still a tech lead. Naturally, I chose to implement this as an ItemUpdating event receiver.
Every time I tried to activate the solution, however, I always got the following error:
Unhandled exception was thrown by the sandboxed code wrapper’s Execute method in the partial trust app domain: The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request.
Well, excuuuuuuuuse me!
Now, I wasn’t entirely un-clever about this. Of course my ItemUpdating event was firing when I was trying to populate the TeamMembers field. (Okay, I’m kind of lying. There was a lot of blank “WTF?” going on in my head before I realized that the ItemUpdating event was firing. Then I went through the feature activation in the debugger, and noticed that the exception was thrown when I called SPListItem.Update() or SPListItem.SystemUpdate(), which I tried in desperation.) But my ItemUpdating method should have just quickly exited upon not seeing the fields that it was worried about in the AfterProperties. Still, worried about my logic, I commented out my routine line by line. Until finally, my entire ItemUpdating receiver looked like:
public override void ItemUpdating(SPItemEventProperties properties) {
// Lots of commented-out lines
base.ItemUpdating(properties);
}
And still, Sandbox is Too Damn Busy.
Then I went to the List Receiver’s Elements.xml file, and commented out the <Receiver…><Type>ItemUpdating</Type>…</Receiver> part. And lo and behold, the Sandbox would suddenly take my calls again.
I then created the simplest test case. One list. One ItemUpdating event receiver which does nothing. One FeatureActivated event receiver that updates a list item. Activation == game over.
Now I understand why updating a ListItem that has an ItemUpdating receiver from a FeatureActivated receiver might be a problem. But, once again, SharePoint has vomited forth one of the least useful error messages possible.
