Creating and Deploying SharePoint Solution Files

Creating and Deploying SharePoint Solution Files

harePoint Solution Package files are Microsoft’s “preferred choice” for deploying Windows SharePoint Server (WSS) components. A Solution Package is a single compressed Windows Solution Package (.wsp) file containing all the necessary resources. A .wsp file can contain one or more WSS components. This article explores how to create and deploy SharePoint Solution Packages to your SharePoint server.

Why Deploy Solution Files?
You should not simply copy files to deploy your SharePoint application to a web farm with multiple servers. Instead, by deploying solution files in lieu of manually copying them, you can avoid errors that might otherwise occur if you were to attempt to uninstall the solution manually. Furthermore, it’s cumbersome to have to alter your web.config files manually, and deploy custom dynamic linked libraries to the GAC, and to each and every bin folder on multiple servers?just to deploy a web application. In essence, deploying Solution Packages is both easier and more robust than copying files manually.

Creating and Deploying SharePoint Solution Files
Here’s a step-by-step approach to creating and deploying a SharePoint Solution Package.

Figure 1. Create a Sample Project: Create a new ASP.NET Web Application project.

Create a Sample Web Application Project
Open Visual Studio and select File ? New ? Project from the menu. Select the ASP.NET Web Application template from the list of available templates (see Figure 1).

Name the new project “DevX,” and click OK to create the project.

Create the Folder Structure
Next, you need to create an appropriate folder structure. First, create a folder called Source under the solution folder. Inside the Source folder create a sub-folder called DevXList. Inside the DevXList folder, create two more folders: ListTemplates and Messages (see Figure 2). You’ll use those folders later to hold the manifest and schema files for the application.

Figure 2. Folder Structure: Here’s the folder structure for the sample application as seen in Solution Explorer.

Create Feature and Manifest Files
You’ll create a feature based on the SharePoint discussions list. To do this, create a new file named feature.xml that will hold the feature information. This file references two other files that you’ll also create: DevXListManifest.xml and schema.xml. Here’s the content for the feature.xml file:


Next, create a DevXListManifest.xml file with the following content:

           ?Figure 3. Sample Application Structure: Here's how the sample application should look after you've created the DevXListManifest.xml and schema.xml files.      Type="108"      BaseType="0"      OnQuickLaunch="FALSE"      FolderCreation="FALSE"      SecurityBits="12"      Sequence="999"      DisplayName="DevX List"      Description="This is a sample list"/>   

To create the schema.xml file, copy the existing schema.xml file from the following location:

   C:Program FilesCommon Files      MicrosoftSharedwebserverextensions12TEMPLATEFEATURES      DiscussionsListDiscuss 

Paste the file into the DevXSourceDevXListMessages folder that you created earlier. In Solution Explorer, your project should now look like Figure 3, with the feature.xml file in the DevXList folder, the DevXListManifest.xml file in the ListTemplates folder and the schema.xml file in the Messages folder.

Create Manifest and Data Definition files
Finally, you need to create a manifest.xml file in the Source folder. The manifest.xml file should refer to the feature.xml file you created earlier:


Create a Data Definition File
The next step is to create a data definition file (.ddf). This file contains the instructions required later by the makecab.exe utility to create the cabinet (CAB) file. Here’s the content:

   .OPTION Explicit ; Generate errors   .Set DiskDirectory1=""   .Set CabinetNameTemplate="DevX.wsp"      manifest.xml   .Set DestinationDir="DevXListListTemplates"   DevXListListTemplatesDevXListManifest.xml ; specify cab file name   .Set DestinationDir="DevXListMessages"   DevXListMessagesschema.xml   .Set DestinationDir="DevXList"   DevXListFeature.xml

Check out this link for a basic explanation of the .ddf command syntax.

Creating the Solution File

Figure 4. Generating a Solution Package: A Solution Package is simply a CAB file with a .wpf extension, so you can use the makecab.exe tool to create it.

With all the prerequisites in place, you can now build the Solution Package file, which is simply a CAB file with a .wsp extension that you can deploy. The.wsp file can contain one or more of the following resources:

  • Assemblies
  • Features
  • Web Parts
  • Web Pages
  • Templates

The simplest way to create a CAB file is to use the makecab.exe command line tool, passing the .ddf file as an argument as shown in Figure 4:

By default, makecab.exe tool generates the output CAB file in the Bin directory with the name DevX.wsp.

Adding the Solution File

Figure 5. Adding the Solution Package: Add the Solution Package using stsadm with the -addsolution option, passing it the name of the .wsp file.

You need to add the Solution file to SharePoint Server using the stsadm tool, which you’ll find in the following folder:

   C:Program FilesCommon FilesMicrosoft Shared      web server extensions12BIN 
Author’s Note: The stsadmtool is easier to use if you add its path to your %PATH% system variable using the Windows path command.

Finally, use stsadm to add the solution file as shown in Figure 5.

Deploying the Solution File
After adding the solution file, the next step is to deploy it, which you also do with stsadm, using the ?deploysolution option as shown in Figure 6:

Figure 6. Deploying the Solution Package: To deploy the package, call stsadm with the deploysolution option, passing it the name of the package file, and options to control where and how to deploy it.

Figure 7. Deployed Solutions List: The devx.wsp file now appears in the list of deployed solutions in SharePoint Central Administration.

The -local option deploys the solution on the local machine, and the -force option causes the deployment to overwrite existing files.

Author’s Note: You can find a complete reference to the stsadm command and its options by browsing to the following sites:

You’re almost done. You’ve created and deployed the sample DevX.wsp file to WSS. To verify that the solution file deployed properly, open SharePoint Central Administration and then switch to Operations ? Solution Management.

You should see the DevX.wsp solution file in the list of the deployed solutions, as shown in Figure 7.

Activating the DevX Feature in SharePoint Server
Figure 8 shows a Windows Explorer view of the folder where the features are physically stored.

Figure 8. Deployed Features: The figure shows the location where SharePoint stores features.

Another way to check whether the file deployed properly is to switch to the Site Settings ? Site features option in SharePoint Central Administration. Here, you can see a list of features that WSS has added (see Figure 9). As you can see from Figure 9, the sample DevX Feature is listed?but it is not yet activated.

Figure 9. Activating Features: You activate and deactivate Site Features from SharePoint Central Administration.

To activate the feature, click the Activate button in the same row as the feature name (see Figure 9). That activates the feature and prepares it for use. Activated features have an “Active” icon, and the Activate button changes to “Deactivate” (see Figure10).

Figure 10. Activated Feature: Activated features get an “Active” icon and the button label changes to “Deactivate.”

You can also activate a feature using the stsadm command line tool, using the following syntax:

   stsadm --o activatefeature       --name        -url http://Server/Site/Subsite

By following the steps listed in this article, you’ll find that creating and deploying Solution Packages is far simpler than trying to deploy applications manually to multiple servers.

For further reading, see these links:


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist