Sandbox code no longer available in Office 365 – with immediate effect

Most technical people working with Office 365 have known that sandbox code has been deprecated for some time. This doesn’t mean any sandbox solution is deprecated however – instead, the deprecation specifically refers to *code* in sandbox solutions, and by that we mean code which uses the server-side API. No Code Sandbox Solutions (NCSS) continue to be supported. This advance warning about sandbox code was given back in January 2014 in https://blogs.msdn.microsoft.com/sharepointdev/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions/. Since then however, no timeline for the actual removal of the feature was announced – and in fact there was no news whatsoever. I even heard from some Microsoft folks that the urgency of removing sandbox code from SharePoint Online had gone away, since the original operational concerns weren’t materializing and in fact the engineering team were able to run and scale the feature just fine in Office 365.

So a big surprise last week was the sudden removal of the feature in many tenants. The “Activate” button against a solution is unavailable, and the following message is shown:

"Activation of solutions with sandboxed code has been disabled in this site collection. Contact your administrator to enable activation using the guidance published here."

One very interesting aspect of this is that you will see this even if you’re not using sandbox code, but *are* deploying a code assembly – and this is the default in Visual Studio! So, lots of solutions which aren’t really using sandbox code at all will still need some attention – developers will need to repackage the WSP again, this time without including the auto-generated assembly. I discuss the specific change later in the “How do I remove auto-generated sandbox assemblies?” section.

Official Microsoft announcement

You can find the official communication here - http://dev.office.com/blogs/removing-code-based-sandbox-solutions-in-sharepoint-online

What effect will this have?

Well, it depends on which camp you fall in:

1. You’re not actually using sandbox code, but have some auto-generated assemblies deployed.
2. You genuinely are using sandbox code.

For number 1, your developers will need to make some relatively simple updates. See the “How do I remove auto-generated sandbox assemblies?” section.

For number 2, the short answer is you have a problem. Just how big depends on how sandbox code is being used, and how much of it you have. Ultimately you need to take action to re-engineer your solution now. You can’t wait until some code changes are scheduled, since bits of your solution may stop working very soon and you may have a service issue. Already, you will not be able to add new sandbox code or reactivate an existing sandbox WSP with code. Additionally, the Microsoft message states that you have 30 days before existing code will stop working. In technical terms, that means the following things will stop working:

• Event receivers
• Feature receivers
• Workflows (coded)
• InfoPath forms (if using code behind the forms)
• Web parts (if coded using sandbox code)

Exactly what that means for your intranet or solution is down to how those building blocks have been used by the original developers.

Considering the impact

I’m really surprised at this – in the original deprecation announcement, Microsoft said:

We realize that our customers have made investments in coded sandboxed solutions and we will phase them out responsibly. Existing coded sandboxed solutions will continue to work in on-premises SharePoint farms for the foreseeable future.

Happily, none of my clients/projects are affected because we knew better than to build solutions using this approach. But I feel for organizations in a different situation. I was certainly expecting a significant “final warning” period and I’d heard it said that there would be at least a further 12 months from this point. But apparently not – and I know Microsoft have probably not breached any contract or element of the Office 365 Service Description here, but I struggle to see that this is “responsibly” taking a feature away from the service.

On a related note, I’ve being doing some work alongside Microsoft with a global enterprise (over 100,000 users) who have sandbox code in their Office 365 intranet – in light of this, it’s perhaps fortunate that they are not yet live. We didn’t create the initial solution, but flagged this in our review of their code, along with a few other things. I suggested the Microsoft folks reach out to their colleagues for clarification on the timeline for switching off sandbox code. Interestingly, the message that came back is that “everything should be fine for at least 12 months”, and so if it’s a surprise to these guys I think it’s fair to say it’s a surprise to many others too.

Communication troubles

Notably, there was some confusion as this was playing out initially. At first, this was being reported as a temporary service issue, and administrators may have seen a message to this effect in the Office 365 Message Center:

However, sandbox code really is being disabled – it just seems that for a while, other teams within Office 365 didn’t actually know either. You will now see one of two things in the Office 365 Admin Center:

Status	Message
You have a problem – sandbox code was detected	MC73347 - We’ve detected that you are using a code-based sandbox solution with your tenant account. Please be advised that we’ve moved forward on our plans to remove code-based sandbox solutions as previously announced in 2014, which can be seen here: http://aka.ms/sandboxcode Please note that declarative (no-code) sandbox solutions are still fully supported. How does this affect me? As part of the removal process, activation of new code-based sandboxed solutions, as well as updates of existing solutions are no longer available. In approximately 30 days, currently running, code-based sandbox solutions in the SharePoint Online environment will be disabled. If you have an extenuating circumstance, please contact us as our Product and Customer Support teams are ready to support you during this transition.
You’re OK – no sandbox code was detected	SP73009 - Custom Solutions and Workflows - False positive Incident customer impact scope has been updated. Ongoing analysis of customer impact has determined that your service is not impacted by this incident

So that’s the final story it seems.

How do I remove auto-generated sandbox assemblies?

As mentioned earlier, developers may need to repackage WSP solutions without the auto-generated assembly. You can do this by setting the “Include Assembly in Package” project property to false:

This step may be necessary the next time some development or maintenance is carried out – effectively anything that would require activation of another version of a WSP.

Summary

We rely on Microsoft to make the right decisions in terms of running Office 365 (and on-premises SharePoint). I’ve no idea of the scale of sandbox code out there in real-life solutions, but I really hope the way this is being handled doesn’t affect too many organizations too badly. Are you affected by this? Or do you otherwise have views? I’d be interested in hearing how this is being received – feel free to leave a comment and let me know.