During the previous recipes, we saw Visual Studio automatically uploading a solution and activating it for our test purposes. The entire step-by-step process that Visual Studio does in order to deploy a solution to the site can be seen in the output window as shownin the following screenshot Development is all done and now we need to deploy this solution to production. Here are the step-by-step instructions on how we deploy solutions:
It is necessary to understand the concept of event receivers to follow through this recipe. It is advised to complete the previous recipes sucessfully.
Open the previously created ListItemEventReceiver solution.
Open the project properties window by right-clicking the project and selecting Properties.
Select the Build Tab and set the Configuration to Active (release).
Rebuild the solution from menu Build | Rebuild.
From the same build menu, select Package to make a package of this solution. This will generate a
.wspsolution file in the
binfolder of your solution as shown:
To add the solution to the solution store use the command:
stsadm –o addsolution –filename ListItemEventReceiver.wsp
To deploy the solution use the command:
stsadm –o deploysolution –name ListItemEventReceiver.wsp –local -allowgacdeployment
stsadm –o installfeature –filename ListEventReceiver_Feature1\Feature.xml
You can navigate to Manage Site Features from Site Action | Site Actions | Manage Site Features. You should see your Feature deployed to the site but not activated as shown:
You can activate the feature by clicking the Activate button.
When we built and packaged our solution, a
.wsp solution file was created. This is nothing but a CAB file contaning feature file and the items that the feature is going to install. You can rename the
.wsp file to a
.CAB extension and open it through any ZIP file extractor. The following is a screenshot showing the contents of a
.wsp file contains the DLL, Application Page, and three different XML documents. These XML documents provide the necessary information on where the resources need to be deployed. Open up the
manifest.xml in notepad. You can see it lists the locations of the Application Page, Event Receiver DLL, and the Feature.
In SharePoint, a Feature is nothing but an XML file. The XML file is named
Feature.xml. This XML contains the name, the ID, and the scope information of the feature. The name and the ID attributes of the Feature uniquely identifies the Feature. An ID is a GUID in the format "
x is a hexadecimal number that can be from 0-9 and a-f. When you created the solution, Visual Studio automatically created this GUID.
Feature.xml also includes the location of the Event Receiver's
Scope indicates how the Feature needs to be scoped. You can scope a Feature in four ways:
Farm Level: This can be activated at a farm level. That is, all the web applications in the farm will have access to the feature.
Site Level: Can be activated at site collection level, meaning all the sites in the sites collection will have access to this feature.
Web Level: Can be activated for a specific website.
Web Application Level: Can be activated for all sites in the web application.
Add-SPSolution –LiteralPath <Location of your wsp> Install-SPSolution -Identity <WSPName> -WebApplication <URLname> Enable-SPFeature FeatureFolderName -Url <URLName>