Udostępnij za pośrednictwem

Using TFS for Source Control in InfoPath 2010

  • Artykuł

In this video demo, Philip Newman and Christopher Brotsos from the InfoPath program management team show how you can use Team Foundation Server (TFS) to manage source control for your InfoPath forms with code. Get Microsoft Silverlight

Follow up

Team Foundation Server (TFS) is an effective repository and source control program for your InfoPath solutions. Teams add InfoPath forms and their related Visual Studio Tools for Applications (VSTA) projects to TFS, and then proceed to collaborate on the overall solution. Form designers focus on adding controls, rules, and layouts to their local copy of a form while developers add C# or Visual Basic .NET code to their local copy of a form code project. Then, by using the TFS visual tooling environment, designers and developers can easily merge their changes together into a complete InfoPath solution.

There are, however, some best-practices that you should, and in some cases must, implement in order to be successful.

Setting up your environment

Configure a portable local workspace

If your team plans to collaborate on an InfoPath solution, ensure all contributors work within a directory that everybody in the team can access via the same path. For example, use a common mapped drive, a UNC path, or as in the video, a local path that can be the same for all users of the project. In the video, we specifically used:

  1. %Root Directory% – C:InfoPath Projects
  2. %Project Directory% - %Root Directory%<ProjectName>
  3. %XSN Components Directory% - %Project Directory%XSN Files
  4. %VSTA Project Directory% - %Project Directory%XSN Sources

InfoPath’s default root directories, for XSNs and VSTA projects, fall under %USERPROFILE%. Because the %USERPROFILE% directory has a different name for each user, it will not be accessible through a common path for all those contributing to the project.

Work with the form template component files and not the XSN

When you collaborate on an InfoPath solution, you should work with the XSN component files themselves, and not the XSN. When you add a control, rule, or new attribute to a form it is common for more than one component file in the XSN to be updated. If you work with the XSN, and not the component files, the template will be treated as a binary object. Most source control programs do not let you diff and merge changes to binary objects, and without this granular view/control of the XSN, you will not be able to successfully collaborate with your teammates.

To work with the XSN component files, setup the local workspace and save/export the files as follows:

Starting a new project

  1. After selecting the template from the New tab in the Backstage, immediately export the XSN component files
    1. Choose Export Source Files from the Publish tab in the Backstage.
    2. Specify the %XSN Components Directory% as previously described and export.
  2. Set the VSTA project path
    1. Choose Form Options from the Info tab in the Backstage.
    2. Select the Programming category from the Form Options dialog, and set the %VSTA Project Directory%, as previously described, in the Project location text box.
  3. From now on, work with the component files instead of the XSN. To do this, open the XSF in the InfoPath Designer instead of the XSN.

Committing an existing project

It’s likely that your existing project is not already configured according to the requirements. So, make a backup of said project(s), and then change the configuration to support a shared design environment.

  1. Move the copy of the XSN to %Project Directory%.
  2. Move the copy of the VSTA project files to %VSTA Project Directory%. Note: do not copy over the current VSTA project root folder.
  3. Open the XSN in design mode.
  4. Export the XSN component files
    1. Choose Export Source Files from the Publish tab in the Backstage
    2. Specify the %XSN Components Directory% and export.
  5. Change the VSTA project path
    1. Choose Form Options from the Info tab in the Backstage.
    2. Select the Programming category from the Form Options dialog, and set the %VSTA Project Directory% in the Project location text box.
  6. Save your changes and from now on, work with the component files instead of the XSN. To do this, open the XSF in the InfoPath Designer instead of the XSN.

Read-only file properties, TFS, and InfoPath

Before Philip and I opened the XSF in design mode, you saw us remove the read-only property from the %Project Directory% instead of executing a check-out in TFS to remove the TFS file lock. Executing a check-out in TFS is not best-practice when working with an InfoPath project because InfoPath 2010 needs access to all of the component files during design mode. Likewise, you also saw Philip execute an atomic check-out/check-in before he updated the repository with the date field and validation rule he added. TFS won’t let you check-in until you check-out, so the two commands should be executed in sequence in order to successfully check-in updated files. (Note: I didn’t check my code into TFS in the video, but if I had, I would also have executed a check-out followed immediately by a check-in).

Configure TFS to check-in your DLLs and PDBs. In a standard Visual Studio project, this isn’t necessary because DLLs and PDBs can be built dynamically at build-time. InfoPath also generates DLLs and PDBs dynamically, but it also lists said files in the template manifest. As such, if the DLLs and PDBs aren’t in the %XSN Components Directory% then the Designer will fail to open with a schema validation error.

Multiple developers and designers working on a form

Avoiding conflicts with the schema, control properties, and the layout of a form can be managed by maintaining the following best practices in your team:

  1. Do not have more than one designer adding controls or modifying the layout of the form simultaneously.
  2. Do not have more than one designer adding rules to the form simultaneously.
  3. All controls and fields added to a form should be given a unique name.

SVN

Apache SVN works equally as well for collaborating on InfoPath form templates and their related VSTA projects. If the guidelines in this post are followed, your team can use SVN as a repository and source control management solution in the same way as Visual Studio Team Foundation Server. Each version control solution has its own benefits and caveats though, and you should evaluate each to determine which solution works best for your team. As an example: SVN doesn’t apply file locks to local copies of projects; its check-in/check-out paradigm differs from TFS. So, your team may find the file management aspects of SVN more intuitive and efficient. On the other hand, you will likely conclude that the CLI is the best choice for managing your project with SVN, and as such, you will lose the graphical/auto merge feature. Again, experiment, evaluate, and choose the solution which works best for your team.

Conclusion

InfoPath makes designing forms easy, and it provides you with a managed object model and access to the .NET Framework. This programmability support is available so that you can extend your forms into a variety of scenarios on the client and SharePoint. As your projects grow in size and complexity, you will find that using a managed repository is a quick and effective way for sharing solution amongst multiple developers and designers.

Comments

  • Anonymous
    June 10, 2010
    The comment has been removed

  • Anonymous
    June 11, 2010
    Thank you for your feedback. VSTA is the single IDE used for authoring managed code behind a standalone InfoPath form, and you are correct, it is based on VS 2005. However, VS2005 does not need to be installed on your machine in order to run VSTA.

  • Anonymous
    June 15, 2010
    Many thanks for your response but I was hoping you might address my main criticism that IDE tooling for InfoPath 2010 has seemingly taken a step backwards in that there does not seem to be native integration for managed code forms in Visual Studio 2010.  Given that so much time and effort has been put into making SharePoint development better supported in VS2010 why are managed code InfoPath forms the odd-one-out? Shouldn't it be as simple as Start Visual Studio - New Project - Office 2010 - InfoPath Form Template - add to Source Control?

  • Anonymous
    June 16, 2010
    In 2010 we provided an environment where development, the new design experience with the Backstage, and publish could be leveraged from a single environment. We have, however, heard from our customers (yourself included) that they want the VS integration for easier source control, workflow project management, and other scenarios. Because the InfoPath/Visual Studio integration does not exist this release, the experience is not as straightforward as you’ve outlined, and instead requires the workarounds highlighted in this blog post. Your feedback has made it to the team and will help us plan future versions of Office.

  • Anonymous
    June 28, 2010
    Why was the entry point of data importer framework removed in Infopath 2010?  I want to import MS Word and Excel into Infopath and it won't give me an option to do that.  Do I have to use Infopath 2007 to use that functionality?  

  • Anonymous
    June 28, 2010
    You can still import word and xl documents into InfoPath 2010. It’s “Convert Existing Form” in the Advanced Form Templates section

  • Anonymous
    June 28, 2010
    I thought so too because I was able to use it in the beta version of Infopath 2010 but after loading the full Enterprise version of Office and going to MS Infopath Designer 2010 > Advanced Form Templates > Convert Existing Form - Select the import method to use: window is empty and not giving me the option to chooose a word/excel doc.  

  • Anonymous
    June 28, 2010
    This should still work. Have you tried reinstalling Office?

  • Anonymous
    July 08, 2010
    Very sad about the lack of InfoPath development support in VS 2010. Are there any plans to release this support in a service or feature pack? I just can't see having our developers flip between 3 applications to incorporate InfoPath into our solution, especially since the functionality did exist (though somewhat buggy) in Office 2007 / VS 2008. It really makes me feel like InfoPath is just not ready for prime time.

  • Anonymous
    August 14, 2010
    Good article. I've a problem trying to save the xsf file, It only allow me to save as xsn file. Thanks.

  • Anonymous
    August 14, 2010
    I figured out why...It's because I moved the folder where I exported the first time.

  • Anonymous
    October 07, 2010
    Thanks for the video,  We are evaluating InfoPath as option for our document standardization review.  It would be great if there is a straight forward & clear approach to integrate with source control system. Also please let me know where I can find best practice guidelines for InfoPath development ( like versioning, source control,security, schema design, deployment).

  • Anonymous
    December 07, 2010
    In VS2008, we would have solutions that would typically have a SharePoint workflow project and then 1 or several projects that were InfoPath form projects that the workflow would use at various points in the flow. With the new way of doing things in seperate environments, how do you affect debugging? I need to be debugging the workflow and traverse into the code-behind in the InfoPath form. I am not understanding how to achieve this. Any help would be greatly appreciated.

  • Anonymous
    December 20, 2010
    Do you have any timeline for Visual Studio 2010 integration? As VSTA is obviously going backward from VS 2008 in terms of IDE, source control, debugging and SharePoint integration. We might stick with Infopath 2007 till IFP 2010 supports VS integration.

  • Anonymous
    January 30, 2011
    As others have already stated, I have discovered this break away from VS 2010 integration to be a major step backwards in infopath development. Using a separate application for editing form code poses some serious hassles when: a) you want to use .NET 3.5 features such as linq. b) Your form code is referencing code written in your other primary IDE. I was surprised to discover this limitation and spent the better part of a day trying to figure out how to create a new infopath form project in VS 2010.

  • Anonymous
    January 30, 2011
    One more thing, and I say this with all possible respect: The repetitive use of the phrase "go ahead" 20-30 times in a 10 minute video makes for an office-space metaphor that is borderline painful to watch to completion.

  • Anonymous
    February 24, 2012
    The comment has been removed

  • Anonymous
    June 10, 2013
    Philip & Christopher, I was really excited when I found your video... because it will solve a problem I have been struggling with... I have access to TFS 2010.  I am using VS2012 in conjunction with InfoPath Designer 2013 for the development of an InfoPath 2010 form.  Is it still possible to keep the code for a InfoPath 2010 form stored in TFS Version Control?