Reza Alirezaei’s Blog

The general requirement is a “round-trip” of the form you want to add or replace. Before adding or replacing forms in a WSP, they need to be published. Once the form is in a WSP, it can be imported into any Visual Studio project (i.e. a project that defines a custom List definition) and reused. When you publish the form, URLs in the XSF file can be relativized, and other content can be added/removed from XSN components as required by the publish process. We’re proposing the following, for example, when replacing a WSP form:

1. Open the WSP in Visual Studio
2. Locate the XSN in the WSP (there is a standard structure for both list and form library forms).
3. Download a copy of the XSN from SharePoint server using SPD, or make a copy of the XSN that is currently in the WSP.
4. Make the required modifications to the XSN in the InfoPath Designer application
5. Publish the form back to SharePoint
6. Download the XSN from SharePoint using SPD.
7. Replace the XSN in the WSP
8. Repackage/deploy the WSP

That’s the general “life-cycle” and practice. The process below is touching on deploying a SharePoint list form:

If you’ve already upsized a list, before importing the Site WSP into Visual Studio, the XSN will exist in the WSP and can be modified. There is also a process for adding a form to a list definition in a WSP which involves several manual steps. At a high level, the latter involves:

1. Add the XmlDocument to the Schema.xml (under List instances)
2. Under the Modules node, add a new Module (Item_):

• Name: Lists<name>Item_
• Modify the Elements.xml file.
• Remove the “Sample.txt” file added by VS.
• Add Folders under the created module and add the XSN template so that the path matches the one described in the Elements.xml file

3. Add the Item_pages Module:

• Name: Lists<name>Item_pages
• Get the List ID (On the SharePoint server, the link to Add a new list item contains the List ID, it can be copied from there.) <- this step might not be necessary, the deployment process  doesn’t match the list by ID but by name, any GUID would do as long as it’s unique.
• Ensure the sharePointListID attribute (under the sharepointListAdapterRW node) on the manifest.xsf file matches the GUID “id” value for the Elements.xml file created in this step.
• Add the property bag to the _pages node.
• Requires: vti_eTag: maps to the uniqueID for the folder “Lists\<name>\item”.  –> More specifically: PropertyBag refers to the properties of the “item” folder.

4. Add a property bag per item to the modules, one for each:

• Template.xsn
• Displayifs.aspx
• EditIfs.aspx
• NewIfs.aspx

On the “Features” node add the Modules created before (step 2 & 3: Lists<name>Item_   & Lists<name>Item_pages)

That’s it!