How Do I Save And Check-In InfoPath 2010 Form Components Into TFS 2010?

Question

BACKGROUND: To check-in XSN component files into TFS, I've implemented the directory structure and practice of editing the manifest.xsf file discussed in the bolg/video by Philip Newman and Christopher Brotsos. I’m aware of the particular need to check-in only the XSN component files (not the binary XSN).

I have checked in a version of the project and am now at the stage of checking in the next version. Even after changing all file properties to be readable for editing work (not checking out of TFS), it seems TFS is preventing saving the xsf file. I’ve observed that I can take a copy of the project files in a different location and able to save the Definition File (xsf) file I’m working on without having to save as a Form Template (.xsn).

PROBLEM: When I try to save the manifest.xsf, I am forced to save it as a Form Template (.xsn) and did not have the option to save as a Definition file (.xsf).

IMAGE OF SETTINGS: http://i44.tinypic.com/igcfmt.png

ENVIRONMENT:
 - Development VM machine running Win Server 2008 R2 Std & SharePoint 2010
 - InfoPath 2010 with code in VSTA

QUESTION: Must I somehow unassociated the files with TFS in Explorer in order to save the XSF without having to save as an XSN?

Answer 1

Hi RKElder,

We can save the manifest.xsf file directly by clicking Save button, but when we save the manifest.xsf file using Save as..., we can only save it as .xsn file.

Best regards,
Emir

---

Emir Liu

TechNet Community Support

Answer 2

Emir,
I would expect clicking Save would correctly save the file as an XSF file, but both Save and Save As... only allow saving as an XSN.

Since I suspect InfoPath is only allowing saving as an XSN is related to a TFS connection preventing save permissions for some of the component files, I've tried the following:

• Confirmed the component files were all writable (Read-Only unchecked)
• Made sure the component files were not selected or displaying in the Source Control Explorer
• Changed the Team Explorer connection to a different TFS server, closed the VS Solution and closed VS
• Note: I DID NOT delete my workspace since I had several pending Source Control changes in other projects I did not want to loose

Even so, it would seem the shell extension is caching the connection; if this is indeed the what is preventing InfoPath from saving the file in the expected format.

References Related to PowerTools Extension:
I've not yet found a solution, but have found these discussions related to the Windows Shell Extensions for TFS. Unfortunately, they just discuss about how to restore the TFS context menus in Windows Explorer and not how to disable the extension or break the TFS connection.

• TFS 2010 Power Tools March 2011 Shell Extension - Missing 'New' item on context menu
• TFS PowerTools - Context Menu Gone Missing
• Missing overlay icons in the TFS 2010 Windows Shell Extensions

Answer 3

I've resorted to a work-around that at least allows me to make updates and check in the component files. I save an XSN file (based on the manafest.xsf in the "XSN Files" directory) at the root level of the project directory and specify the Programming path to the "Form Code" directory. Once I'm ready to check in my final changes, I checkout the InfoPath component files, Export the Source Files to the "XSN Files" directory, then check in the component files.

TFSProjectRoot
  |- XSNFile.xsn
  |- XSN Files (directory)
  |- Form Code (directory)

Answer 4

well, to share with you the way we am doing,

we simply check in/out the XSN files and it has been okay.

Answer 5

Jason,
Checking out & in the single XSN file will work, but the approach I've taken (based on the recommendation of the MS InfoPath Team referenced in my first post) has more flexibility.

The XSN file will be treated as a binary object that you cannot merge or perform a compare in source control. While the template component files allow comparing changes with other versions, merging into a branch, and even manual edits to the config files that make up the XSN. The extra steps certainly don't make it an elegant solution, but the separate files make it more feasible to collaborate.

If these source control attributes are valuable to you, you might consider what is presented in this video/blog:
http://blogs.msdn.com/b/infopath/archive/2010/06/10/using-tfs-for-source-control-in-infopath-2010.aspx