SharePoint 2007: Using WSPBuilder for rapid deployment

Assuming the readers of this post are not new to SharePoint development, it’s a known fact that SharePoint development isn’t as easy as developing on ASP.Net. Contrary to ASP.Net development where pages developed can be viewed by right-clicking on it and viewing it in browser; SharePoint takes much more than that! A matter of fact, a SharePoint WebPart takes around 11 steps right from developing it to deploying it, populating it in WebPart Gallery before getting it displayed on SharePoint pages. And surprising it might seem, even some of the most experienced SharePoint experts err while following this procedure ... ☺ ☺

Talking about real-life scenarios in service-driven companies where SharePoint developers do not have access to production servers; the only way deployment happens is through client’s onsite SharePoint Administrator. This makes developers write a painful and lengthy deployment document along with all source-code files bundled. With WSPBuilder, deployment becomes a click-once process or call it a single-command process. WSPBuilder helps to make a Solution Package (i.e. a .wsp file) using Visual Studio 2005/2008.

---

Solution packages are the preferred mechanism for deploying WSS components. The solution package itself is a compressed CAB file with a .wsp extension, and it contains one or more WSS components along with any dependent files that need to be deployed on each front-end Web server.

A simple solution package might contain just the files needed to deploy a single feature. A more complex package could contain the files for multiple features, applications pages, Web Parts, list definitions, event handlers, and a site definition. You decide what goes into a solution package according to what set of components it makes sense to deploy as a single unit.

The WSS runtime provides a built-in installer component that runs on each front-end Web server and is responsible for uncompressing the files inside a solution package and properly installing its components.

The Solution package tells the installer to perform other important deployment procedures, such as registering features with the WSS runtime, adding assembly DLLs to the Global Assembly Cache (GAC), and updating the web.config file with SafeControl entries required in Web Part deployment.

---

Requirements: WSPBuilder Extensions

Current version: WSPBuilder Extensions 1.0.6
(supports MOSS 2007 x86 / x64 bit, IIS6 / IIS7 on VS 2008)

Date: Jul 29, 2009       Status: Stable

Other awaited release: WSPBuilder Extensions 2010 BETA 1.4
(supports SharePoint 2007/2010 x86/x64 bit, IIS6/IIS7 on VS 2008/2010)

Release Tracker: Here

Issue Tracker: Here

---

Example: Deploying a MOSS 2007 WebPart with ASP.Net Web User Control (i.e. .ascx) using WSPBuilder

Check this blog post of mine Here on how to create SharePoint 2007 WebParts with ASP.Net Web User Controls.

Step 1: Create a new WSPBuilder project in Visual Studio 2008





Step 2: Create the folder hierarchy as required and copy the required files within the folder structure

Once created, you will witness the folder structure in the Solution Explorer as follows. Note the following points:

• The 12 hive in Solution Explorer corresponds to the 12 hive where Microsoft SharePoint has been installed. The subsequent folders like GAC, TEMPLATE/LAYOUTS, TEMPLATE/FEATURES, TEMPLATE/XML, etc have to be created explicitly underneath the 12 hive which correspond to the existing locations. The files kept in these folders will be deployed at the exact locations on all front-end servers relative to their 12 hive.

• The GAC hive in Solution Explorer corresponds to the GAC (Global Assembly Cache) on all front-end servers. A DLL kept here would be copied to the server’s GAC when the Solution Package is installed.

• Add reference to libraries as required in the WSPBuilder project. As an example, you’ll need to add reference to ‘System.Web’ library in the project for a successful build if you have an ASP.Net Web User Control added.

• The WSPBuilder.exe.config file plays the same role as that of web.config but for the WSPBuilder project. This file is not present by default when the WSPBuilder project is created so it has to be manually copied into the project. A sample wspbuilder.exe.config file is present at the install path of WSPBuilder in /Program Files/WSPTools/. Please make sure you don’t modify that file there and that you copy this file to your project and then make modifications to it. One of the <appSettings> attribute in the config file is <add key="Includefiletypes" value="cs" /> which means it’ll allow files with .cs extension to be bundled into the Solution Package which by default it doesn’t allow. Check the below snapshot for details.

For the purpose of this example, I have created the required folders below the 12 hive and copied the Web User Control underneath it. Also, the DLL for the WebPart has been copied under the created GAC folder. A point to note, please make sure you follow the naming conventions and rename the folders appropriately and as per convention.


Step 3: Build the project and create a WSP

If you have any files added to the directories which need compilation then Build the project by pressing F5. When done, right-click on the solution > WSPBuilder > Build WSP. On successful completion, a .wsp file would have been created at the project location.








Step 4: Deploy the WSP using the stsadm utility

Open the command prompt and traverse to the location where the .wsp file is located. Run the following command making sure the filename is exact.

stsadm –o –addsolution –filename Sample_WSPBuilder.wsp

Step 5: Deploy the solution from the Operations Tab of Central Administration Site

Browse to the Central Administration Site > Operation Tab > Global Configuration > Solution Management





Click on sample_wspbuilder.wsp in the list and click on ‘Deploy Solution’ in the following page.








Once clicked on ‘Deploy Solution’, the following page will display the time when you want your solution to be deployed and which Web Applications to target. The default time is now and all content web applications. Click OK to proceed.





The solution package is now deployed which is evident from the snapshot below.





Once deployed, the following actions have been achieved:

•  WebPart’s DLL has been copied to the GAC. Also to the bin folder of the SharePoint virtual directory with its .pdb file.

•  The ASP.Net Web User Control (i.e. .ascx and .ascx.cs) files have been copied at the “12/TEMPLATE/LAYOUTS/PhotoGallery/” location.

•  The necessary SafeControl entries in web.config have been made automatically and the previous web.config file has been backed up with .bak entension.

Step 6: Following the required steps to view the WebPart

Make sure you follow the required steps of populating the WebPart Gallery and adding the WebPart to a SharePoint page.

Any questions, please feel free to put them in the Comments section.

Note:

•  The solution can be undeployed in the similar fashion by clicking on the Solution package name in Solution Management and then ‘Remove Solution’.

•  If you want to remove the solution package at Farm level then first undeploy the solution using the previous step and then use the following command. Note that this would uninstall the DLL’s in GAC and delete the subdirectories in 12 hive (as created by the WSP when installed) from all front-end servers.

stsadm –o –deletesolution –name Sample_WSPBuilder.wsp –override

---

You can download the source code Here:

---

Key Learning SharePoint component deployment can be made easy with WSPBuilder. Once the WSP is created, developers should try deploying the same on their development environment and when successful, handover the same to the SharePoint Administrators for deployment on production servers.

---

Post a Comment