Another Reason to Stop Developing Sandboxed Solutions

As you probably know by now, sandboxed solutions are no longer a preferred approach to development in SharePoint 2013. Wherever possible, you should use develop your custom functionality within a SharePoint app. If SharePoint apps don't offer the capabilities you require, you probably need a farm solution anyway, which leaves sandboxed solutions in a distant third place for SharePoint development.

However, there may still be reasons that compel you to create a sandboxed solution for SharePoint 2013. (In my case, it's because I'm writing a course that needs to cover sandboxed solution development). If so, there is a limitation you need to be aware of:

You can't run sandboxed code on a single server installation of SharePoint 2013 on Windows Server 2012 + domain controller.

You can install and activate the solution without any problems, but any sandboxed code will throw the following error:

An unknown exception occurred while executing a sandboxed code solution request in the worker process.

A quick trawl of the forums - e.g. here - suggests that this problem is specific to Windows Server 2012 + DC configurations. Now, we all know that running SharePoint on a domain controller is unsupported in production environments. At the same time, many developers - including myself - find a single-server development environment vastly preferable to a multi-server development environment. If you run a development server and a domain controller on separate VMs, it can be a real battle to keep the VMs in sync when you use snapshots and reverts.

The single server development environment works just fine for SharePoint apps and farm solutions. However, if you want to develop sandboxed solutions, you'll either need to install your single server development environment on Windows Server 2008 R2, or you'll need to run your DC on a separate VM.


  1. Thanks for posting this, I thought I was going nuts in my new Server 2012 Development VM when my sandbox webpart wouldn't deploy. Very succinct description of the issue.

  2. Although I found the workaround below, I'm just going to switch over to my Win 2008 R2 VM as you mention:

  3. OK, Quickly Stupid question...
    I am about to pull the trigger (via AutoSP Installer) on a brand new SP 2013 Dev environment...

    I would really prefer to implement a fully functional SP 2013 Farm with a separate DC.
    As I have always implemented sp dev environments as a single box VM, I am not familiar with how to network the VMs together correctly in HyperV...
    Can you recommend a resource (blog and or book) that covers this?

    Thanks and Cheers ;0)

    1. Found it:


Post a Comment

Popular posts from this blog

The target principal name is incorrect. Cannot generate SSPI context.

Server-side activities have been updated

Versioning SharePoint Framework Packages