hen you want to build a simple formsomething with a set of fields and perhaps a table of repeating fieldsit's easy to pick up InfoPath and bang out a form in a matter of minutes, or at least within an hour. However, integrating code with your InfoPath forms can make form building a trickier proposition. Sure, VB.NET and C# are supported languages for extending InfoPath forms, but how does that support work and how are you going to be able to deploy it?
This discussion will allow you to investigate options for developing code when using InfoPath, consider the limitations, and discover ways to make intelligent, code-enabled InfoPath forms.
A Cornucopia of Coding Options
At first glance your options for developing code with InfoPath look simple. You can use either script or .NET code, namely C# or VB.NET, but in addition to language choices there are two different approaches that you can take for .NET development. You can use either Visual Studio Tools for Applications (VSTA) or Visual Studio Tools for Office (VSTO). VSTA ships with InfoPath and doesn't require a Visual Studio license, but VSTO does. As you explore the coding options for InfoPath, consider these .NET development environments first.
The decision between VSTA and VSTO is largely akin to making a decision about what brand of car to buy. Both will get you to your destinationa smart formbut they have different characteristics in terms of their focus and approach. VSTA is a sidecar to InfoPath; it takes the InfoPath interface and binds to it to manage the code's development.
You can use VSTA to design the form in InfoPath, and then you can write the code using the separate VSTA tool. This approach seems like a major inconvenience at first, but after a short time it becomes fairly natural. The nice part of VSTA is that if you're working on just the form's layout you don't have to open VSTA. You start InfoPath and away you go.
VSTO on the other hand integrates the InfoPath designer as a part of the Visual Studio experience; therefore, you can transition between designing the form and writing code for the form without leaving the tool. If you're approaching the form as a developer who happens to use InfoPath, then using VSTO may be the better solution. It supports source code control, even if it can be quirky.
The problem with VSTO is primarily that it's InfoPath designer tool doesn't reproduce InfoPath forms with 100 percent fidelity. If you can live with the quirks and have the extra time to learn more about it, VSTO is probably a better tool for long-term use.