Building and Deploying a SharePoint 2010 Project with Team Builds
Part 1 of 3
In this month’s article we will be looking at the environment setup that is needed for SharePoint development. We will also share some available resources and help familiarize the SharePoint project structure (Features, Elements and Package).
At first glance, the SharePoint build and deployment appears to be straightforward. At a simplistic and high-level view, we have a solution with Features, Elements, and C# code that can be packaged into a “.wsp” type file. This file can be deployed to a SharePoint site to show results rather quickly. This process allows a developer to make required changes to the code while in the development phase. In addition, we now have a Sandbox options for developers to work in. Through a MS build argument “/p:IsPackaging=true”
You can create a “.wsp” package of your solution as part of a more formal build and release process. However, without a fully automated and integrated process for SharePoint development, build, and deployment, some questions and best-practice problems arise:
· How can I get a Continues Integration (CI) build and deployment for SharePoint?
· How can I get the SharePoint build and deployment incorporated in testing and release cycle.
· How would a SharePoint deployment cycle fit into a current Agile or Scrum practices?
As you can see by the questions above, we have number of both technical challenges and process questions to address.
In the previous version of SharePoint, is has not been easy to establish a normal Software Development Lifecycle. Moving the code through development, testing, and release has been challenging due the lack of a solid version control code and reliable build, and test and release process (to name a few). With SharePoint 2010, Team Foundation (TFS) and Visual Studio 2010 (VS2010), we now have new tools to make the above questions easier to address and provide answers for. This series will be focused on the build and release. We will also be touching on version control and testing using Test Professional (For the purpose of this article we will tread lightly over Version Control, Test Professional, and Agile or Scrum practices, as they are large topics onto their own).
Before we dive in, I would like to set a baseline of working knowledge and the environment setup that will be needed. In the next series, we will need an environment to work in. This will consist of TFS 2010, VS210, Build Controller/Agent, SharePoint installation (local or remote), and permissions to all environments and the Build Controller/Agent.
If you need to setup TFS on an interim or test server, you can download a 90-day trial version. I would recommend that you setup up your TFS server during the third week of November, as this will ensure enough time for you to benefit from our entire three-part article series before the 90-day trial ends.
It is highly recommended to review the following links to ensure familiarity with the tools and concepts.
1. Configuration and using Team Foundation Server 2010
We will be using Team Build for our packaging and deployment. Having a working Build Controller Agent and full access to both will be required.
Please review the following links for more information regarding:
2. Installation and Configuration of SharePoint 2010
3. Scripting knowledge
4. SharePoint Development
SharePoint 2010 features a number of new project templates that are available within Visual Studio 2010.
In fact, there are too many to point out here! Instead, I refer you to the following article which explains the new project templates in details: Top 10 New Developer Features
There are a number of sites covering SharePoint Development. For our walkthrough, I will create a simple Empty Project and then add an Empty Element. The Empty Element will have a Custom Action that will Display a link.
To get started I’m going to create an Empty SharePoint Project in Visual Studio.
1. Open Visual Studio | File | New Project |
2. Select SharePoint 2010 | Select .Net Framework 4 | Select Empty SharePoint Project
3. In the Name Field |Rename the project to MSNURL |Click OK
4. In the SharePoint Customization Wizard
Enter the site URL | Select Deploy as a Farm solution radio button | Select Finish
Note: I am using the “my Team Site B” that I have setup and have permissions to. Your site URL might be different.
5. In Solution Explorer, expand the Project Solution, Empty SharePoint project. You will see we have the common Properties and References as any other project. We also have two additional folders called Features and Packages
We need to add a new Empty Element project to the Project.
6. Right Click on the MSNURL Project | Select Add | choose New Item
7. In the “Add New Item –MSNURL” | Installed Templates | Select SharePoint 2010 | Select Empty Element project templates.
8. Rename the Empty Element to msnUrlLink | Select Add.
NOTE: If you look at the upper left corner, you will see “Add New Item – <Project Name>”. In the New Project, (File |New |Project) you will notice that you are not able to find the “Empty Element” Item. This is because Items are in a project and need to be added from a project. How I remember this is, projects are like containers and can hold many different types of items.
Once the new “msnUrlLink” Element loads into the MSNURL Project we can add the code for our MSN URL Link
9. Double click Element.xml | Copy and paste the code below into the Element.xml file
<?xml version=”1.0″ encoding=”utf-8″?>
<CustomAction Id=”MSN Libary” GroupId=”SiteActions” Location=”Microsoft.SharePoint.StandardMenu”
Title=”MSDN Library ” >
<UrlAction Url=”http://msdn.microsoft.com/library/default.aspx “/>
10. Right click on the project | Click on Build (or Ctrl + Shift+ B)
If everything builds correctly, check in the project into Source Control.
Note: I am using Team Foundation Server (TFS) your source control may be different
11. Select Source Control Explorer | Right click MSNURL project | Select “Check In Pending Changes…”
12. In the Check In – Source Files – Workspace:<your TFS Server> | Add Comment: | Click the Check In
*Note: having code checked in to a source control system is very valuable. I know from my own experience, as I have worked on a piece of code that has changed and then has a bug, either by my own doing or by someone else’s. By having options to look at the history or changes, and to be able to revert code back to a known working point, is not only a huge benefit but also critical to any development cycle and process. We can associate the checked-in code to a Work Item that is a part of the story, task, or agile process.
Let us look at the other items that are in the SharePoint project. If you look at the project, you will see Properties, References, Features, Package, and the Element that you been working with. Starting at the top: Properties and References items are a common project items that we normally would see in a typical project. The Features are a place where we can select the items in the solution to include into the Feature folder. You can add more features with different items. Feature is the set of code you wish to activate or disable in your SharePoint site. Since there is so much to cover on features, I would like to refer you to the following article for more information: Using Features in SharePoint Foundation.
13. Expand the Features node | Double click on Features1.feature
Features1.feature menu will open. In this feature menu, you have a number of configuration options for that Feature
Some of these options are:
· Set the site scope for the feature
· Select and move an item from the solution into the feature
· Add Features Activation Dependencies
The Feature Property list that has a number of options for activation, configuration, and deployment.
· Activate on Default
· Always Force Install
· Feature ID
· Deployment Path
14. Expand the Package.package node | Double click on Package.package
In the Package.package you can select what will be the .wsp file for deployment. There are a number of options to select for the .wsp
Some of these options are:
· Option to reset IIS web server
· Select and move an item from the solution into the package
· (Advanced setting) Add Existing Assembly and Assembly from Project Output
· Package Explorer that shows the items properties information
· Package properties has the package setting that can be edit
Now let’s deploy our solution using Visual Studio.
15. Right click on the MSNURL project | Select Deploy
Notice that the .wsp package was created and saved to the ProjectBinDebug folder. It has the information to deploy the project and Element to the site that you select when creating the package.
The package script also runs the preset of actions to deploy the package to the SharePoint Site. The default actions are:
· Run Pre-Deployment Command
· Recycle IIS Application Pool
· Retract Solution
· Add Solution
· Activate Features
· Run Post-Deployment Command
16. Check to see if your feature has deployed correctly. In this case, we deployed the feature to our Site Action (GroupId=”SiteActions” ) and the location is set to (Location=”Microsoft.SharePoint.StandardMenu”)
17. Open the SharePoint Site | Select Site Actions
Once you have verified that the link has been deployed and it’s working, we need to we can retract the package from the SharePoint site.
18. In Visual Studio | Right clicking on the MSDURL Project | choose Retract
Notice that the Retract does the following “Recycle IIS Application Pool” and “Retract Solution”. This is show in the out put window
The deployment configuration setting are in the SharePoint tab in the proejct properites.
You can see this Default deployment configuration by look at the “View Deployment Configuation” page.
19. Right clicking on the MSNURL Project | Select Properties
20. Select the SharePoint Tab |Select Default | Click on View
This will bring up the View Deployment Configuriation page. As you can see, you can not edit the default deployment configration. You can set the project to No Activation, which will compile the project but not deploy the features to the SharePoint site. You can also create a New deployment configuation steps using the defaults steps that are avaliable. You can also create your own custom action steps “Copy WSP File”. This will be covered in next Months session
SharePoint 2010 makes development much easier than before. In our SharePoint Project, we are able to create an Empty Project and add a number of different Project Templates that are available in Visual Studio 2010. As we have seen, we are able to work in Visual Studio and check in and out like code as any other application. This is a key added benefit because we know can treat the SharePoint development like a real software deployment, and we are able to put the development story or request in a process like Agile and Scrum.
Next month we will dive into how to create a SharePoint Team Build. We will also show how to pass parameters from the Team Build into a PowerShell script to deploy the .wsp package to a site, and to have a Continuous Integration (CI) type of Build process. We will also touch on Testing and create a custom deployment step (condition logic check) class in C#.
Check out the following resource links for further reading:
Looking for additional information on Integrating SharePoint Development into an End-to-End ALM Process?
We would be happy to discuss your SharePoint needs and how Northwest Cadence can be of service.
Have you participated in the FREE ALM Catalyst Program yet? Northwest Cadence is excited to offer a 1-hour session on SharePoint Development Tools, as part of this program!
Contact Rick.Flath@nwcadence.com to learn more!
In January 2012, Northwest Cadence is pleased to offer a 4-hour remote training event: Building and Deploying a SharePoint 2010 Project with Team Builds
When: January 10, 2012
Price: $99.00 per person
Join Northwest Cadence as we provide you with an overview of a SharePoint 2010 Project, dive into the details of creating a SharePoint package from Team Foundation Server 2010 Team Build, and then deploy the .WSP package to a SharePoint test site.
Questions? Please contact Rick.Flath@nwcadence.com