The answer to this question is yes, but… not for all situations and not all types of sandbox solutions.
SharePoint sandbox solutions were introduced with SharePoint 2010 and provided a mechanism to execute code outside of the ISS worker process. The sandbox solutions do not affect the entire farm; they are installed per site collection and they can be installed by the site collection administrator.
Every day I deal with SharePoint users that are extremely afraid of using sandbox solutions mainly because the message about this type of solutions being deprecated was not properly communicated by Microsoft.
What should you avoid?
Code-based sandbox solutions should be avoided. On SharePoint 2013 they still work, it’s still possible to run them on SharePoint 2016 with a few tricks, but on SharePoint Online they are no longer supported.
Since July 2016 it is no longer possible to activate code-based sandbox solutions on SharePoint online; if you try to do it you will see the message bellow.
Any sandbox solution that uses the server-side API is deprecated since 2014 and should be replaced by the App/Add-in model. This means you no longer can create solutions with:
- Web parts that use sandbox code (this even affects web parts that only use code to store the properties)
- Event Receivers
- Feature Receivers
What can you keep using?
- Site Templates
- Content Types
- Custom Actions
- Branding elements (like custom master pages and alternate CSS files)
By default, all sandbox solutions created with Visual Studio templates include a .net assembly which needs to be disabled to get a fully declarative solution.
To disable the assembly in the project with Visual Studio, you can set the property “Include Assembly in the Package” to false, as shown in the image bellow.
For complex scenarios, you can use the App/Add-in model and the Office PNP is full of good examples that you can use as a starting point; the PNP repository is kept updated by the community and by Microsoft.
If you are planning to start developing SharePoint solutions in the upcoming months, the SharePoint Framework (SPFx) is the way to go. It didn’t reach the final version yet and is only available for SharePoint Online, but it will be available on SharePoint 2016 during 2017 with a feature pack, although it is not granted that it will be released for SharePoint 2013.
With all supported methods available to build solutions, SharePoint developers are becoming to be more like web developers… this is the time to invest in your future and learn new methods and technologies; you can start by reading this article.
Bellow you have a table with all the development methods that you can and cannot use in 2017 in your SharePoint environments.
|SharePoint Online||SharePoint 2016||SharePoint 2013||SharePoint 2010|
|Code-based Sandbox Solutions||Not Supported||Not Supported||Deprecated||Supported|
|No-code Sandbox Solutions||Supported||Supported||Supported||Supported|
|APPS / ADD-INs||Supported||Supported||Supported||Not Supported|
|SPFx||Supported||Supported*||Not Supported||Not Supported|
|Full Trust Farm Solutions||Not Supported||Supported||Supported||Supported|
*At the time I’m writing this article it is not supported but will be supported during 2017.