Developing SharePoint Solutions for SharePoint Foundation provides developers with many opportunities to build powerful and dynamic solutions. It also helps lower costs to the organization because of the ability to quickly develop solutions. In the past, some organizations were hesitant when considering implementing custom SharePoint Solutions, because they felt that it would be a long and costly process to develop a solution. This fear has been greatly reduced with SharePoint Foundation because of the improved development process, new features, and tools.
These new tools help developers to:
Streamline the design of workflows to build automated business processes.
Develop SharePoint solutions faster, based on SharePoint project templates.
Integrate with external systems more efficiently by utilizing the Business Data Connectivity services.
Create powerful custom application pages for SharePoint.
Create and validate solution packages faster.
Debug SharePoint solutions faster.
Getting solutions packaged and deployed to other SharePoint Foundation environments is another critical component of development. In earlier versions of SharePoint, tools such as the WSP Builder and the stsadm command line were used to create a .wsp file and deploy custom workflows to the server. In Visual Studio 2010, packaging and deploying custom workflows to a SharePoint Foundation environment has been made simple and more efficient through the use of the Package Designer, Packaging Explorer, and PowerShell scripts.
Note
Microsoft has released a number of developer resources including the SharePoint Guidance 2010 Hands-On Labs, which you can view at http://spg.codeplex.com/releases/view/60343; and the SharePoint 2010 Developer Resource Centers at http://msdn.microsoft.com/en-us/sharepoint/bb964529.aspx.
Once you have modified your site via the browser and SharePoint Designer, you can package it as a .wsp file and hand it over to the central SharePoint support team so that they can make it available to other users or use your work as a basis for further customizations. In previous versions of SharePoint, when you saved a site as a template, a .stp file was created which contained the differences between the site created from the site definition and the customizations that were created by using the browser or SharePoint Designer. Now a .wsp file is used when you create a site template. It contains the ONET.XML file from the original site definition and details of features, elements, and optionally, the content from the site.
You can use one of the new features in Visual Studio, Import SharePoint Solution Package, to import the .wsp file to create reusable artifacts, such as list definitions, content types, and fields. This greatly improves the development process—developers now have the ability to quickly create a list or site template by using out-of-the-box functionality in the browser. You can take the templates and automatically generate the schema and configuration for the definitions in Visual Studio. You can then manipulate the files to fit your specific need. Once you’re done, you can easily deploy this solution to your farm where it can be used across multiple sites. Currently this is restricted to items created in SharePoint Foundation 2010 and SharePoint Server 2010. In the following, you will find an example of how to import a solution.
To import the components into Visual Studio for this example, you will need to create a Site called Import Demo by using the browser or SharePoint Designer in your SharePoint Foundation environment. Once this site is created, start a new document library called Test Template. Save the site as a template called ImportDemoTemplate. Once the template is created, save the ImportDemoTemplate.wsp file to a location on your computer.
Now that you have a customized site set up, you can work on creating a solution based on the list definition by completing the following procedure:
Open Visual Studio, click New | Project, and then in the New Project dialog box, under Installed Templates, in the language of your choice, select SharePoint and click 2010.
Click Import SharePoint Solution Package.
Type SPFINWspImportProject1 for the Project Name, and then click OK.
Specify the site and security level for debugging, and then click Next to display the Specify The New Project Source page of the SharePoint Customization Wizard.
Click Browse, navigate to the location where you saved the .wsp file, click Open, and then click Next.
On the Select Items To Import wizard page, clear all of the items in the list, by pressing Ctrl+A and then pressing the Space bar.
Select Test Template List Instance from the list, and then click Finish.
A Selection Dependency Warning dialog box opens, asking whether you want Visual Studio to automatically include all the required dependencies detected in the .wsp file. Click Yes, and then click OK to the Import Completed dialog box.
Notice that the wizard has automatically created the Features and Packages needed to build and deploy the solution. It has also created a List Instances folder that contains the Elements.xml and Schema.xml files.
You can now build and deploy the solution to your SharePoint environment.
Up to this point in this chapter, the customizations and solutions you’ve built can be used in situ; that is, they have been developed on the site where they are to be used. However, there might be occasions where you build the solution on one site and need to recreate it on one or more other sites. This is particularly true in large organizations, where you build your solution in a development environment, and then it must go through a release management process before being deployed to the production environment.
There are many ways to deploy customizations and solutions in the SharePoint environment. In a small organization, the ability to re-create customizations and solutions quickly relies on fast installation and deployment methods. In larger organization, there might be a need for a more complex method.
Once you have completed your testing, you need to build a release version of your solution. As with any other Visual Studio project, the finished files are created in the <project name>/bin/Release folder. It is in this folder that you will find the .wsp file that you will hand over to the build managers of the other environments or to the server administrators of your production environment.
SharePoint solutions are often created by non-IT users—citizen developers—who have a day job and do not have the time or business sign-off authority to maintain and enhance the solutions. Therefore, once customizations and solutions are developed, with the recognition that these need to be deployed again, the responsibility for these customizations and solutions might need to be handed over to a central department. No matter which packaging and deployment method is used, customizations and solutions must always be documented and tested, and depending on the solution, there must be plans for installation, upgrade, patching, and removal.
Debugging applications developed for SharePoint Foundation 2010 has been greatly simplified in Visual Studio 2010. When a project is started based on one of the SharePoint 2010 templates, the SharePoint Customization Wizard assists you in specifying the different components that you will need to debug your solution. For example, when a workflow is created, the Customization Wizard prompts the user to enter the site and lists the components that the solution is to use for debugging. Once the user has added the necessary code to the solution, the user need only press the run button (F5) to deploy the solution and start the debugging process. The default deployment configuration performs the following steps:
Run predeployment command
Recycles the Internet Information Services (IIS) application pool.
Retracts the solution, if it was previously deployed
Adds the solution
Activates the Feature(s)
Runs the post-deployment command
At this point, the user can place breakpoints in the code and step through the process, just as you can with any other .NET application.
Tip
INSIDE OUT Modifying the default Visual Studio deployment configuration
To create, modify, delete, or to change the default Visual Studio deployment configuration, open the SharePoint property page by right-clicking the project name in Solution Explorer. Click Properties, and then click the SharePoint tab.