Wednesday, October 13, 2010

Visual Studio versus VSTA

In taking over the duties of another developer who did part-time InfoPath maintenance, I've also been presented with an opportunity to clean out some dusty code closets.

All of the forms I've touched during my time here are in Visual Studio projects, but we still have a few forms that I haven't been directly involved in which were developed exclusively in VSTA. This change of guard has presented me with the opportunity to bring these other forms into alignment with our existing codebase, which is nice.

The first time I tried to migrate a VSTA project to Visual Studio, it was a nightmare. Not knowing how InfoPath 2007 integrated with VS08, I frequently found myself checking in-and-out code to avoid the dreaded "Operation could not be completed" errors. I was actually surprised earlier this week when I was able to successfully migrate a project in under half an hour, complete with renaming some extensionless files in the manifest and schemas.

The first pointer I learned for this task is a fairly simple one. If Visual Studio won't open the form, navigate to the manifest.xsf file, right-click on it, and select to Design the form in InfoPath. If there's a schema error in the form, the InfoPath client will point you straight to it. Visual Studio will not.

This will only carry you so far, of course. If you have a non-critical file missing that is specified in the manifest (such as a datafile for a data source), InfoPath will load your form in Design mode while Visual Studio will fail. Visual Studio also likes to complain when it can't get exclusive file locks on every file specified in your manifest.xsf, and accordingly, Visual Studio will refuse to open those files if the embedded InfoPath client is loaded (which also means that text searches will exclude those files!). Better keep that copy of Notepad2 handy.

Additionally, should Visual Studio lose its file lock on *any* of those files opened during Design mode, it will refuse to save any further changes, so save often!

This certainly seems like a lot of misery, but it's the best way to handle TFS integration, and it offers better debugging than you'll get out of VSTA, so it's a necessary evil. If you're prepared upfront and get some experience under your belt, it doesn't have to be a nightmare.

No comments:

Post a Comment