In this recipe, we will be creating a SharePoint 2013 farm solution. Farm solutions allow us to deploy content to the filesystem of the SharePoint servers and interact with SharePoint farm elements outside of a site collection, such as the web application.
Follow these steps to create a SharePoint solution:
A Visual Studio SharePoint project builds a
class library (an assembly) when compiled. In addition to building the assembly, Visual Studio provides a publishing function that packages the assembly, the manifest, and all the included files into a SharePoint solution (.wsp
) file.
When creating a new SharePoint solution, it will default to a sandboxed solution. With any programming, it is a good idea to only have access to what is required for your solution. If your SharePoint project does not require access to elements not allowed in a sandboxed solution, use a sandboxed solution.
With SharePoint 2010 and Visual Studio 2010, Microsoft introduced project templates to create, package, deploy, and debug custom SharePoint solutions. SharePoint 2010 and Visual Studio 2010 provided two types of SharePoint solutions: farm solutions and sandboxed solutions.
Farm solutions are deployed at the SharePoint farm level and require a farm administrator access to install them to the farm. Sandboxed solutions are deployed at the site collection level and only require a site collection administrator access to install them to the site collection. Farm solutions are provided full access to the SharePoint farm, whereas sandboxed solutions are only provided access to elements within the site collection.
Farm solutions can only be added with PowerShell Cmdlets or the stsadm.exe
command. They cannot be added or updated with the web interface. They can, however, be deployed and retracted with the web interface.
Sandboxed solutions can be added, deployed, updated, and retracted with the web interface or PowerShell Cmdlets. They cannot be managed with the stsadm.exe
command.
The primary differences between farm and sandboxed solutions are illustrated in the following table (note that this is not a comprehensive list):
Type |
Farm solution |
Sandboxed solution |
---|---|---|
Deploys to |
Farm solutions store |
Site collection solutions gallery |
Installation methods |
PowerShell Cmdlets and the |
PowerShell Cmdlets and web interface |
Farm features |
Yes |
No |
Web application features |
Yes |
No |
Site collection features |
Yes |
Yes |
Site features |
Yes |
Yes |
Application pages (/_layouts) |
Yes |
No |
Custom action groups |
Yes |
No |
Code-based workflows |
Yes |
No |
Content types and fields |
Yes |
Yes |
Custom actions |
Yes |
Yes |
Declarative workflows |
Yes |
Yes |
Event receivers |
Yes |
Yes |
List definitions and instances |
Yes |
Yes |
Modules |
Yes |
Yes |
Web parts |
Yes |
Yes |
Timer jobs |
Yes |
No |
The IIS worker processes (w3wp.exe
) executes the farm solution code, whereas the user code solution worker processes (spucworkerprocess.exe
) executes the sandboxed solution code.
With SharePoint 2013 and Visual Studio 2012, Microsoft has added a third type of SharePoint solution, the SharePoint app. A SharePoint app solution runs isolated from the SharePoint stack, only allows for the client-side and JavaScript object models to be used to interact with SharePoint, and provides a framework to publish apps to and install apps from the SharePoint app store.
Using the SharePoint version as reference, the tools and solutions available in SharePoint are illustrated in the following table:
SharePoint version |
2007 |
2010 |
2013 |
---|---|---|---|
Tools available |
|
|
|
Farm solutions |
Yes |
Yes |
Yes |
Sandboxed solutions |
No |
Yes |
Yes |
Apps |
No |
No |
Yes |
Packaging branding elements, such as master pages and page layouts, can be accomplished with a sandboxed solution. However, since we will be interacting with the web application and a custom timer job in this chapter, we will work with a farm solution throughout this chapter.
3.16.79.65