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


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

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


Creating the DDF File
Now that the manifest.xml file is complete, it's time to create the CAB file that is the solution package. To create the solution package, use the MAKECAB.EXE utility because the setup and deployment project in Visual Studio that makes CAB files can't make them with subdirectories. Solution file ubdirectories must match the locations referenced in manifest.xml. To get those subdirectories in the solution file, use a DDF that MAKECABknows how to read. In that file you'll specify the compression options, the files to compress, and what subdirectories in the CAB file to place them in.

The basic format of a DDF file is that of a text file. It contains one command per line. A line beginning with a single period is considered to be a command. Generally the first command is .OPTION EXPLICIT. For those of you familiar with Visual Basic, you'll recognize this sequence of words, which in this case means that if there's a problem processing the file MAKECABshould exit and report the error. The other commands that you'll use at the top of every DDF file that you're using to create a solution are:

  • .Set CabinetNameTemplate – Specifies the name of the output file—in this case, WFInspector.wsp
  • .Set DiskDirectoryTemplate=CDROM– Indicates that all of the CAB goes into a single directory
  • .Set CompressionType=MSZIP– Indicates that all of the files will be compressed into CAB files
  • .Set UniqueFiles="ON"– Indicates that all of the files referenced must be unique
  • .Set Cabinet=On– Use cabinet files
  • .Set DiskDirectory1=. – Use the current directory for the output CAB file

With that part out of the way you can just start listing files until you need to change the directory in the CAB file. Because the project to create the solution was created as an empty project underneath the same Visual Studio solution tree, most of the references will include a double dot (up one directory) notation and then back down into the correct folder. In every DDF for a solution file it's a good idea to start with manifest.xml since you know it's required. In this example there are three files that are saved in the root directory of the solution file: manifest.xml, WFInspectorWebParts.dll, and WFInspectorWebParts.webpart. These three lines look like this:


Next, set the new CAB directory to WFInspector with .Set DestinationDir=WFInspector line, which adds the two feature files (feature.xml and module.xml), which are deployed through the <FeatureManifest> element. Then set the directory to FEATURES\WFInspector and include the default.aspx file. Deploying all three of the files into the same directory may seem odd. Why do they end up in two different folders in the solution file? Sadly, they do because they're deployed differently; the relative paths referenced in Manifest.xmlare different, and they will land in the correct directory on the server.

The final step is to add the files for the WFInspectorStaplefeature. The whole DDF file looks like this:

.Set CabinetNameTemplate=WFInspector.wsp
.Set DiskDirectoryTemplate=CDROM
.Set CompressionType=MSZIP
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=.
.Set DestinationDir=WFInspector
.Set DestinationDir=FEATURES\WFInspector
.Set DestinationDir=WFInspectorStaple

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