Compartir a través de

Deprecation of Custom Code in Sandboxed Solutions

  • Artículo

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

  • Anonymous
    January 13, 2014
    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 Stefan

  • Anonymous
    January 13, 2014
    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.

  • Anonymous
    January 13, 2014
    The comment has been removed

  • Anonymous
    January 14, 2014
    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

  • Anonymous
    January 14, 2014
    The comment has been removed

  • Anonymous
    January 14, 2014
    The comment has been removed

  • Anonymous
    January 14, 2014
    (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 (officespdev.uservoice.com). Is your expectation that people leave all of their feedback on this post?

  • Anonymous
    January 14, 2014
    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?

  • Anonymous
    January 14, 2014
    Great to see this news and we appreciate the honesty and transparency. Long live the sandbox, in azure :)

  • Anonymous
    January 14, 2014
    Feel gutted for whoever designed the UserCode Host environment, there was some pretty slick engineering there.

  • Anonymous
    January 14, 2014
    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 ;)

  • Anonymous
    January 15, 2014
    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.

  • Anonymous
    January 15, 2014
    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.

  • Anonymous
    January 15, 2014
    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.

  • Anonymous
    January 15, 2014
    We would like a statement on your preferred method for branding solutions please. Sandbox? Apps? Farm solutions?

  • Anonymous
    January 22, 2014
    The comment has been removed