Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


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.




Application Security Testing: An Integral Part of DevOps

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.EXEutility—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 &#150 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 &#150 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 WFInspectorfunctionality.
  • WFInspector web part &#150 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.xmlfile 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 ApplicationServeroption.
  • ResetWebServer – Set this attribute to TRUEtypically, 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.xmlof 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:

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

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.xmlto 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 TEMPLATEdirectory, use the <TemplateFile> node like this:

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

Comment and Contribute






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



Thanks for your registration, follow us on our social networks to keep up-to-date