Build and Deploy the Solution File
All of the hard work is done. From here on out it's pretty simple. Building the solution file is simply a matter of running MAKECAB /F WPInspector.ddf
. The result is the solution file WFInspector.WSP
. To make sure that it was created correctly, rename it so that its extension is .CAB
and double-click it. Microsoft Windows Explorer will open the CAB file and display all of the files stored in it. Once you're comfortable that the file was created correctly rename it so that its extension is WSP to be able to deploy it to the SharePoint farm.
Deploying the solution file to SharePoint is a two-step process: First, register the solution in the database. Registration is accomplished from the STSADM command-line utility. To add the wfinspector.wsp file, run the utility like this:
STSADM o addsolution filename WFInspector.wsp
Second, once the solution has been added to the solution store you can deploy it from the command line, or you can deploy it using the Central Administration user interface. Find the Solutions Management page by going to Start-->Administrative Tools-->SharePoint 3.0 Central Administration-->Operations, and in the Global Configuration section clicking Solution management. From there, click one of the listed solutions to see its status and to take action on it—like deploying it.
Alternatively, you can deploy the solution from the command line with the STSADM command deploysolution. If you want to deploy the wfinspector.wsp solution to the local system, issue this command:
STSADM o deploysolution name wfinspector.wsp allcontenturls local allowgacdeployment allowcaspolicies
options are necessary only if you have indicated deploying an assembly to the GAC, or you have provided a CAS policy as a part of the solution file, respectively.
Extra Credit: Deploy a Site Definition
While it's much more common to deploy features and web parts, you may occasionally need to deploy site definitions. In this scenario you'll need to include <SiteDefinitionManifests> and <SiteDefinitionManifest> nodes in your manifest.xml file (directly under the root <Solution> node). The SiteDefinitionManifest element contains a single attributeLocationwhich in this case is the directory name for the site definition as it will appear under the …12\TEMPLATE\SiteTemplates directory.
Inside the <SiteDefinitionManifest> node is a <WebTempFil> node that also has only a Location attribute. This attribute refers to the relative path and name of the Webtemp*.xml file from the TEMPLATE directory. For instance, to deploy a site definition installed in the DEVX directory with a webtemp*.xml file named WEBTEMP_DEVX.xml, the XML fragment would be:
<WebTempFile Location="1033\XML\WEBTEMP_DEVX.XML" />
In the DDF file the site definitions files are in the directory that you referenced in the SiteDefinitionManifest
attributein this case, DEVX
and below. Thus, the ONET.XML
file would be in DEVX\XML
. The WebTemp
file is stored in a directory with a path matching the path used in the Location
attribute of the <WebTempFile> node.
The true beauty of solutions files is that in the end they are easy to make, and they create a repeatable process for installing and uninstalling custom code. For those in larger environments, where change control is critical, Solutions are a great way to ensure that the same files are deployed and the same configuration changes are made in each environment.