Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

June, 2010

  • Microsoft InfoPath 2010

    Using TFS for Source Control in InfoPath 2010

    • 18 Comments

    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.

  • Microsoft InfoPath 2010

    How to Pass Querystring data into an InfoPath Form

    • 34 Comments

    Hi there, Daniel Broekman here. After showing you how to customize a SharePoint list with InfoPath 2010, and describing the differences between SharePoint list forms and form library forms together with Kate Everitt, I’m back with a quick tip for easily sending  a value from the browser’s query string into an InfoPath form.

    Imagine one of the following scenarios:

    • You want to dynamically pull all the invoices for a specific customer into a single form. For example, you could have a link to http://server/site/ShowInvoices.aspx?Customer=Contoso, which could be set up to display a list of all the Contoso invoices in a table. If you then swap out “Contoso” with “Fabrikam” in the URL, you would see all of the Fabrikam invoices.
    • You want to track referrals for your form. You can do this by specifying a dynamic default value for the form indicating the referral source. For example, you can include a link to http://server/site/form.aspx?Referrer=Email in an email you send to users, and add a link to http://server/site/form.aspx?Referrer=Website on the homepage of your website, and capture the value of the “Referrer” parameter along with the rest of the form data.

    In InfoPath 2007, you could accomplish these scenarios with code. With InfoPath 2010 and SharePoint 2010, there is a much easier way to send data from the query string into an InfoPath form. Let’s take a look.

    The basic concept

    Using a web part page and a part-to-part connection between a Query String (URL) Filter web part and an InfoPath Form Web Part (new in SharePoint 2010), we can easily pass a value from the browser’s query string into the form.

    Step-by-step

    I’m going to assume you already have a list form published to SharePoint. I just created a simple form to collect feedback on a conference presentation. As you can see, I included a “Referrer” field that will track the referral source of users filling out my form.

    Conference Feedback Form

    To set up the rest of the scenario, follow these steps:

    1. Create a new web part page.
    2. Add 2 web parts to the page. From the “Forms” category, add the InfoPath Form Web Part, and from the “Filters” category, add the Query String (URL) Filter web part. Web Part Adder (Forms Category)Web Part Adder (Filters Category)
    3. Configure the InfoPath Form Web Part to point to the list or library where your form is published. InfoPath Web Part Tool Pane
    4. Configure the Query String (URL) Filter web part to specify the parameter name it should look for in the URL. In this case, we want it to find “Referrer”. Query String Web Part Tool Pane
    5. Next, set up the part-to-part connection by opening the Web Part edit menu and selecting Connections > Send Filter Values To > InfoPath Form Web Part. Query String Web Part Connection Menu
    6. This brings up a dialog where you can choose the field in the form where the data should be sent. Choose the field you want, and then click Finish. In this case, we want to map the data to the “Referrer” field. Web Part Connection Dialog

    Everything should be set up correctly now. Save your changes to this page, and then navigate to the page. You should see the blank form.

    Saved Web Part Page

    Testing the Connection

    To test that everything is working correctly, add “?Referrer=email” to the end of the URL, and you should see the Referrer field being populated with the value “email”.

    Testing the Query Parameter Connection

    That’s it! You now have a page that passes data from the query string into an InfoPath form, set up in less than 5 minutes, and without any code.

    For more advanced scenarios, you can use this as a starting point. For example, you could have a rule on the “Referrer” field that performs certain actions based on the incoming value, such as querying a secondary data source, loading a specific item, etc. In the “customer invoice” example I gave at the beginning of this post, you could have an “onchange” rule on the “Customer” field that queries a secondary data connection for all of that customer’s invoices.

    One final note: the InfoPath Form Web Part only supports one incoming part-to-part connection at a time, which means that you are limited to passing one value into the form using this method.

    Please leave a comment to let me know how you’re using this functionality in your forms!

    Daniel Broekman

    Program Manager – Microsoft InfoPath

  • Microsoft InfoPath 2010

    Cool Form! MS Store Inventory Checklist

    • 7 Comments

    This week's cool form is an inventory check list form that is used in the Microsoft Company Store. The form contains 2 views.

    The 1st view contains a set of checks that need to be completed by store employees.

    The 2nd view displays the list of checks that have not yet been completed by the user.

     

    If you have a “cool” form that you would like to share with us, please send an e-mail with the following details to coolform@microsoft.com -

    • Attach 1 or 2 screenshots of your form
    • Provide a brief description of the form
    • You may also attach the XSN file (optional)

    The most popular submissions will be featured on our blog in future posts.

    Check out other Cool Forms here.

Page 1 of 1 (3 items)