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 .CABand 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.wspfile, 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.wspsolution to the local system, issue this command:
STSADM –o deploysolution –name wfinspector.wsp –allcontenturls –local –allowgacdeployment –allowcaspolicies
The –allowgacdeployment and –allocaspoliciesoptions 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 attribute—Location—which in this case is the directory name for the site definition as it will appear under the …12\TEMPLATE\SiteTemplatesdirectory.
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's Location attribute—in 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 Locationattribute 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.