Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Using SharePoint Solutions to Deliver Server-Side Solutions : Page 2

Discover an elegant technique for creating and deploying solutions that provide reusable processes for installing and uninstalling custom code.


advertisement
Why Create Solution Files?
The Solutions format is very simple. It contains one mandatory file, manifest.xml, packed into a CAB file format and renamed with the WSP extension. Perhaps the most difficult part of the whole process is creating a Diamond Directive File (DDF) that you can use to create the CAB file with the MAKECAB.EXE utility—and it's a variant of the old INI file format that we know and love. The net is that the barrier to entry is fairly low, and you get a way to install, and retract, complete solutions from the entire web farm in a way that allows the state of the web farm to be kept in sync by SharePoint.

In the end, a solution file is easier to manage than any other mechanism for deploying files to SharePoint servers. Once added to the solution store, it can be managed through a central administration interface, or through the command line. Solutions can be deployed and retracted at will.

Before walking through the creation of a sample solution file, it's important that you understand the three major components of what you're delivering:

  • WFInspector feature – This feature uses the functionality to add pages to a web site. It also uses the functionality to add a link to these pages.
  • WFInspectorStaple feature – This feature staples the WFInspector feature to every web site. In other words, the WFInspectorStaple makes sure that every new web site that is created will have the WFInspector functionality.
  • WFInspector web part – This web part is the core of the solution. It provides a listing of the workflows running on the items in a given site.
With these components of the solution in mind, you can start building the manifest.xml file that the solution file needs.



Creating a Manifest File
The core file in the Solutions format is the Manifest.xml, an XML file that describes the contents of the WSP (solutions file). The root node of this XML file includes these attributes:

  • xmlns – This attribute is the namespace for the node that, like most SharePoint XML files, is http://schemas.microsoft.com/sharepoint/ for this node.
  • DeploymentServerType – An attribute with the values ApplicationServer and WebFrontEnd; solutions that need to be deployed only on front-end web servers use the WebFrontEnd option, and solutions that need to be deployed on any of the application servers, such as the indexing server, use the ApplicationServer option.
  • ResetWebServer – Set this attribute to TRUE typically, if you want the solution deployment framework to automatically reset the web server for you.
  • SolutionId – This attribute specifies the GUID identifier for the solution, in registry format minus the braces.
Once the <Solution> node is in place, it's time to move on and add the features to the manifest file. Add them by using the <FeatureManifests> and <FeatureManifest> set of tags. The <FeatureManifests> tag is simply a container for multiple <FeatureManifest> tags, each of which includes a single attribute, the Location attribute, which refers to the feature.xml of the feature to be deployed. In this case there are two nodes that refer to the two solutions to be deployed. The <FeatureManifests> node for the solution example discussed here looks like this:

<FeatureManifests> <FeatureManifest Location="WFInspector\feature.xml" /> <FeatureManifest Location="WFInspectorStaple\feature.xml" /> </FeatureManifests>

The SharePoint Solution framework will manage connecting the Element Manifests referred to in the feature.xml file for you. However, none of the ancillary files used by the feature, whether in the feature directory or not, will be copied by default; therefore, a different strategy for them is needed. Fortunately, the Solution framework provides two tags that can be used in manifest.xml to copy arbitrary files during deployment.

You can use a <RootFile> node in the <RootFiles> node to deploy files anywhere within C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12. For brevity, this directory will be referred to as …\12 hereafter in this discussion. You can use a <TemplateFile> node in the <TemplateFiles> node to deploy files within …\12. In this example you need to deploy a page, default.aspx, into the same directory as the Feature that deploys with a module element.

Because the file you need to deploy is under the TEMPLATE directory, use the <TemplateFile> node like this:

<TemplateFiles> <TemplateFile Location="FEATURES\WFInspector\default.aspx" /> </TemplateFiles>



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap