Even though it's still possible (and sometimes tempting) to build and deploy SharePoint Sandbox Solutions for SharePoint Online (Office 365) they have been deprecated in favour of SharePoint Add-ins (previously SharePoint Apps). There is information provided by Microsoft in regards to the limitations of Sandbox Solutions but there are some undocumented limitations, especially when leveraging them in SharePoint Online.
Recently I was tasked to build a simple web part that would create a basic CSV report of specific content in a site collection. Due to the timing and budget it was determined a Sandboxed Solution would be the best approach, as this web part would only be used on a temporary basis until a more permanent solution was implemented. The web part was built quickly and performed the following:
- Iterated through all the sites and document libraries in the site collection
- Added audit related details to a CSV document to be stored on the site in a designated document library
The feature that deployed the web part had a feature receiver associated with it that:
- Created a document library to store the reports
- Created a SharePoint Group for securing the document library
In an on premise SharePoint 2013 there was no issues at all with the solution and it functioned as expected. Tests were then performed on a SharePoint Online site where the solution worked as expected.
Once moving into more detailed testing I started to run into issues. On one site collection I was unable to even activate the Sandbox Solution. I would receive an error "Sandboxed code execution request failed" with a correlation id. Further testing identified the issue being in the feature activation code that was creating the SharePoint Group. Initially I thought the issue might be related to the Resource Quota configured for the site collection, so I bumped that up with no success. Next I manually created the SharePoint Group (the feature receiver would skip the group creation if it already existed) and tried to activate the solution again. This time it succeeded.
Comparing the two site collections I noticed the one that the solution was failing to activate on had dozens of SharePoint Groups, compared to five on my test site. So with a lot of SharePoint Groups trying to check if a specific group existed, and if not creating it caused issues.
The next set of tests I performed was with the web part. I modified the source code to only generate the report from the content of a single site (instead of all sites in the site collection), that worked as expected. Next I changed the code from recursively navigating the site structure to iterating through the SPSite.AllWebs collection, which failed. I received the "Web Part Error: Sandboxed code execution request failed. Correlation ID…" error message.
I then went back to the SharePoint Online site that the web part was working on and I continued to add new sites and document libraries until the web part was failing there as well. As my test tenant was not as busy as the other one (where even the solution activation was failing), the web part solution was able to generate reports where similar site structure and content existed.
This behaviour leads me to believe that there are further restrictions on the Sandbox code execution outside of the Resource Quotas. As the collections get larger (e.g. SPWeb.SiteGroups) interacting with them via Sandboxed code was failing as well as memory demands of the solution increased during runtime a threshold was being hit which was halting the process. It's possible that SharePoint Online has boundaries set on the User Code services used to execute Sandboxed solutions but I haven't been able to source any details on these.
After hitting these unknown restrictions the best option to provide this basic solution would be a Provider Hosted SharePoint Add-in. This would allow for the creation of the reports without hitting any SharePoint Online limitations as well, removes any performance issues that could occur in a SharePoint Hosted Add-in.