Starting Development with SharePoint 2010
Hour 1, “Introducing SharePoint 2010,” gave you an overview of SharePoint 2010, and Hour 2, “Understanding the SharePoint 2010 Architecture,” looked at SharePoint’s architecture. If you are the typical developer, by now you are probably anxious to write some code. In this hour you begin by writing code in SharePoint 2010 in the form of a console application. After that you learn about SharePoint features and solutions, and then write your first SharePoint feature. Finally you learn about debugging techniques in SharePoint and how they differ from a normal ASP.NET application.
You just wrote your first code and used two important objects of the SharePoint Object model that you will find yourself using almost everywhere. The SPSite represents a SharePoint site collection. The SPWeb represents a site within the site collection. In this case we are accessing the top level site by making a call to the OpenWeb() function of the SPSite. We could have also accessed the top level site by accessing the RootWeb property of the SPSite. However, it was important for you to see the OpenWeb() method and overload that you will be using to access the subsites method as well. Hour 7, “Understanding SharePoint 2010 Server Side Development,” discusses most objects of the SharePoint object model in detail. However, it is helpful to get acquainted with a few of the objects that you will use frequently. You might have observed that SPSite and SPWeb represent the site collection and the site in the SharePoint hierarchy that we looked at in Hour 2. Following are the other objects in the SharePoint hierarchy:
- SPFarm—This class represents a SharePoint farm and is a part of the Microsoft.SharePoint.Administration namespace. You can access the local farm instance through the SPFarm.Local object.
- SPWebApplication—This class represents a SharePoint web application and is also a part of the Microsoft.SharePoint.Administration namespace. You can access the WebApplication instance of a site through the WebApplication property of the SPSite class instance.
- SPContext—This is an important class that represents the context of the request in SharePoint. You can access various important objects of SharePoint like the SPSite and SPWeb instances for the current request through this object. To get access to this object you call SPContext.Current.
You will see as you proceed further in this book that SharePoint provides a rich object model, and you learn about many objects in detail.
Understanding SharePoint Solutions as Deployment Units
Although console applications are a great way to play around with the SharePoint API, you will not be using them to deploy new functionality to SharePoint. The recommended way to deploy functionality is through SharePoint solutions, which are cab files with a .wsp extension, which stands for Windows SharePoint Solution Packages. The most important file in the WSP file is the manifest.xml. This file contains information about the other files in the solution. In SharePoint 2010 you can create two types of solutions: farm solutions and sandboxed solutions.
Understanding Farm Solutions
A farm solution is a SharePoint solution that is deployed to the Solution Store in Central Administration of your SharePoint farm. People who have worked with SharePoint 2007 will find this familiar.
You have now built and deployed your first SharePoint solution. In the preceding output you can see that your HelloWorldVWP feature was activated while deploying. This means that the web part is now available for adding to the pages in the site.
In the preceding scenario we deployed the solution directly through Visual Studio. But we could have just as easily packaged the solution by right-clicking on the project and clicking on Package. We could then deploy the solution using the following stsadm commands.
Stsadm -o addsolution -filename HelloWorldFarm.wsp Stsadm -o deploysolution -name HelloWorldFarm.wsp -url http://splearn –allowgacdeployment
You can see the contents of the .wsp file generated when you packaged the solution. To view the contents of the .wsp, perform the following steps:
- Go to the Bin\Debug folder of your project. Rename HelloWorldFarm.wsp to HelloWorldFarm.wsp.cab.
- Open the .cab file and you should see the contents of the solution, as shown in Figure 3.7.
- Select the Details view and notice the path column.
Figure 3.7. Contents of the WSP file
- Open the manifest.xml file. You can see it contains all the information about the contents of the solution, as shown in Figure 3.8.
Figure 3.8. Sample manifest.xml
- You can also find the SafeControl tag for the web.config file, which is required to allow the web part to run on your site.
- Now browse to the <14 Hive>\Template\Features folder and you should see a directory named HelloWorldFarm_HelloWorldVWP. Notice that this maps to the path column in the WSP file. Also go to the <14 Hive>\Template\CONTROLTEMPLATES folder. You can see your HelloWorldFarm folder in there. Notice again that this maps to the path column in your WSP file.
Browse to your SharePoint 2010 Central Administration site. Navigate to System Setting and under Farm Management click Manage Farm Solutions. You should see your solution along with other solutions, as shown in Figure 3.9.
Figure 3.9. Solution Store in the SharePoint 2010 Central Administration
Finally you can see your web part in action. Follow these steps:
- Browse to your SharePoint site (in my case it is http://splearn).
- Select the Page tab on the ribbon and click Edit. Two new tabs—FormatText and Insert—appear.
- Go to the Insert tab and click web part. The list of web parts appears below the tab.
- Select Custom under Categories on the left side. You see your HelloWorldVWP web part, as shown in Figure 3.10.
Figure 3.10. Insert web part screen
- Click Add and the web part is added at the top, as displayed in Figure 3.11.
Figure 3.11. HelloWorldVWP web part added to top zone
One of the most important factors that differentiate a farm solution from a sandboxed solution is that the farm solution is always deployed to your Central Administration Solution Store. Farm solutions can run any type of code without any restrictions. This can be at times counterproductive as there is an increased chance that some code can bring your entire farm down.
Understanding Sandboxed Solutions
Sandboxed solutions are newly introduced in SharePoint 2010. Sandboxed solutions are not deployed to your Central Administration Solution Store like farm solutions. They are deployed to the solutions gallery of your site collection. Also they run with a lot of restrictions compared to farm solutions. In addition sandboxed solutions do not run under the worker process like farm solutions but in a special process known as the Sandboxed Code Service. You can see this service by browsing to SharePoint 2010 Central Administration, System Settings, Manage Services on Server. There you can find the Microsoft SharePoint Foundation Sandboxed Code Service as shown in Figure 3.12. Make sure that this is started.
Figure 3.12. The Manage Service On Server screen in SharePoint 2010 Central Administration
Though we created and deployed simple web parts without much functionality, the steps to create and deploy web parts will be applicable to most of the other things including more complex web parts and other project types in SharePoint. However you need to know when you should create sandboxed solutions and when you should create farm solutions. Sandboxed solutions are the recommended way to go in SharePoint 2010 as they can be monitored more easily and due to restrictions imposed on them cannot cause issues that rogue code in a farm solution might. Sandboxed solutions are an important topic, and Hour 21 is devoted to them. You should go with a farm solution only if you cannot achieve the functionality through a sandboxed solution due to the restrictions imposed on them. Even then various workarounds are available for overcoming the sandboxed solutions’ restrictions as you see later.
Understanding Sandboxed Solutions Restrictions
It is important to know the restrictions imposed on sandboxed solutions if you are to be able to work with them. Following are the SharePoint project items that will not work with a sandboxed solution:
- Visual web parts
- Application pages
- Custom action group
- HideCustomAction element
- Content type binding
- Web application-scoped features
- Farm-scoped features
- Workflows with code
Don’t worry if you do not understand all the items listed here. You will come across all these items in subsequent hours. In addition to the previous items, you can access only the following from the SharePoint object model in a sandboxed solution:
- All of Microsoft.SharePoint, except
- SPSite constructor
- SPWorkItem and SPWorkItemCollection
- SPUserSolution and SPUserSolutionCollection
- Microsoft.SharePoint.Utilities, except
- Microsoft.SharePoint.WebPartPages, except
In addition to the preceding restrictions the administrator can apply further restrictions to the API. The Microsoft.SharePoint.Administration.SPWebService class provides a collection in the form of the API block list that enables an administrator to specify additional types in the API to block.