Intoduction to SharePoint 2010 for Developers

This webinar is also available on the DevExpress Channel.

SharePoint 2010 Data Access

This webinar is also available on the DevExpress Channel.

Andrew was also kind enough to publish a wrap-up blog post with links to additional references.

Applies to: Microsoft Office SharePoint Server 2007, Microsoft Office InfoPath 2007, Microsoft Office Forms Server 2007

Introduction

InfoPath browser-enabled form template deployments are easy enough to do via the InfoPath client when the template does not require administrator approval. However even when administrator approval is not required, but the SharePoint governance plan requires script-able deployments of all InfoPath forms due to quality assurance and user acceptance testing requirements we need a mechanism to package our forms in a WSS solution package.

In this situation we are left with a few options, the easiest option is to deploy the form template using Central Administration in our development environment and then use Mark Wagner’s SharePoint Solution Exporter tool to extract the WSP file. This option is a bit limited however. The solutions generated by InfoPath Form Services after a form is uploaded using Central Administration contain a single form template and have some really unpleasant naming conventions (GUID are not pretty to look at).

Another option, and the topic of this tutorial, is to create a solution package from scratch. This option requires more work but provides more flexibility. We can include more than one form template (XSN file) per solution. We can comply with form, feature, and solution naming schemes. The following steps are required to create a solution package using this option:

1. Create and publish an InfoPath browser-enabled from template(s)
2. Create a solution manifest
3. Create a feature manifest
4. Create an element manifest
5. Create a data description file
6. Create and deploy the solution package (and activate the feature)

The following sub sections will discuss how to perform the steps above.

Create and Publish the InfoPath Browser-Enabled From Template

There are plenty of resources already available on how to create browser-enabled form templates and what the different types of browser-enabled form templates InfoPath Forms Services can use. So for the sake of simplicity, I will use only one form for this tutorial. The only thing that we need here is to make sure we have a published browser-enabled form template.

Follow the steps below to create a sample InfoPath Form Template:

1. Open Microsoft Office InfoPath 2007
2. Using the Getting Started modal dialog, click once on the Sample - Expense Report template under the Customize a Sample heading (center of the modal dialog window) and click the Design this form link under the Form tasks heading (right side of the modal dialog window)
3. Using the application menu, select File > Publish…
4. If the an information window appears telling you “the form template must be saved it can be published,” click the OK button and save the form template somewhere (name it something appropriate like Expense Report for example)
5. Select the To a network location radio button and click the Next button in the Publishing Wizard
6. Provide the Form template path and file name (I made a directory called c:\wspinfopath and saved the template there, remember the location that ou chose as we will use this location later in the tutorial) in the Publishing Wizard
7. Provide the Form template name (I used Expense Report) and click the Next button in the Publishing Wizard
8. Clear the text box (make it empty) and click the Next button in the Publishing Wizard
9. If prompted about the access path, click the OK button in the alert prompt
10. Verify the form name, publish path (remember this value), make sure the access path is empty, and the security level is not Restricted (InfoPath Forms Services does not support the Restricted security level)
11. Click the Publish button in the Publishing Wizard
12. Click the Close button in the Publishing Wizard
13. Close Microsoft Office InfoPath 2007

Visit the InfoPath Developer Portal for additional InfoPath development resources. You can also download my sample published InfoPath Form Template here.

Create the Solution Manifest

In order for Windows SharePoint Services 3.0 to know what to do with a solution package (WSP file) we need to add the required meta data in the form of a solution manifest. This file must be named manifest.xml in order for WSS to find it in the package. You can use any XML or text editor to create the file. I used Visual Studio, but it really doesn’t matter.

Follow the steps below to create a solution manifest:

1. Open your favorite XML or Text editor and create a file named manifest.xml
2. Save the file to the publish path location of the InfoPath form template (I hope you remembered your path, mine was c:\wspinfopath) and name it manifest.xml
3. Copy and paste the XML code sample below, save the file, and exit your XML or Text editor

<?xml version="1.0" encoding="utf-8" ?>
<Solution xmlns="http://schemas.microsoft.com/sharepoint/"
          SolutionId="39E1D478-A2BD-4B39-9842-49CA69369BFE"
          DeploymentServerType="WebFrontEnd">
  <FeatureManifests>
    <FeatureManifest Location="myInfoPathFormTemplate\feature.xml"/>
  </FeatureManifests>
</Solution>

When creating your own solution manifest, make sure you generate a new solution id. You can also download my sample solution manifest here.

Create the Feature Manifest

The steps for creating the feature manifest are identical to the steps we used to the the solution manifest with two exceptions. The exceptions are name the file something different (I use feature.xml for this tutorial) and the content that you save in it. So fire up your editor of choice and put the following XML code in the file.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="41CEE181-9440-4536-A1DA-73F41D2155B7"
         Title="My InfoPath Form Template Feature"
         Description="This feature contains the 1 InfoPath form template, but can contain more than one."
         Version="12.0.0.0"
         Scope="Site"
         DefaultResourceFile="ipfscore"
         ReceiverClass="Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver"
         ReceiverAssembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0,
                           Culture=neutral, PublicKeyToken=71e9bce111e9429c" >
  <ActivationDependencies>
    <ActivationDependency FeatureId="C88C4FF1-DBF5-4649-AD9F-C6C426EBCBF5"/>
  </ActivationDependencies>
  <ElementManifests>
    <ElementManifest Location="element.xml"/>
    <ElementFile Location="ExpenseReport.xsn"/>
  </ElementManifests>
  <Properties>
    <Property Key="FeatureName"
              Value="My InfoPath Form Template Feature"/>
  </Properties>
</Feature>

When creating your own feature manifest, make sure you:

• Generate a unique id for the Id attribute of the Feature root element
• Give your feature a meaningful title in the Title attribute of the Feature root element
• Give your feature a meaningful description in the Description attribute of the Feature root element

There are a ton of things going on in the feature manifest. I am not going to go into the details of what each node means and what other possible attributes you can use. That topic deserves a post (or many posts) of its own. Instead, let me just point out some key points:

• The ActivationDependencies node makes sure that InfoPath Forms Services (IPFS) is available and active before our feature is activated. IPFS is an enterprise feature and will require either an Enterprise or Internet CAL.
• I am not sure why we need the FeatureName in the key-value property pairs in the Propertynode. I am assuming that XsnFeatureReceiver class uses it, but I have not really played with those properties.
• The ReceiverClass and ReceiverAssemblyattributes are important so that IPFS takes the appropriate actions during the various feature events (such as the install, un-install, activate and deactivate events).
• If you have more than one XSN file that you want to deploy with this feature, then just add additional ElementFile nodes.
• The scope of the feature must be a site collection (yes the Site value is correct and intentional in the Scope attribute of the Featureroot element). Remember that when an InfoPath form is uploaded via Central Administration, it must then be activated to a site collection. I am not sure what would happen if a different scope is used as I have not tried it. You are welcome to give it a shot.

Like the solution manifest, you can also download my sample feature manifest here.

Create the Element Manifest

We are more than halfway done… I think. Just kidding we are almost there. The next file we need to create is the element manifest. Basically it is just like the feature manifest, but again the file name and the content of the file are a bit different. Fire up your editor… again. This file will be called element.xml.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="XSN" Url="FormServerTemplates" RootWebOnly="TRUE">
    <File Url="ExpenseReport.xsn"
          Name="ExpenseReport.xsn"
          Type="GhostableInLibrary"/>
  </Module>
</Elements>

You can do some interesting things with element manifests and we could spend a ton of time exploring this manifest. But we won’t because that is yet another topic that is deserving of its own post (or more). Just know that this file and its XML code are responsible for telling the WSS run-time to provision the form template to the Form Template Library in the root website of the site collection.

By the way, if you added more than one XSN file to the feature manifest because you have more than one form template to deploy with your solution, then you will want to add additional File elements for those files. There should be a one to one correlation between the form templates listed in the feature manifest and the element manifest.

I know you are expecting by now… so download my sample element manifest here if you like.

Create the Data Description File

When all is said and done, the solution package (WSP file) is just a cabinet file and is created using the MAKECAB utility. But in order for the utility to know how to create the file we have to pass it a data description file (DDF file) as an argument. The DDF file is just a plain text file with its own syntax that is pretty easy to follow. So for the last time (I promise) fire up your favorite text editor and put the following contents in it. (This file will be called wsp.ddf.)

; wsp.ddf (Alonso Robles)

.OPTION EXPLICIT     ; Generate errors
.Set CabinetNameTemplate=myInfoPathFormSolution.wsp    
.Set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP ;** All files are compressed in cabinet files
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=Package

; Add Solution Manifest
manifest.xml   manifest.xml

; Add Feature Manifests
feature.xml    myInfoPathFormTemplate\feature.xml

; Add Element Manifests
element.xml    myInfoPathFormTemplate\element.xml

; Add Element Files
ExpenseReport.xsn  myInfoPathFormTemplate\ExpenseReport.xsn

You may feel overwhelmed with the contents of the DDF file. It’s okay that’s normal. You may also be wondering why I used a feature folder hierarchy in the file when we created a folder for a feature at all throughout the tutorial. And you are probably guessing that I am not going to go into the details of the DDF file in this post. And you would be right if you think I am going to tell you that the DDF file is another topic deserving its own post. What you may not know, is that I have covered the DDF file in some detail in a previous post: Creating Solution Packages for WSS 3.0 and MOSS 2007 Deployments.

Oh yeah, almost forgot… you can download my sample data description file here.

Create and Deploy the Solution Package (and Activate the Feature)

This next part is accomplished using the command line. I am going to assume that you have the MAKECAB utility installed and that you have both MAKECAB and the STSADM utility accessible via the your environment variables. If you don’t you may need to update your environment variables to make the utilities accessible (or use absolute paths) when using them. Fire up a command line window and let’s get started. Below you will find the commands that I used to build and deploy the solution package (with a few modifications to generalize the commands) followed by a brief explanation:

cd c:\wspinfopath
makecab -F wsp.ddf
stsadm -o addsolution -filename myInfoPathFormSolution.wsp
stsadm -o execadmsvcjobs
stsadm -o deploysolution -name myInfoPathFormSolution.wsp -immediate
stsadm -o execadmsvcjobs
stsadm -o activatefeature -name myInfoPathFormTemplate -url http://mymoss

Quickly reviewing the commands above, we can see that we changed our working directory to the location of the publish path of the InfoPath form template (and the solution files). Then we generate the WSP file with the MAKECAP utility. Finally, using the STSADM utility we added the solution, deployed it, and activated the feature (for more information STSADM operations see my post on the 189 STSADM Operations). 

Conclusion

This post covered how to create a WSS solution package to deploy InfoPath browser-enabled form templates. While this method may not be required for all Microsoft Office SharePoint Server 2007 or Microsoft Office Forms Server 2007 implementation, it does offer some flexibility in order to allow us to comply with solution, feature, and form template naming conventions. In addition, it provides the ability to create script-able deployments that can be uniformly applied to multiple environments.

Additional Resources

• 189 STSADM Operations
• Creating Solution Packages for WSS 3.0 and MOSS 2007 Deployments
• How To: Create a SharePoint Solution for an InfoPath Form
• InfoPath Developer Portal
• SharePoint Server 2007 Developer Portal
• Windows SharePoint Services Developer Center