Upgrade InfoPath Forms without Loss of Data

How to manage updated versions of InfoPath form templates when used as Site Content Type.

The following article demonstrates how to ensure that an InfoPath form created from an older version of the form template continue to load from the template version which they were created from, while any new form submitted to the library will always use the latest version of the form template. This may be required when InfoPath forms are being integrated with SharePoint workflow, as the workflow will be set up to function using data from fields in the most recent version of the form template. If the main data source in the InfoPath form template is updated, the SharePoint Workflow may also need to be updated to cater for any field changes, or additional fields which are required by the workflow. Once the Workflow has been updated to work with the most recent form template version, any new forms submitted to the library will open from the new template, which will then start the updated version of the Workflow. Previous forms created from an older template versions will continue to load using the same template version in which the form was created. Any running Workflows will also continue use the workflow version which was current at the time the form was initially submitted.

Submitted forms can be "Relinked" to the current version of the template as long as they are stored in a SharePoint Form Library. If the forms are being submitted to a standard document library, the "Relink Documents" View and functionality will not be available. There are risks involved when relinking forms to the a more recent version, as modifications to the Form's Data Sources or code may result in the xml file created from an older not being able to open if data can't be mapped to fields in the main Data Source.

Be sure to test relinking an older form to the most recent version, by making sure that the form can open, that calculations, validation, rules and code are working as expected and that the form can be submitted successfully.

If you are certain that a form which is linked to an out-dated InfoPath Form template will function properly once "Re-Linked" to the current version, existing forms can be re-linked using the "Relink Documents" view of the SharePoint Form Library containing the submitted forms.

The process for creating, updating and managing incrementing InfoPath Form Template versions in a live environment, while ensuring that functionality in previous versions of the forms template remains is as follows:

1. Create a SharePoint Document library to store InfoPath form templates(Give it a name infopathcontenttypes).
This library will not be used to submit completed forms to. The sole purpose of this document library is to store template versions. This Document Library is not a Form Library and it is a normal Document Library.
- Set permissions on the document library to grant Read-Only access any user who requires access to the form.So the url of the document library will he http://servername/sitename/infopathcontenttypes

2. Create a SharePoint Form Library for completed forms to be submitted to(Give it a name empforms).
- See Submit InfoPath form to SharePoint List or Library using Content Type for details and instructions on how to set up InfoPath Forms to submit to a SharePoint Library by publishing the form as a site Content Type. This relates to steps 2, 3, 4 and 5. So the URL of Form Library will be http://servername/sitename/empforms

3. Configure the InfoPath Form Data Connection to submit to the Form Library created in Step 2.
See reference in Step 2 above for instructions.

4. Publish the Form Template as a Site Content Type.
This will be used as the default Content Type for the Form Library the submitted forms will be stored in. The form template will be published/saved to the Document Library created in Step 1 during the Publish process.
 Important thing to note is following
 1. Select New Content Type
 2. Give it a name emp content type version1
 3. In the template save location window type "http://servername/sitename/infopathcontenttypes/empversion1.xsn"

5. Set the Content Type created in Step 4 as the default Content Type for the Form Library that completed forms are submitted to (Created in Step 2). See reference in Step 2 above for instructions. You just need to change the content type of empforms library to "emp content type version1".Create some documents and submit them.

6. Changing the form template and publishing again You repeat the step 4 but this time instead of version1 you just replace it with version2  and then you set this new version2 content type as the default in empforms library. Make sure that you don't remove version1 content type.


Making Changes/Updates to the InfoPath Form Template once it is already in use.
Once you have all required components created and configured in the above steps, you will be able to make changes to Form Template without effecting previously submitted forms. This is possible as the Form's Content Type has been set as the default for the Form Library containing the forms.

When a user presses the "New" button on the Form Library, the a blank form will load from the most recent version of the form template. Once the form has been submitted, the template which it was created from is added to the forms XML so that it knows exactly which template to load when opening the form. If an update is then made to the Form Template, the submitted form will continue to load from the form template which it was created from unless "Relinked" to the current version.

The key is not to overwrite a previous Form Template with an updated version, but instead use a manual versioning system by adding the version number to the template filename when publishing the updated template. After the form is saved with a new filename, the Content Type is automatically updated to load new forms from the Updated version. As the previous versions of the template still exist in the form template document library, forms which were created from these versions will continue to open properly.

When making changes to an InfoPath Form template stored on a SharePoint site, you will be required to save a copy of the template somewhere else to be edited. An easy way to check if updates made to a form template will break previous forms if the current version is overwritten with the updated version, is by the message display by InfoPath when saving the form. If changes have been made to the Main Data source, a warning will be displayed when the form template is being overwritten if InfoPath detects that Updates make the different versions incompatible with each other. If this message is displayed, it is usually a good idea to save the Update form template with a new filename to ensure the older version is still accessible to forms which were created from it.


Related Articles:

SharePoint 2007 Deployment: List Template Features

List Templates

A list template is a reusable definition of a SharePoint list that is used to create lists. You can create list templates in one of two ways:

• Using a feature, just as described in this post.
• Using the SharePoint interface

To create a list template using the SharePoint interface, you only need to access the list's settings screen, and click on Save As Template. This will save the list template as a .stp file in the List Templates Gallery. This gallery stores only the custom list templates created through the SharePoint interface.

One additional note about list templates stored as .stp files is that they don't store a complete list definition (like the feature does) but rather a set of customizations performed on an existing list definition. This means that, although you can copy the file and deployed it to a different SharePoint farm, you must ensure that the original list definition that was customized to create the template also exists in the destination farm.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with list template elements can only be deployed to Site Collection or Web Site scopes.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>

<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="My List Template Feature"
         Description="Adds my My List Template."

         Scope="Web"
         Version="1.0.0.0">
    <ElementManifests>
        <ElementManifest Location="MyListTemplate.xml" />

        <ElementFile Location="MyListTemplate\schema.xml" />
    </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My List Template Feature.
• It will be deployed as a Web Site feature, since it's Scope value is Web.
• It references a single element manifest file: MyListTemplate.xml.
• It references an element file, schema.xml, which is the file that contains the list definition and must be located in a subfolder with the name of the list template (MyListTemplate in this case).

Element Manifest

The element manifest file can have any name you wish (in this example it's called MyListTemplate.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <ListTemplate> element which is used to deploy List Templates.

<?xml version="1.0" encoding="utf-8" ?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <ListTemplate
        FeatureId="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
        BaseType="0"
        Category="Custom Lists"

        Name="MyListTemplate"
        DisplayName="My List Template"
        Description="My Custom List Template."
        DisableAttachments="TRUE"

        DisallowContentTypes="TRUE"
        EnableModeration="FALSE"
        FolderCreation="FALSE"
        Hidden="FALSE"

        HiddenList="FALSE"
        OnQuickLaunch="TRUE"
        SecurityBits="11"        
        Sequence="500"

        Type="100"
        VersioningEnabled="FALSE">
    </ListTemplate>
</Elements>

This example creates a list template named MyListTemplate which is based on the Custom List template. Here is a short explanation of the attributes of the <ListTemplate> element:

• FeatureId - (optional) The GUID of the feature in which this list template is defined. This is an optional attribute but it's useful to include it since each list template is uniquely identified by is Type inside a specific Feature.
  
• BaseType - (required) Specifies the base type, or default schema, for lists created using this template. Like I mentioned in a previous post (WSS Tip #16: List Base Types) this attribute can have one of five possible values:
  • 0 (Generic List)
  • 1 (Document Library)
  • 3 (Discussion Forum)
  • 4 (Survey)
  • 5 (Issues List)
    
• Category - (optional) Specifies which category a list created from this template belongs to. It can assume one of the following values:
  • Libraries
  • Communications
  • Tracking
  • Custom Lists
    
• Name - (required) Specifies the internal name of the list definition. No spaces or special characters can be used. This name is also used to find the folder that contains the schema.xml file that has the list definition.
  
• DisplayName - (required) Specifies the name of the list template that will be shown to the user in the Create screen.
  
• Description - (optional) Specifies the description of the list template.
  
• DisableAttachments - (optional) Specifies if the list created with this template allows items to have attachments. Default value is FALSE (the items are allowed to have attachments).
  
• DisallowContentTypes - (optional) Specifies if the list created with this template can manage content types, allowing items of multiple content types in the same list. Default value is TRUE (content type management not allowed).
  
• EnableModeration - (optional) Specifies if the list created with this template will have content approval enabled, which means all items must be approved before they are published. Default value is FALSE (no content approval required).
  
• FolderCreation - (optional) Specifies if the list created with this template allows the user to create folders, showing the New Folder option in the New button. Default value depends on the type of list. For custom lists, the default value is FALSE (folder creation is not allowed) but for document libraries, the default value is TRUE (folder creation is allowed).
  
• Hidden - (optional) Specifies if the list template is hidden, which means it will not appear as an option on the Create page. Default value is FALSE (list template is not hidden).
  
• HiddenList - (optional) Specifies if the list created with this template will be hidden. Do not confuse with the previous option which refers to the list template and not the list created with it. Default value is FALSE (list will not be hidden).
  
• OnQuickLaunch - (optional) Specifies if the list created with this template will be displayed in the local navigation menu (quicklaunch). Default value is TRUE (list will be displayed on quicklaunch).
  
• SecurityBits - (required) Defines the item-level permissions for the list created with this template. This attribute is a 2-digit string where the first digit controls the read access, and the second digit controls the edit access. For read access, the digit can be:
  • 1: Users can read all items
  • 2: Users can read only their own items

For edit access, the digit can be:

• 1: Users can edit all items
• 2: Users can edit only their own items
• 4: Users cannot edit items

A notes about this attribute: a user with Manage Lists permission can always read and edit all items, regardless of the value of this attribute.

• Sequence - (optional) Specifies the order of the list template in the Create page. If this attribute is not set, the list template will be placed last in the list of templates (together with other templates that also haven't defined their sequence).
  
• Type - (optional) This attribute uniquely identifies this list template within the feature that contains it. SharePoint defines a set of list types which are used in the out-of-the-box list templates:
  • 100: Generic List
  • 101: Document Library
  • 102: Survey
  • 103: Links List
  • 104: Announcements List
  • 105: Contacts List
  • 106: Events List
  • 107: Tasks List
  • 108: Discussion Board
  • 109: Picture Library
  • 110: Data Source Gallery
  • 111: Site Template Gallery
  • 113: Web Part Gallery
  • 114: List Template Gallery
  • 115: XML Form Library
  • 120: Custom Grid for a List
  • 200: Meeting Series List
  • 201: Meeting Agenda List
  • 202: Meeting Attendees List
  • 204: Meeting Decisions List
  • 207: Meeting Objectives List
  • 210: Meeting Text Box
  • 211: Meeting Things to Bring List
  • 212: Meeting Workspace Pages List
  • 300: Portal Sites List
  • 1100: Issue Tracking
  • 2002: Personal Document Library
  • 2003: Private Document Library

This attribute might be important if you want to define event handlers that are attached to a specific type of list. I will talk about that scenario on one of the next posts in this series.

• VersioningEnabled - (optional) Specifies if the lists created with this template support versioning of their items. Default value is FALSE (item version is not enabled).

 Other Attributes

There are some less used attributes that one can use in the <ListTemplate> element, which are listed below:

• AllowDeletion - (optional) Specifies if the lists created with this template can be deleted. Default value is TRUE (lists can be deleted).
• AllowEveryoneViewItems (optional)
• AlwaysIncludeContent - (optional) Specifies if the contents are included by default, when lists created with this template are Saved as Templates. Default value is FALSE (content is not included, by default).
• CacheSchema (optional)
• Catalog - (optional) Specifies if the list definition is for a site gallery, list gallery or web part gallery. Default value is FALSE (list is not a gallery).
• Default - (optional) Specifies if new SharePoint sites will include this list. Default value is FALSE (lists are not included in new sites).
• DontSaveInTemplate - (optional) Specifies if a list created with this template should be included when the site that contains it is Saved as Template. Default value is FALSE (list is included in custom site template).
• EditPage - (optional) Specifies the path to a custom application page (/_layouts) to use when editing list properties for list created with this template.
• Image - (optional) Specifies the path to an image that represents the type of list defined by this template.
• NewPage - (optional) Specifies the path to a custom application page (/_layouts) to use when creating a new list based on this template.
• NoCrawl - (optional) Specifies if this list should be crawled and displayed in search results. Default value is FALSE (list is crawled).
• RootWebOnly - (optional, deprecated) Specifies that the lists created with this template can only exist in the root web site of a site collection. Default value is FALSE (lists can exist on any web site).
• SetupPath - (optional) Specifies the path to a folder in the Windows SharePoint Services setup directory (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE) that contains a file to include in the template.
• SyncType (optional)
• Unique - (optional) Specifies that this template can only be used to create lists during site creation, and not through the Create page or the SharePoint object model. Setting this attribute to TRUE has the effect of hiding the list template from the Create page and the list created with it from the web site lists. Default value is FALSE (lists can be created in the interface and through the object model).
• UseRootFolderForNavigation (optional)

List Definition File (schema.xml)

The list definition file (named schema.xml) is included in the feature using an ElementFile tag. Note that this file must be located in a subfolder with the same name as the list template being defined (in this example, MyListTemplate).

This file can be quite large and overwhelmingly complex, since it contains CAML and HTML embedded in the XML. The best strategy to built it is to copy an existing one and making only the necessary changes (which are only a few lines).

For this example, I will use the list definition file from the Custom List template which can be found in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\CustomList\CustList\schema.xml.

List Element

The first thing you must change is the attribute values in the List element. The original file has the following attributes for the main element:

<List xmlns:ows="Microsoft SharePoint" 
      Title="Basic List" 
      FolderCreation="FALSE" 
      Direction="$Resources:Direction;" 
      Url="Lists/Basic List" 
      BaseType="0">

For this example, I will change the above snippet to the one shown below:

<List xmlns:ows="Microsoft SharePoint"

      Title="My List"
      FolderCreation="FALSE"
      Direction="$Resources:Direction;"
      Url="Lists/MyList"

      BaseType="0">

Most of these attributes can be overridden when creating a list based on this template, but it's always a good practice to set the correct display name (Title attribute), default URL (Url attribute) and list base type (BaseType attribute). There are several optional attributes that you can specify to set additional configuration for the list template. For the sake of simplicity, I will not list them in this post.

The List element can have two child elements: Data and Metadata.

Data Element

The Data element is optional and is used to specify a set of rows that will be included in every list created with this template. Below is a sample snippet of this element.

<Data>

    <Rows>
        <Row>
            <Field Name="Title">My Item Title</Field>
            <Field Name="Body">Welcome to my custom list.</Field>

            <Field Name="Country">Portugal</Field>
        </Row>
    </Rows>

</Data>

In the above sample, I'm assuming that the list contains (at least) three fields (named Title, Body and Country, respectively) and I'm setting their values for a single row.

Metada Element

The Metadata element holds the definition of the list. It can have several child elements:

• Default - Contains the default form definitions used in lists created through the list definition.
• ContentTypes - Contains references to content types to associate with list created through the list definition.
• DefaultDescription - Sets the default description that appears in the title area of list views.
• DocumentLibraryTemplate - Specifies which file servers as the template document for items of a document library.
• Fields - Contains the field definitions for that belong to the list template.
• Forms - Contains the collection of forms used for lists create through the list definition.
• Toolbar - Contains the configuration for the toolbar used in the list views in list created through the list definition.
• Views - Contains the definition of the views used in a list created from this template.

Most lists will only need a subset of these, and I will show only three of them, which are the ones that must be changed in this example: ContentTypes, Fields and Views.

ContentTypes Element

The ContentTypes element specifies which content types will be associated with the lists created with this template. Each content type is referred through a ContentTypeRef child element as shown below.

<ContentTypes>

    <ContentTypeRef ID="0x0100C5647A362F236548B218C15302286758">
        <Folder TargetName="MyContentType" />
    </ContentTypeRef>

    <ContentTypeRef ID="0x0120" />
</ContentTypes>

The ContentTypeRef element has a required attribute ID, that specifies the ID of the referred content type. The Folder child element is optional, and is used to specify the relative folder path (inside the list's root folder) for the content type's resource folder. Most of the times, it's value is the name of the content type.

Fields Element

The Fields element is used to list the fields that should be included in the list. Two important notes about this element:

• You don't need to specify fields that were already defined in the base list.
• You must specify all other fields, even those that belong to a content type already associated with the template (via ContentTypes element).

<Fields>

    <Field 
        Type="Text"
        DisplayName="Body"
        ID="{b402db15-ee44-4ec4-89e3-23e10a8fc64c}"
        SourceId="0x0100C5647A362F236548B218C15302286758" 
        StaticName="Body"

        Name="Body" />
    <Field
        Type="Text"
        DisplayName="Country"

        Required="FALSE"
        MaxLength="255"
        Group="My Fields"
        ID="{f402db10-eb44-4ba4-20f3-73e13e8fe42c}"

        SourceId="0x0100C5647A362F236548B218C15302286758"
        StaticName="Country"
        Name="Country" />

</Fields>

In the above sample, I defined two fields (Body and Country). I didn't define the Title field because it is already defined in the base list. The attributes of the Field element are the same that were explained in the post SharePoint 2007 Deployment: Site Column Features.

Views Element

The Views element is used to specify the views that will be used in the lists created through this list template. It has a View child element for each view to be created, which is a rather complex element, with several possible attributes and child elements. Most of the times, you'll only need to edit the ViewFields and the Query child elements of the View element, as shown in the sample below.

<Views>

    <View BaseViewID="0" 
          Type="HTML" 
          WebPartZoneID="Main" 
          DisplayName="My View" 
          DefaultView="TRUE" 
          SetupPath="pages\viewpage.aspx" 
          ImageUrl="/_layouts/images/generic.png" 
          Url="AllItems.aspx">

        (...)
        <ViewFields>
            <FieldRef Name="Attachments" />
            <FieldRef Name="LinkTitle" />

            <FieldRef Name="Body" />
            <FieldRef Name="Country" />
        </ViewFields>

        <Query>
            <OrderBy>
                <FieldRef Name="Title">
                </FieldRef>
            </OrderBy>

        </Query>
    </View>
</Views>

In the above sample, the defined view is called My View and contains four fields: Attachments, LinkTitle, Body and Country, and the items are ordered using the Title field.

Upload Documents to a DocLib using features(Module)

Suppose You have created a DocumentLibrary named  "AddNewItems" and you want to upload few items to that document library.

Following is the content of the elementmanifest.xml file.


<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module List="101" Name="AddNewItems" Url="AddNewItems/sample">
    <File IgnoreIfAlreadyExists ="true" Path="a.txt"
           Type="GhostableInLibrary" Url="AddNewItems2/sample2/a1/a1.txt">
      <Property Name="Title" Value="abc"></Property>
      <Property Name="empname" Value="Hello"></Property>
    </File>
  </Module>
</Elements>

Things to note:
Url attribute in the Module element should start with the listname into which you want to upload the documents. You can also put more values in that element (like "listname/sample") if you want to create folders inside document library.

Column Values: If you want to set column values you should use Properties element like shown above. I wanted to populate "empname" property with value "Hello".

Type should always have "GhostableInLibrary" for items in Document Library.

Url in File element is a virtual path for the file. It will create folders if they don't exist.

SharePoint 2007 Deployment: Creating and Using Features

Summary

This third post is about creating and using Features in a general sense. Creating Features for each specific element will be the subject of later posts. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.

Feature Scopes

A Feature can be activated or deactivated in a specific scope, and there are four different scopes:

• Farm – The elements will be deployed at the farm level. To activate or deactivate a farm-scoped Feature, go to Central Administration, Operations section, and click on Manage Farm Features in the Global Configuration group.
• Web Application – The elements will be deployed at the web application level. To activate or deactivate a web application-scoped Feature, go to Central Administration, Application Management section, and click on Manage Web Application Features in the SharePoint Web Application Management group.
• Site Collection – The elements will be deployed at the site collection level. To activate or deactivate a site collection-scoped Feature, go to the root web site settings, and click on Site Collection Features in the Site Collection Administration group. You must be a site collection administrator to see this setting.
• Web Site – The elements will be deployed at the web site level. To activate or deactivate a web site-scoped Feature, go to the web site settings, and click on Site Features in the Site Administration group. You must have ManageWeb permissions (for instance, being a site administrator) to see this setting.

Each type of element can be deployed to one or more of these scopes. When describing each element type, I will specify to which scopes they can be deployed to.

Feature Schema

To create a Feature you must create a XML file named feature.xml which contains all the general configurations for the Feature and the references to all the files that describe the Elements contained in the Feature. Below is an example of a feature.xml file that uses all possible attributes, just for demonstration purposes. Required attributes are printed in bold.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
    Id="AB30188E-6F5D-4380-89D9-46F5D43E25F7"
    Scope="Site"
    Title="My Feature"
    Description="My Feature includes several elements."
    Version="1.0.0.0"
    Creator="André Vala"
    SolutionId="2530188E-6F5A-433B-89D9-BA98D43E25F7"
    ImageUrl="/_layouts/MyFeature/MyFeatureIcon.jpg"
    ImageUrlAltText="My Feature Icon"
    Hidden="FALSE"
    ActivateOnDefault="FALSE"
    AlwaysForceInstall="FALSE"
    AutoActivateInCentralAdmin="FALSE"
    RequireResources="TRUE"
    DefaultResourceFile="MyResourceFile"
    ReceiverAssembly="MyFeatureReceiver, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=3f5df55c01ba1c99"
    ReceiverClass="MyFeatureReceiver.MyReceiverClass">
    <ActivationDependencies>
        <ActivationDependency FeatureId="C03829C4-0E85-4DCE-90F8-B7E3F008A0C5"/>
    </ActivationDependencies>
    <ElementManifests>
        <ElementManifest Location="MyElement1.xml"/>
        <ElementManifest Location="MyElement2.xml"/>
        <ElementManifest Location="MyElement3.xml"/>
        <ElementFile Location="MyFile1.jpg"/>
        <ElementFile Location="MyFile2.jpg"/>
    </ElementManifests>
    <Properties>
        <Property Key="MyProperty" Value="MyValue" />
    </Properties>
</Feature>

Tip: To make things easier when creating these files in Visual Studio 2005 (or later), you can use the wss.xsd schema file, included with SharePoint (usually in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML), to enable Intellisense.

Feature Element

The <Feature> element is the root element of the feature.xml file and it has several possible attributes, although not all of them are required:

• Id (required): Unique identifier for this feature (GUID).
• Scope (required): Scope in which the Feature will be activated/deactivated. Can assume the values Farm, WebApplication, Site and Web (as described in the first section of this post). Keep in mind that the elements you want to include in the feature might dictate what will be its scope.
• Title (optional): Title of the Feature as shown in the Feature list.
• Description (optional): Description of the Feature as shown in the Feature list, below the Feature title.
• Version (optional): Version number of the Feature.
• Creator (optional): Name of the author of the Feature.
• SolutionId (optional): ID of the Solution that the Feature belongs to.
• ImageUrl (optional): URL of the image that will be used as icon in the Feature list. If this attribute is not present, SharePoint will use the default Feature icon.
• ImageUrlAltText (optional): Alternative text used in the Feature icon.
• Hidden (optional): Specifies if the Feature should be hidden from the Features list. The default value is FALSE.
• ActivateOnDefault (optional): Specifies if the Feature should be automatically activated after it is installed. This attribute is only used if the Feature scope is Farm or WebApplication, otherwise it is ignored. The default value is TRUE.
• AlwaysForceInstall (optional): Specifies if the Feature should always be installed, even if it's already installed. The default value is FALSE.
• AutoActivateInCentralAdmin (optional): Specifies if the Feature should automatically be activated in its scope. This attribute has no meaning for Features of scope Farm. The default value is FALSE.
• RequireResources (optional): Specifies if SharePoint should look for a culture-specific resource file for this Feature. If there is no resource file for the current culture, the Feature is hidden in the Features list (but can still be activated by object model or console command). The default value is FALSE.
• DefaultResourceFile (optional): Defines the name of the resources files. By the default all resource files are named Resources.XX-xx.resx (where XX-xx is the culture code), but setting this attribute with the value MyResourceFile will cause SharePoint to look for filenames like MyResourceFile.XX-xx.resx
• ReceiverAssembly (optional): Full qualified name of the assembly that contains the Custom Feature Event Receiver class. This attribute is always used with the ReceiverClass attribute.
• ReceiverClass (optional): Name of the class that implements the Custom Feature Event Receiver. This attribute is always used with the ReceiverAssembly attribute.

Activation Dependencies

The <ActivationDependencies> element is optional and is used when you want to create a dependency between two Features. In other words, if a certain Feature A depends on some Element from a Feature B, creating an activation dependency in Feature A ensures that it won't be activated if Feature B is not activated first. This element can contain any number of <ActivationDependency> elements whose only attribute (FeatureId) is the ID of the Feature upon which this Feature is dependent.

Element Manifests

The <ElementManifests> element is also optional although it is used very often since it contains the list of Elements that belong to the Feature. This element can contain two types of child elements:

• The <ElementManifest> element, which points to a XML file that describes one or more SharePoint Feature Elements.
• The <ElementFile> element, which points to a generic file that is part of the Feature but is not an Element Manifest. An example of such a file can be a master page or a .webpart file.

Both elements have a Location attribute that must contain the path to the referenced file. Most of the next posts in this series describe each type of Element Manifest.

Properties Element

The <Properties> element is optional and it defines a property bag that can be accessed in Custom Feature Event Receivers. This element contains <Property> elements which have two attributes:

• Key: Name of the property key, in the property bag.
• Value: Value of the property, in the property bag.

This property bag can be very useful to send parameters to a Custom Feature Event Receiver whose behavior can be parameterized.

Feature Installation and Uninstallation

Although the best way to install a Feature is through a Solution, you can do it manually. Just keep in mind that you must do it in all the servers of the farm (whereas with the Solution, the multi-server deployment is automatically assured).

To install a Feature you have to create a folder in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES with the name of the Feature and copy the feature.xml and any other files (like Element Manifests) to that folder. Then you have to execute the following console command:

    stsadm -o installfeature -name MyFolderName

Where MyFolderName is the name you gave the folder that contains the Feature.

To uninstall the Feature you have to execute the opposite console command (see below) and remove the folder you created.

    stsadm -o uninstallfeature -name MyFolderName

Feature Activation and Deactivation

Similarly, besides activating and deactivating the Feature using the SharePoint UI, you can do it using console commands. To activate a Feature you have to execute the following command:

stsadm -o activatefeature -name MyFolderName -url http://MyServer/MyWebSite

Where MyFolderName is the name of the folder that contains the Feature, and http://MyServer/MyWebSite is the URL address of the web site where you want to activate the Feature.

To deactivate it, you call the opposite command, as shown below:

stsadm -o deactivatefeature -name MyFolderName -url http://MyServer/MyWebSite

SharePoint 2007 Deployment: Module Features

SharePoint 2007 Deployment: Module Features

Summary

This post is about developing features to deploy files in a SharePoint site (module features). Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the provisioning of files (modules) in a SharePoint site.

You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Modules

Modules are collections of files that must be provisioned in a SharePoint web site. This type of feature element can be used to:

• Add pages to a web site
• Add web parts to a web site's web part gallery
• Add web parts to a web part page
• Add documents to a document library
• Add style sheets to the a web sites style library

According to the documentation, WSS 3.0 supports provisioning a maximum of 1000 files through module feature elements (whether using a single module element with 1000 files, or 1000 module elements each with a single file).

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with module elements can be deployed to Site Collection and Web Site scopes, since they represent files that are to be placed in web sites.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
  xmlns="http://schemas.microsoft.com/sharepoint/"
  Title="My Module Feature"
  Id="17E94729-EF3E-4f43-9385-88E1201F91E0"
  Description="This feature adds files to the web site."
  Version="1.0.0.0"
  Scope="Web"
  Hidden="FALSE"
  DefaultResourceFile="core">
    <ElementManifests>
        <ElementManifest Location="Modules.xml" />
        <ElementFile Location="default.aspx" />
        <ElementFile Location="MyMasterPage.master" />
        <ElementFile Location="MyDocument.docx" />
        <ElementFile Location="MyWebPart\MyWebPart.webpart" />
        <ElementFile Location="MyStyles.css" />
    </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My Module Feature.
• It will be deployed as a Web Site feature, since it's Scope value is Web.
• It references a single element manifest file: Modules.xml.
• It references several element file files. You must reference separately, using these elements, each file you wish to include in the module.

Element Manifest

The element manifest file can have any name you wish (in this example it's called Module.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <Module> element which is used to deploy Files to SharePoint web sites.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    
    <!-- Page Module -->
    <Module Name="Pages" Url="" Path="">
        <File Url="default.aspx" 
              NavBarHome="True" 
              IgnoreIfAlreadyExists="TRUE" 
              Type="Ghostable">
 
            <!-- Places Web Part on Page -->
            <AllUsersWebPart WebPartZoneID="Left" WebPartOrder="1">
                <![CDATA[
                  <webParts>
                    <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
                      <metaData>
                        <type name="MyWebPart, 
                                    MyWebPart.MyWebPart, 
                                    Version=1.0.0.0, 
                                    Culture=neutral, 
                                    PublicKeyToken=1255988569cf0248" />
                        <importErrorMessage>
                            Cannot import My Web Part.
                        </importErrorMessage>
                      </metaData>
                      <data>
                        <properties>
                          <property name="Title" type="string">
                            My Web Part
                          </property>
                        </properties>
                      </data>
                    </webPart>
                  </webParts>
                ]]>
            </AllUsersWebPart>
            
            <!-- Places a List View for a Discussion Board -->
            <View List="Lists/Discussions" 
                  BaseViewID="4" 
                  Name="Discussions" 
                  WebPartZoneID="Left" 
                  WebPartOrder="2"/>
 
            <!-- Places a List View for a Document Library -->
            <View List="MyDocuments" 
                  BaseViewID="10" 
                  Name="My Documents" 
                  WebPartZoneID="Left" 
                  WebPartOrder="3"/>
 
            <!-- Customizes Navigation -->
            <NavBarPage Name="$Resources:core,nav_Home;" 
                        ID="1002" 
                        Position="Start" />
        </File>
    </Module>
    
    <!-- Master Page Module -->
    <Module Name="Master Pages" List="116" Url="_catalogs/masterpage">
        <File Url="MyMasterPage.master" Type="GhostableInLibrary" />
    </Module>
 
    <!-- Document Module -->
    <Module Name="Documents" List="101" Url="MyDocuments">
        <File Url="MyDocument.docx" Type="GhostableInLibrary" />
    </Module>
 
    <!-- Web Part Module -->
    <Module Name="WebParts" List="113" Url="_catalogs/wp">
        <File Path="MyWebPart\MyWebPart.webpart"
              Url="MyWebPart.webpart"
              Type="GhostableInLibrary" />
    </Module>
 
    <!-- Style Sheet Module -->
    <Module Name="Stylesheets" List="101" Url="Style Library">
        <File Url="MyStyles.css" Type="GhostableInLibrary" />
    </Module>
</Elements>

The example above provisions five different files in a SharePoint web site:

• An ASPX web page (web part page) to the root of the web site. This web page contains:
  
  • A MyWebPart Web Part (on web part zone Left)
  • A List View Web Part that shows a view of a discussion board list
  • A List View Web Part that shows a view of a document library
• A Master Page to the Master Page Gallery of the web site
• A document to a Document Library of the web site
• A web part to the Web Part Gallery of the web site
• A style sheet to the Style Library of the web site

The Module Element

The <Module> element is used to specify a Module. There can be any number of modules in a single element manifest. Here is a summary of the possible attributes of this element:

• IncludeFolders - (optional) I could figure out what this attribute is for...
• List - (optional) Type of list where the files included in this module should be provisioned (check the possible values on my post about List Template Features).
• Name - (required) Name of the module (file set).
• Path - (optional) Specifies the physical path of the files, inside the feature folder (C:\Program Files\...\12\TEMPLATE\FEATURES\[feature]). By default, SharePoint assumes the files are in the same folder as the element manifest file. You can also specify the path on each <File> element (see below).
• RootWebOnly - (optional) Boolean value. If TRUE it specifies that the files in this module will only be provisioned on the root web site of a site collection.
• SetupPath - (optional) Specifies the physical path to a folder, inside SharePoint's setup folder (C:\Program Files\...\12\TEMPLATE), that contains the files included in the module.
• Url - (optional) Specifies the virtual path of the folder in which to place the files of the module. This attribute is also used to provision a folder inside a list. If the Path is not specified, the value of this attribute will be used for the physical path also.

The File Element

The <File> element is used to specify a file inside a module. There can be any number of <File> elements inside a <Module> element. See below a list of the possible attributes of this element:

• IgnoreIfAlreadyExists - (optional) Boolean value. If TRUE it specifies that the file should be provisioned even if it already exists on the destination URL.
• Name - (optional) Specifies the virtual path for the file.
• NavBarHome - (optional) Boolean value. If TRUE it specifies that the file will be the destination of the Home link, used in the web site's navigation. This attribute is only used for web pages.
• Path - (optional) Physical path to the file, inside the feature folder (C:\Program Files\...\12\TEMPLATE\FEATURES\[feature]). This attribute is used if you need to specify a different path for each file inside the module. Otherwise, you can use the Path attribute on the Module element.
• Type - (optional) Specifies if the file is to be stored in a Document Library (in this case the value should be GhostableInLibrary) or outside of a list (in this case the value should be Ghostable).
• Url - (required) Specifies the virtual path for the file. If Name is specified, then the value of this attribute is ignored. However, if Path is not specified, the value of this attribute will be used for the physical path.

The AllUsersWebPart Element

The <AllUsersWebPart> element is used when you want to add a generic web part (non-List View web part) to a web part page. It can only be used inside a <File> element that provisions a web part page file. It has only two attributes:

• WebPartOrder - (required) Specifies the vertical position of the web part inside a web part zone.
• WebPartZoneID - (required) Specifies the name of the web part zone.

Inside this element, you can place a CDATA element with the web part's XML description, either using the DWP file schema (also called V2) or the WEBPART file schema (also called V3).

The View Element

The <View> element is used when you want to add a List View Web Part to a web part page. It can only be used inside a <File> element that provisions a web part page file. It has a lot of possible attributes, but I will only list the most common:

• List - (optional) Specifies either the template type of the list (an integer value) or the URL of a list provisioned in the web site (a string value). On most cases, you should use the URL, since there might be two lists of the same type on the web site.
• BaseViewID - (optional) Specifies the ID of the list view to be used.
• Name - (optional) Specifies the name of the view.
• WebPartOrder - (required) Specifies the vertical position of the web part inside a web part zone.
• WebPartZoneID - (required) Specifies the name of the web part zone.

The NavBarPage Element

The <NavBarPage> element is used to define how the navigation items should be created so that other pages link to this one. It can only be used inside a <File> element that provisions a web page file. It has three attributes:

• ID - (required) Specifies the ID for the page. This ID will be used by other pages when defining the relative position of the navigation items.
• Name - (required) Specifies the text that is displayed in the navigation area of other pages that link to this one.
• Position - (optional) Specifies the position of the navigation item on the navigation area of other pages that link to this one. This attribute can have the following possible values:
  
  
  • Start - Add the node to the start of the top navigation area.
  • End - Add the node to the end of the top navigation area.
  • Number between 1001 and 2000 - Add the node after another NavBarPage element whose ID matches the number.

The Property Element

The <Property> element is used only inside the <File> element, to define the value of one or more properties of that file, once it is provisioned. It's mostly used to set properties of web part files or document files. It has only two attributes:

• Name - (required) Name of the property to be set.
• Value - (required) Value to set the property with.

Additional Notes

The files included in a module feature element are provisioned in the web site where the feature is activated. However, when the feature is deactivated, the files that belong to the module element are not removed.

You can learn a lot about modules by looking inside the onet.xml files included in each site template (look in C:\Program Files\...\12\TEMPLATE\SiteTemplates). These files include a <Modules> element which shares the same schema as the Module Features.

Powershell commands

http://www.computerperformance.co.uk/powershell/powershell_syntax.htm#Operators_

http://mybsinfo.blogspot.com/2007/01/powershell-adventure-chpt2-using-net-in.html

http://www.powershellpro.com/powershell-tutorial-introduction/tutorial-powershell-aliases/

Anatomy of UDC

The anatomy of a UDC file

OK, we’ve talked about super-fantastic high end authentication scenarios. We’ve talked about cross-domain security and administrative control. We’ve talked about generating UDC files using InfoPath and consuming them again in the designer. Now let’s drill into the structure of the file itself.

UDC V2 is an XML format, and like any good XML format, there is a schema and a namespace associated with it. I’ll give you the full schema at the end of this post.

A handy tip: copy the schema into notepad and save it with an xsd extension, then follow the steps outlined in Aaron Stebner’s blog here: http://blogs.msdn.com/astebner/archive/2005/12/07/501466.aspx to add the xsd file to Visual Studio’s intellisense cache. Once that’s in place, Visual Studio will help you generate your UDC files!

Basic Structure of the File

Every UDC file you create will have the structure below, so copy it to notepad and use it as the basis for all your files. This is the infrastructure – the metadata that describes the connection and allows external components such as SharePoint and InfoPath to understand what’s inside.

<?MicrosoftWindowsSharePointServices ContentTypeID=”0x010100B4CBD48E029A4ad8B62CB0E41868F2B0”?>
<udc:DataSource MajorVersion="2" MinorVersion="0" xmlns:udc="http://schemas.microsoft.com/office/infopath/2006/udc">
  <udc:Name/>
  <udc:Description/>
  <udc:Type MajorVersion="2" MinorVersion="0" Type=""/>
  <udc:ConnectionInfo Purpose="" AltDataSource=””/>
</udc:DataSource>

The file begins with a processing instruction specifying a Content Type Id. This is necessary to associate the file with the UDC content type on a Microsoft Office SharePoint 2007 server. Having the content type identified allows the Name, Title, Description, Type, and Purpose fields to be promoted into columns in the data connection library so that the InfoPath designer can see the file.

By the way: there’s a known issue on Windows Vista where the title property doesn’t get promoted when using the Convert function in the InfoPath designer. To work around this issue, save the file to your local disk, and then re-upload the file to the library using the SharePoint library upload function.

The root node is called DataSource, and it specifies the UDC version of 2.0, as well as the udc V2 namespace. The Name and Description fields are promoted into SharePoint columns, and they show up in the InfoPath designer when browsing to the file in the data connection wizard. So, while these fields are not strictly required, you should use them to provide useful information about what the data connection is about, and maybe even contact information for the owner of the data source.

Type (specifically, the Type attribute on the Type element) and Purpose are both required, and very easy to fill once you know the possible values:

DataSource/Type/@Type:

Value	Use for
SharePointList	SharePoint list query connection
SharePointLibrary	SharePoint Library submit connection
Database	Database query connection
XmlQuery	Xml file query connection
XmlSubmit	HTTP Post submit connection
WebService	Web service submit or query connection

DataSource/ConnectionInfo/@Purpose:

Value	Use for
ReadOnly	All query connections
WriteOnly	All submit connections
ReadWrite	Web service only, when both query and submit methods are specified and they reference the same WSDL

The AltDataSource attribute specifies a second UDC file in the same library. When specified, InfoPath will use the original file, and Forms Services will use the file specified in the attribute. The attribute's value should be the filename of the alternate UDC file. Naturally, the two files should specify equivalent connections - specifically, the connections have to have the same Type and Purpose, and they have to return the same data, or data in the same format.

The ConnectionInfo Element

The meat of the connection information is here, and each type of data connection requires specific elements. So, the contents of this element will change depending on the Type and Purpose attributes.

Let’s run ‘em down, shall we? I’m confident that you can learn by example, so I’m not going to do a lot of explaining here. As I noted in a previous post, we’re working on a schema reference that will fill in the details.

1. Web Service
This example is for a query connection. For a submit connection, the Purpose would be WriteOnly, and the ServiceUrl and SoapAction would be contained within an UpdateCommand element rather than SelectCommand.

Web service is the only connection type that can have both a SelectCommand and an UpdateCommand in the same file. The two operations need to share the same WSDL, and the Purpose in that case is ReadWrite.

<udc:ConnectionInfo Purpose=”ReadOnly”>
   <udc:WsdlUrl>
   http://www.someserver.com/service/service1.asmx?wsdl
 </udc:WsdlUrl>
 <udc:SelectCommand>
  <udc:ServiceUrl>
   http://www.someservice.com/service/service1.asmx
  </udc:ServiceUrl>
  <udc:SoapAction>
   http://www.someservice.com/service/SomeOperation
  </udc:SoapAction>
 </udc:SelectCommand>
</udc:ConnectionInfo>

2. Database
A database connection is always marked as ReadOnly. InfoPath determines at design time whether submit can be enabled for the connection.

<udc:ConnectionInfo Purpose=”ReadOnly”>
 <udc:SelectCommand>
  <udc:ConnectionString>
Provider=Microsoft.ACE.OLEDB.12.0;User ID=Admin;Data Source=C:\temp\Database1.accdb;Mode=Share Deny None;Jet OLEDB:System database=&quot;&quot;;Jet OLEDB:Registry Path=&quot;&quot;;Jet OLEDB:Database Password=&quot;&quot;;Jet OLEDB:Engine Type=6;Jet OLEDB:Database Locking Mode=1;Jet OLEDB:Global Partial Bulk Ops=2;Jet OLEDB:Global Bulk Transactions=1;Jet OLEDB:New Database Password=&quot;&quot;;Jet OLEDB:Create System Database=False;Jet OLEDB:Encrypt Database=False;Jet OLEDB:Don't Copy Locale on Compact=False;Jet OLEDB:Compact Without Replica Repair=False;Jet OLEDB:SFP=False;Jet OLEDB:Support Complex Data=False;
  </udc:ConnectionString>
  <udc:Query>SELECT * FROM Table1</udc:Query>
 </udc:SelectCommand>
</udc:ConnectionInfo>

3. SharePoint list query
<udc:ConnectionInfo Purpose=”ReadOnly”>
 <udc:SelectCommand>
  <udc:ListId>{8fe80d4c-2203-4fa3-a411-f57f2e8be459}</udc:ListId>
  <udc:WebUrl>http://someserver/sites/somesite</udc:WebUrl>
 </udc:SelectCommand>
</udc:ConnectionInfo>

4. SharePoint library submit
The FolderName element specifies the default folder name that is used to prepopulate the data connection wizard.  Form designers will still need to specify the file name, as it is stored in the form template.

<udc:ConnectionInfo Purpose=”WriteOnly”>
 <udc:UpdateCommand>
  <udc:FileName>ExpenseReport.xml<udc:FileName>
  <udc:FolderName AllowOverwrite=”true”>
   http://someserver/sites/somesite/somelibrary
  </udc:FolderName>
 </udc:UpdateCommand>
</udc:ConnectionInfo>

5. XML file query
<udc:ConnectionInfo Purpose=”ReadOnly”>
 <udc:SelectCommand>
  <udc:Query>http://someserver/somefile.aspx</udc:Query>
 </udc:SelectCommand>
</udc:ConnectionInfo>

6. HTTP Post
<udc:ConnectionInfo Purpose=”WriteOnly”>
 <udc:UpdateCommand>
  <udc:Submit>http://someserver/somefile.aspx</udc:Submit>
 </udc:UpdateCommand>
</udc:ConnectionInfo>

Authentication

I’ve described the contents of the Authentication element in previous blog posts, so I won’t go into a detailed explanation. Two things are important here:
1. The Authentication element must be the last child of ConnectionInfo
2. If both SSO and UseExplicit are specified, Forms Services will use the credentials specified in the SSO element and will ignore the UseExplicit element.
This section is used only for forms running in the browser – InfoPath always ignores the authentication element.

<udc:Authentication>
 <udc:UseExplicit CredentialType="">
  <udc:UserId/>
  <udc:Password/>
 </udc:UseExplicit>
 <udc:SSO AppId="" CredentialType=""/>
</udc:Authentication>

The Universal Data Connection 2.0 schema

Download the XSD from here.