Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Introduction
SharePoint 2010 provides a slew of great new features, including the ability to directly edit the default newform.aspx and editform.aspx forms for list items. Those are the forms that SharePoint provides for “free” when you create a list or library in SharePoint. SharePoint assembles a very simple data entry form that enables you and your end user community to quickly create, edit and delete items. These free forms are quite useful, but they are very rigid. You have very limited capability to customize them. Microsoft changed this story with SharePoint 2010 and InfoPath.
You can now edit those default forms by clicking a single button from the page as show in figure 1 and 2:
Figure 1: SharePoint Ribbon
Figure 2: InfoPath Integration via the Ribbon
This functionality is a great improvement with SharePoint 2010. However, it also introduced a new challenge – how to integrate this new data entry capability into a proper software development life cycle process.
Customized InfoPath Forms and the SharePoint Life Cycle
In the old MOSS days or even in the new SharePoint 2010 days, if you leave your create, update and delete functionality in the hands of SharePoint’s default operation, you don’t have to worry much about multiple environments (development, testing and production). However, things change when you customize a form using InfoPath. This is because InfoPath operates a bit differently.
The out of the box SharePoint process is definition and data driven. You specify columns, display order, type and whether they should display at all. SharePoint uses that definitional information to produce the default display. Using InfoPath, on the other hand, creates a list-specific customization whose specific customizations are recorded in an InfoPath template file. This file has a .XSN extension and is stored in a hidden folder in the list or library itself (see Figure 3 for an example). The template includes every important fact about the list, including formatting, validation rules and most importantly (from the point of view of this article), the actual list to which the template is connected. The InfoPath template “knows” its list and this is stored as a link directly in the template itself.
Figure 3: InfoPath Template In the List
You must take this fact into account when thinking about how you deploy your form from one environment to the next.
Migration Options
When you customize a list in SharePoint, you have several options to migrate it from development to test to production. Setting Visual Studio aside (which is the best option but also the most technically complex approach), you can:
1. Save the list as a template, download the template and import it into the new site.
2. Export and then import the site using the new SharePoint 2010 PowerShell commands (best) or stsadm (old and deprecated).
3. Backup and restore the entire site collection.
SharePoint handles the first two cases correctly (at least in all of the tests the author could think to try). However, it does not handle the full site collection backup and restore properly. Specifically, SharePoint fails to correct the embedded links to the list during the site collection restore. Consider this scenario to illustrate the point:
- You have a development site collection named: http://devserver/sites/DevelopmentSite
- You have a production site collection named http://devserver/sites/ProductionSite
- You use PowerShell to back up the development site collection and then use PowerShell to import the site collection into production.
In this case, you’ll find that the InfoPath form in production is actually linked back to development. End users will have the bizarre experience of opening up the form in production and end up editing data in development!
This is a bit of a nasty problem because InfoPath doesn’t give you an option to change the target environment for lists customized this way. Consider figure 4:
Figure 4: Trying to Change Publish Destination
InfoPath won’t allow you to fix the publish destination, so you find yourself in an impossible situation. Fortunately, you do have a path forward.
Cracking Open InfoPath Templates
An InfoPath template file (XSN file) is actually a zipped up file comprised of a number of individual discrete files. You can expose and edit these individual files by simply renaming the template file with a .CAB extension. Save the template to your local drive and then use Windows Explorer to rename it to a .CAB extension.
When you do that, you can then navigate directly into the CAB and reveal these various files, as shown in Figure 5:
Figure 5: Inside the CAB file
The trick is to edit the manifest.xsf file directly. This includes those errant links pointing back to the development environment. The xsf file is actually an XML file and you can edit that with any old text editor.
Note that you need to extract the CAB file’s contents to another folder. Windows won’t allow you to edit the XSF file directly.
One quick way to edit the file is open notepad and then drag the .xsf file into it. When you do that, you’ll see the XML content and it will probably look similar to Figure 6:
Figure 6: Manifest.xsl inside Notepad
Closing the Loop
You’re just about there. Do a search and replace in this file for the incorrect reference to the dev server. Replace http://devserver/sites/devsitecollection with http://prodserver/sites/prodsitesollection.
Save the XSF file and then right-click it in InfoPath 2010. You’ll now be able to publish it to production.
Conclusion
This article describes how you can correct a problem that arises when you customize a SharePoint 2010’s default newform and editform data entry screen using InfoPath. If you back up a site collection from one environment to another, SharePoint doesn’t correct the link and as a result, your production site’s list will back to the development server.
The InfoPath client won’t let you correct this directly, so instead you can crack open the InfoPath form and manually correct the broken link.
Inquisitive readers should take this opportunity to poke around the XSF file and see what other interesting bits might be changed here. There are a lot of hidden nuggets tucked away in SharePoint as a whole and InfoPath forms are no different. Happy digging!
