How to: Create and Deploy Common Declarative Elements in Sandboxed Solutions
This topic explains how to create, in a sandboxed solution, the common Microsoft SharePoint 2010 project components that are declaratively defined.
Applies to: SharePoint Foundation 2010
Available in SharePoint Online
The topic covers only the following declarative components. (For information about how to create and deploy other kinds of components in sandboxed solutions, see the Related Topics section.)
List/Library Template (including the schema.xml file)
List/Library Instance
Content Type
Binding of Content Type to List
Field (but not custom field types)
Custom Action (however, defining a Custom Action Group and hiding a Custom Action are not allowed in sandboxed solutions. See the note later in the topic.)
Property Bag
Stapling of a Feature to a site definition configuration (also called Feature/Site Template Association)
Creating Common Declarative Elements in Sandboxed Solutions
Note
The following common declarative SharePoint project components cannot be deployed in a sandboxed solution:
-
Registration of a control candidate for a delegate control (Control element).
-
Registration of a document converter (DocumentConverter element). These are registered at the web application level, and sandboxed solutions are not allowed to access anything outside the hosting site collection.
-
Definition of a Custom Action Group (CustomActionGroup element).
-
Hide a Custom Action (HideCustomAction element).
-
Define a workflow Workflow element). This element is used only as part of coded workflows, which cannot be deployed in a sandboxed solution.
For more information about why these components cannot be deployed in sandboxed solutions, see Restrictions on Sandboxed Solutions in SharePoint 2010.
To create the components
Start a Microsoft Visual Studio SharePoint project. It can be any of the project types that are allowed in sandboxed solutions, including Empty SharePoint Solution. (It cannot be Business Data Connectivity Model, Site Template, Visual Web Part, Sequential Workflow, or State Machine Workflow.)
When prompted for the solution type, select Sandboxed, not Farm.
After Visual Studio creates the project, add Content Type, List Instance, List Template, or List Template From Content Type project items as needed to the project.
Customize the Elements.xml files (and Schema.xml files, if any) in these project items exactly as you would in a farm solution.
If your solution includes any of the other kinds of components in this bulleted list, there is no specific Visual Studio project item, so add an Empty Element item to the project.
The Empty Element item contains a single Elements.xml file whose only markup is the root <Elements> element.
Customize the Elements.xml file exactly as you would in a farm solution. For example, if your component is one or more fields, add one or more Field elements as child elements of the <Elements> element, and configure their attributes and child elements, if any.
If there is more than one component in your solution for which there is no specific Visual Studio project item, you can add separate Empty Element items for each of them or combine different kinds of child elements to the <Elements> element of the same Empty Element item. After you add a child element to the <Elements> element, configure its attributes and child elements. The following table shows the purely declarative components available in sandboxed solutions that do not have a specific Visual Studio project item.
Component
Element
Binding of a content type to a list
Custom Action
Property Bag
Feature stapling
Field
Your project should have at least one Feature, and all the element manifests (Elements.xml files) of all of your components should be referenced in a Feature. If you are using Visual Studio, a first Feature is created automatically when you add the first component, and each new component is added to it. You can add more Features and use the Visual Studio Feature designer to move components between Features. A sandboxed solution cannot deploy anything outside the site collection to which it is uploaded, so none of your Features can be scoped to Farm or WebApplication.
Build, package, and deploy to your development SharePoint installation. When testing and debugging is completed, make the sandboxed solution package (.wsp file) available to site collection administrators.
Deploying the Sandboxed Solution
A site collection administrator can install a sandboxed solution to the site collection's Solutions Gallery. There are two steps to this process. First, the solution package is uploaded to the gallery. Second, it is deployed, which is called "activation" for sandboxed solutions. The second step automatically activates any Features in the package. If any solution validators are registered with the site collection, they also execute at the activation stage. If the solution passes validation and has not been blocked by a farm administrator, it is ready for use on the site collection.
See Also
Tasks
How to: Create and Deploy Event Receivers in Sandboxed Solutions
How to: Create and Deploy Feature Receivers in Sandboxed Solutions
How to: Create and Deploy Declarative Workflows in Sandboxed Solutions
How to: Create and Deploy Workflow Actions in Sandboxed Solutions
Concepts
What Can Be Implemented in Sandboxed Solutions in SharePoint 2010