Back in the pre-WSS 3.0 era, one of the biggest challenges was the deployment of your SharePoint projects, especially in farm scenarios. Each time you wanted to deploy a solution, you had to deploy it to each and every server. With WSS 3.0, the SharePoint team introduced a new deployment mechanism: SharePoint Solutions.

  A Solution is nothing more than a CAB file with a .wsp extension. It contains a file named "Manifest.xml" and several other files depending on what you are deploying. It is important that the file is named Manifest.xml (case insensitive) otherwise it wont be identified as a Solution package. The manifest.xml describes the solution in addition to what and where is to be deployed. For a complete schema of the solution see Solution Schema. As an example I will show you how to create a basic web part deployment package. Consider the scenario where you have created a web part inside the assembly MyWebPart.dll with the web part property file mywp.webpart. Here is the relevant manifest.xml:

<Solution SolutionId="4AFC1350-F354-4439-B941-51377E845F2B" xmlns="http://schemas.microsoft.com/sharepoint/&quot; DeploymentServerType="WebFrontEnd" ResetWebServer="true">
<Assemblies>
<Assembly DeploymentTarget="GlobalAssemblyCache" Location="MyWebPart.dll">
<SafeControls> <SafeControl Assembly = "MyWebPart, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxxx" Namespace = "MyWebPart.WebParts" Safe = "TRUE" TypeName = "*"/>
</SafeControls>
</Assembly>
</Assemblies>
<DwpFiles>
<DwpFile Filename="mywp.webpart"/>
</DwpFiles>
</Solution>

Lets take a look at the Solution element. All of the attributes are optional although they have a huge impact on your solution. The SolutionId can be specified if you want to access the solution later on programmatically through the object model or if you want to specify the parent solution of a feature. ResetWebServer is the equivalent of an “iisreset” and in our case it is required. the DeploymentServerType can take two values WebFrontEnd or ApplicationServer. We can now specify any assemblies we want to include in our solution as you can see in line 3. Since I am in favour of adding assemblies to the GAC I chose that as a DeploymentTarget. Location here specifies the location of the assembly within the WSP (or CAB) file. As children of an assembly we can specify safecontrol entries which are crucial for our web part. The DwpFiles are exactly what they say they are, DWP files. You can specify any extension here but keep in mind that SharePoint understand .dwp and .webpart files only. Anything entered here will be deployed to the web application on the file system level and will be made available to all sites within the web application. This is not how the Visual Studio extensions for WSS do it. The template there creates a feature which deploys the .webpart files to each site’s web part catalog.

  Our WSP file now contains a manifest.xml, a mywp.webpart and mywebpart.dll. We now need to add the solution to our farm’s solution store. That can be achieved either through the object model or the stsadm utility. To keep it simple, lets do the stsadm utility method:

stsadm –o addsolution –filename x:mypart.wsp

If all went well and you received a confirmation message, you will now need to deploy your solution to one or more web applications. You can do this through the object model, stsadm utility or simply the SharePoint Administration site. In the SharePoint v3 Central Administration Site, click the Operations tab and select Solution Store. You should now see a list of solutions (if you added any!) and with a status specifying if the solution has been deployed. Clicking on a solution brings up a new page which a “Deploy Solution” button on a toolbar. Clicking that will allow you to deploy your solution to a specific web application or even better, all of them!. As soon as you deploy the solution, the web parts should be made available to one or more web applications and you can now see the web part when you click the "Add Web Part" button in a content page.

Advertisements