Deprecation of Custom Code in Sandboxed Solutions

Our bad. We’ve been guilty of sending mixed messages about the status of sandboxed solutions in SharePoint development. We’d like to clarify that now.

While developing sandboxed solutions that contain only declarative markup and JavaScript -- which we call no-code sandboxed solutions (NCSS) -- is still viable, we have deprecated the use of custom managed code within the sandboxed solution. We have introduced the new SharePoint app model as a replacement to those scenarios that required the use of managed code. The app model decouples the SharePoint core product from the app runtime, and this enables much more flexibility and gives you the ability to run the code in the environment of your choice. 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. Given the dynamic nature of online services, we will determine support needs for coded sandboxed solutions in SharePoint Online based on customer demand. NCSSs continue to be supported. All future investments will go to making the new SharePoint app model richer and more powerful. Accordingly, we recommend that all new development should use the new app model whenever possible. In scenarios where you have to develop a farm solution or coded sandboxed solution, we recommend that you design it so that it can easily evolve toward a more loosely coupled development model.

For more information about the app model written especially for experienced SharePoint developers, see Reimagine SharePoint Development.

Call to action: We want to make the app model great. Help us by identifying scenarios, APIs and feature gaps that make farm solutions or coded sandboxed solutions necessary today. Provide your suggestions and ideas in our UserVoice site.

This blog post was written by Brian Jones, Group Program Manager, Office Developer Platform.

Comments (16)
  1. Stefan Bauer says:

    Thank you to clean up the confusion around sandboxed solutions. I just have one question.

    What about custom code feature event receiver? For example if I like to check in all the files into a specific library automatically then I still have to use custom code.

    Kind regards


  2. Becky Isserman says:

    I think there is custom feature event receivers, but they are in auto-hosted apps.  We need better explanations on how to setup an auto-hosted event receiver & make sure they work versus sandbox solutions.  Or we need something in SharePoint hosted apps that works the same way or better with an activating and deleting functionality.  I'm not sure if the event receivers we get with auto-hosted are comparable to feature & event receivers in sandbox solutions or even close.

    It would be great to expand the documentation for these apps & for the apis in javascript.  The documentation for the javascript object model is pretty confusing on MSDN.  When you click around most is mislabeled & you cannot find what you are looking for within the api just to do basic things like read lookup fields in lists.

    I am starting to come around to the app model way of thinking, but I still see gaps.  I think if you guys can start filling them in, then we will get a wider adoption of apps versus sandbox solutions.

  3. MgSam says:

    "Our bad. We’ve been guilty of sending mixed messages about the status of sandboxed solutions in SharePoint development."

    Nice. Just make it into a big joke that you have screwed customers (yet again) by having them invest in a technology which you created, trumpeted, and dumped all within the course of a few years. Luckily, this doesn't affect our shop, but if it did the glibness of this post would be even more offensive.

  4. Thorsten Hans says:

    Great to see this post for clarification. I think especially new SharePoint and Office devs have still to many choices. Restricting O365 to only support Apps in the future will be much easier for growing SharePoint / O365 devs out there. Betting on the App Model allows you as a dev a lot more options as using the Sandbox Model of SharePoint.

    @Stefan: RemoteEventReceivers in Apps are the solution.

    #Apps #Apps #Apps

  5. Rickee says:

    @Stephan and @Becky:

    As Thorsten noted, the new app model uses remote event receivers in place of the classic SharePoint event receivers used in SharePoint solutions. Remote event receivers are supported in both provider-hosted and autohosted SharePoint apps. When you add a remote event receiver to an autohosted SP app project, the tools in VS will add the receiver to the WebDeploy package inside the app package. The receiver service is automatically deployed at app installation just as the other components of the autohosted app are deployed.

    See the following node of the SharePoint 2013 App Model SDK: Handling Events in Apps for SharePoint (…/jj220048.aspx)

    We are working to improve our JavaScript API documentation.

  6. Tobias Lekman says:

    For me, it's about client performance and sequential load.

    Too many separate SharePoint apps on a single page can cause performance issues due to too many separate web requests. Loading apps asynchronously on page start or window load causes the client to queue the different client side apps – one slow app will then affect any other app that needs to be loaded on the page. Using auto hosted app parts, we then get an array of queued IFRAME objects instead which results in several "Loading…" messages popping up instead but with the same issue of queued loading.

    Sandboxed solutions allows us to move some of that processing to the server side to ensure that the data or customized function is readily available to the client directly on page load. This way, we can execute the custom feature directly, synchronously and within the same DOM space as the regular page.

    I would like to see a way to load different apps either in a synchronous fashion, a framework/guidance on how to improve simultaneous load speed or to run an auto hosted application directly inside the page without the need for an IFRAME. We also need a simple way of customizing the appearance of an application while loading as the AppRedirect page (especially in Office 365) contains a hard-coded loading image from the layouts folder.

  7. Scott Hoag says:

    (IMO) This was a pretty horrible way to release this messaging. That aside, you could have at least put up a link to your User Voice site ( Is your expectation that people leave all of their feedback on this post?

  8. Dan Usher says:

    I would think perhaps that there might be an update to MSDN in an article or a TechNet KB that states something along these lines?

  9. Chris Johnson says:

    Great to see this news and we appreciate the honesty and transparency.

    Long live the sandbox, in azure 🙂

  10. Jimmywim says:

    Feel gutted for whoever designed the UserCode Host environment, there was some pretty slick engineering there.

  11. Lytjohan says:

    Concerning "Call to action":

    I would suggest taking a long hard look at localization support in apps – and even sandbox if needed  – its broken – simple as that.

    Another area – would be expanding the client api to actually reflect what was possible in sandbox code – like inclusive group detection ( ad groups in sharepoint groups )

    Hard to create large scale apps if those simple few things are not working properly or as expected.

    All that said – Good work – and hopefully even better work in the future 😉

  12. Cory Peters says:

    Good to have clarity but in my view this doesn't change anything. We're going to keep on as if NCSS don't exist as sandbox solutions still have a number of challenges we would have to overcome anyways.

    The biggest thing we're facing is that SharePoint Online doesn't have an API for automating the deployment of sandbox solutions. Currently we've resorted to emulating POST requests. There are some good examples on CodePlex for this. Secondly, sandbox solutions don't promote well between environments… we still typically have dependencies on external web resources and the URLs to access those resources will change between Dev, Test, QA, Production.

    Although more painful to deploy SharePoint configurations we've given up on the feature framework and sandbox model for large deployments involving dozens or hundreds collections.

  13. Bjoern H Rapp says:

    I have implemented zero to none sandbox solutions so this won't change much. From the first time I read about it I realized it was too limited to have a promising future.

  14. BC says:

    We need a way of deploying artifacts to the host web using the app model without having to write heaps of custom code to copy files over and check them in etc. There is a module but that only deploys to the app web and its not recommended to reference masterpages etc. from the app web.

  15. Can you please address best practice for branding? says:

    We would like a statement on your preferred method for branding solutions please. Sandbox? Apps? Farm solutions?

  16. Matthew Pope says:

    We currently have a product that runs in sandboxed solutions on SharePoint on-line and after reading this article we are concerned that there is no time frame for when the sandboxed solution will no longer be supported. I hope that someone can help us clear this up and give us a fixed timeframe as it is essential we factor this migration into our development roadmap.

Comments are closed.

Skip to main content