Recently I’ve been working on an Office 365 based SharePoint solution. It’s a system to allow a company to create sites to collaborate with their customers, and I learnt some interesting things on the way. In part 1 I’ll deal with the technical side of things, and in part 2 I’ll look at more ‘project’ level observations.

I should start by noting that, as a developer, I’ve not done much with Sandbox solutions; typically they’re too limited for what our customers are after. I know that people say that “Sandbox solutions should be your default, they can do most of what you’ll need” – except that I’ve found that they nearly always can’t for our projects. For this project, though, I was told to do what I could within the limits of Office 365.

Tooling

First off, I installed the Visual Studio 2010 SharePoint Power Tools. These are pretty useful – it adds a sandbox compatible ‘Visual Web Part’, and it makes your Intellisense sandbox aware. It’s well worth installing.

It in the Sandbox

So, the first thing to note is that Office 365 development is in the Sandbox. Let’s consider some of the limitations this causes:

• No deployment to _LAYOUTS – so no Application pages.
• No User Controls (although Visual Web Parts can give a similar editing experience)
• No Timer jobs
• No modifications to the Web.config
• All content must go into the Content DB

Fine. That’s annoying – it’s rare I don’t have some need for one of those – but fine.

Logging

Logging in Office 365 is non-existent. This is generally true in the Sandbox too, though there I can at least possibly install a User Code Proxy to call from my sandboxed code. I can’t do that in Office 365, and there is no pre-existing service to use.

In fact, error reporting is pretty poor too.

As a developer, if something goes wrong in Office 365, I have very little information with which to diagnose the issue. In short, it’s rubbish. I don’t even seem to have access to the developer dashboard. I’m going to go out on a limb and say that Office 365 development will be permanently impeded unless some sort of logging service is made available. It’s not a great user story.

The best that the documentation describes is:

You can further validate the operations being performed in the actual SharePoint Online environment by conditionally creating list items in SharePoint lists, based on any information that you want to interrogate at run time. In effect, you can use SharePoint lists as a custom application log that can help you analyze the operations, exceptions, and performance of your solutions.

Yuck.

Permissions and Impersonation (i.e. RunWithElevatedPrivileges)

Sandbox solutions, and (therefore) O365 solutions don’t allow impersonation, or RunWithElevatedPrivileges. While the probably makes sense from a security standpoint, often the reason that I’m asked to write things is precisely to allow users to do things that they ordinarily might not have the rights to do. It’s a bit of a bummer, but there’s nothing we can do about it other than try to design our security models appropriately.

Speed and Timeouts

Requests in Office 365 must complete within 30 seconds. If they don’t, they time out. Now, 30 seconds sounds like a long time, but I’ve seen site templates that take longer than that to create a site.

Worse, I found that even trivial event handlers were ‘delayed’ the first time they ran. When first run, they would 7-8 seconds to run – even though they only contained one trivial line of C#. If you caused them to run again, they were nearly instantaneous. If you wait a while, and try again, you get a 7-8 second delay. This is nearly one third of the available processing time! Clearly, there was some sort of caching going on, which is good, but what’s with the delay?

I don’t mind having a timeout – but that kind of delay on an event handler is pretty disasterous in practice.

Lack of Microsoft.SharePoint.Webcontrols

Sadly, sandbox solutions don’t allow you to use the Microsoft.SharePoint.Webcontrols assembly, and all its useful controls. This includes things like the PeopleEditor control, CSSRegistration control, BaseFieldControl (for rendering fields), DateTimeControl, Theme class, and lots of others.

That is a real shame, particularly the CSSRegistration control; without it, I can’t see how you can use themes effectively with Visual Web Parts that use custom CSS.

You can use these controls in the markup of pages, but interacting with them in C# isn’t possible.

RSS Feeds don’t work in Office 365

This seems a big blooper, but RSS feeds don’t work in Office 365. Yikes! I can understand why (how would the caching work?), but I can’t understand why this hasn’t already been addressed. Or why the web part is still available, even though it doesn’t work.

SPWeb.Properties and serialization

I’ve discussed this before, and really it’s a Sandbox issue – but serialization of those properties doesn’t work too well. I had to do it myself.

CAS policy

I like to use the System.Reflection namespace in my logging methods to record the calling method. This worked fine in my local sandbox – but failed on the Office 365 system that I was using. I traced it back to the use of System.Reflection. I’m guessing that I’m not allow to use System.Reflection. Which is a shame.

A Problem with SPWeb.Recycle

Again, as discussed previously, there is an issue with SPWeb.Recycle() in Sandbox solutions, that causes it to throw a MissingMethodException. Ouch.

References:

• What Can Be Implemented in Sandboxed Solutions in SharePoint 2010 – http://msdn.microsoft.com/en-us/library/gg615464.aspx
• Sandboxed Solutions Architecture in SharePoint 2010 – http://msdn.microsoft.com/en-us/library/ee539417
• SharePoint Online for Office 365 Developer Guide – http://msdn.microsoft.com/en-us/library/hh147180