SharePoint 2010 introduces a new way of adding custom dev to SharePoint: Sandbox solutions, also called User Solutions. Solution deployment we are all used to in SharePoint 2007 still exists in SP2010 but those solutions will be called Farm solutions. Sandbox solutions are scoped to site collection and each site collection has its own gallery of these solutions which can be found in the site settings page.
When you create a Visual Studio project using any of the SP 2010 templates it asks us what type of solution it is going to be, as shown in this picture:
This selection can be changed later from the Visual Studio project properties:
Visual Studio 2010 gives visual tools to build the deployment package so long gone are the days of editing DDF and manifest files. After building the WSP you can upload it to the solution gallery just like you would upload a master page to its gallery. Select the solution you uploaded and the context sensitive ribbon gives you the option to activate the solution.
To have your solution working make sure you have this windows service running: Windows SharePoint Services User Code Host V4.
Sandbox solutions have their own advantages but also some limitations. Best part is you don’t have to deploy the solution from the server which means no server reset. You can do as many deployments as you want – every developer’s dream 🙂 And, you can test your customizations in a test site collection on the production servers before applying it to the real sites. I personally am very excited about this possibility.
Coming to the limitations, not every type of custom functionality can be packaged into a sandbox solution. From what I’ve seen so far any component that needs files in 14 hive cannot be part of sandbox solution, for e.g.: Visual Web Part. When creating a new visual studio project if you select Visual Web Part template, in the next screen sandbox solution will be grayed out. Next big limitation is you cannot run your code with elevated privileges. If you select “Deploy as sandboxed solution” when creating the project, Visual Studio doesn’t give intellisense for the classes that cannot be used in a sandbox solution. You can still type those classes manually and your project would compile fine but your component won’t work when your sandbox solution is activated. So, keep these two limitations in mind when going for a sandbox solution.
As you saw, you don’t have to involve server team to deploy custom functionality. Anybody with enough permissions can upload whatever customizations they want which is not so good news for farm administrators. To make them happy, Central Administration(CA) gives a way to block the sandbox solutions. In CA under System Settings you can see the “Manage User Solutions” option. Here you can upload the solution you want to block and you can set a custom message to be displayed wherever the components of the blocked solution are used. Below is the screenshot of the web part that is part of a blocked solution.
Hope this of help. This is Sandbox solutions as in the first beta of SharePoint 2010.
