InfoPath Dev

I must be doing something wrong...

First, I have been developing with InfoPath 2003 for around 6 years on Windows XP and have just upgraded to Windows 7 and InfoPath 2010...and I must say that I am extremely disppointed and displeased with the upgrade and the "new way" to develop...Of course, I'll give Microsoft the benefit of the doubt for the moment...

My general question is: How is one supposed to reliably develop with InfoPath 2010?

As you all know, InfoPath template development has been removed from Visual Studio and now InfoPath 2010 carries with it its own version of Visual Studio Tools for Applications 2005 for managed code development.  Not only did I find this unintuitive but it made development needlessly cumbersome, in particular having to extract and re-bundle source files from/to the .xsn template...and this is the source of my problems...

After watching a video from Microsoft with their InfoPath team developers (I believe Chris Brotsos?) regarding source control for InfoPath development, they suggest having a master project folder for the template under which are 2 subfolders: "XSN Files" (where all the schemas, manifest, resources, etc. reside) and "XSN Sources" (where all the managed code resides).  So, I mimicked this approach, keeping the generated .xsn file in the master project folder.

What I have found is that when I go to File | Publish | Extract Source Files and choose my "XSN Files" folder that the .xsn files seem to extract fine but the source code also gets extracted but to a completely different location, in particular, a comletely made up location under the "Project location for Visual Basic and C# code:" entry on the Design tab on the Options window for the InfoPath application.  And then, this same entry for my template project is changed behind my back to reflect this new location. 

Of course, as I am trying to upgrade IP 2003 forms, sometimes I modify the schemas and resources manually.  Then, as the video demonstrates, I right-click on manitest.xsf and click Design to incorporate the changes into the .xsn.  Everytime I go through this gyration, my template and project references get all messed up.

Needless to say, I have been going around in circles trying to fix/add/patch missing code which vanishes from my project because I wind up working on code in location A thinking that I am working on code in location B.  Oh, and for some strange reason, assembly references from my .csproj file (like Microsoft.Office.Interop.InfoPath.SemiTrust) vanish as well each time I go through these gyrations.  I can't be confident in what I am doing anymore without constantly re-checking that the project references are valid and in the state which I think they are.  And yes, I have tried researching this and inspecting every niche and crany of IP configuration settings and of each of the XSN files that I can find.

I'm sure Microsoft has a logical and thoughtful reason and explanation for all this and that I am doing something completely wrong.

Can somebody please either explain to me how I am supposed to develop IP 2010 forms or at least point me in the direction of some good references?

I and what is left of my hair thank anyone who can help shed some light on this bizarre behavior.

Tony

Hi Tony,

Believe me, we feel your pain. I'm going to defer to Hilary and Jimmy and others for advice on the coding. What I can tell you is that things dramatically changed and there was no "good story" for developing code with InfoPath forms.

However, most forms don't need code, and those that do, can use our qRules plugin which covers 130 of the most requested features that require code. So, at the risk of sounding like a blowhard, I think you should consider just using our common library. It will save you time down the road. We don't make any money off of it. We use the proceeds to pay for time in the forum. It doesn't cover that time but it does help people and the best thing about it is that it's xpath agnostic which means you can use it in all of your forms.

What do you need code for in your form? What are the 10 features you need? My guess is that qRules will handle them.

I'm more than happy to help you migrate your 2003 code over to qRules commands.

qRules will reduce or eliminate the amount of code in your form which means lower maintenance cost. If you need source, let us know and we'll work out something for you. qRules can be used in conjunction with other code in your forum, but it only supports 2007 and 2010 object models. Check it out: http://www.qdabra.com/en/products/qRules_overview.aspx

Now, if you really want to do it yourself, that's cool. I'll ask Hilary and Jimmy to respond with info on the optimal developer environment.

More soon,

P

Hello Tony,

 As Patrick alluded, after much trial and error Hilary and I have mostly found our stride using InfoPath with source control. I believe I've seen the video you referred to, and though it provided some good information, I disagreed with quite a bit of it (particularly the part about merging simultaneous changes from multiple form developers, which I think is complete madness).

 This is what I have found to work:

• Decide on a consistent path for people to have their source control files stored locally.  If one person uses C:\SourceControl\ on their machine, and another person uses C:\MySourceControl\, then this will cause difficulty for sharing form development, because InfoPath uses absolute paths in its form save locations. 
• Store your InfoPath form source along with its code, in subfolders under a single folder, like:
  Widget Shipping Form
      Form Source
        (XSN source files)
      Code
        (Code project and files)
• To initially get your form into this structure, use the Export Source Files option to save it to the desired location. If it creates a new copy of your code project, move that project to the location you want it, and use File->Form Options->Programming->Browse in InfoPath to redirect the reference. 
• Then check all of the source files and code project into source control
• When you need to make modifications to the form, clear the Read Only attribute on all files in both the XSN source and the code project. If you don't do this, InfoPath will try to save the form to a new location when you go to save it.
• Then use right-click->Design on the manifest.xsf to open the form up.
• When you are done making changes, first save the form (which will update the XSN source files), and then if you want to deploy the form somewhere, either use File->Publish or File->Save As..., depending on how you intend to use it.
• In Visual Studio, do a compare operation on the form's folder. Check out changed files. Add new files that are not yet checked in. Delete files that are on the server but no longer in the local folder.

I have encountered the same issue as you with a disappearing assembly reference (specifically System.Xml) when working on one of our IP 2003 forms. I have not found a way around this besides re-adding it each time I work on the form. It seems VSTA just strips out certain references when the project is opened.  I have not, however, had this issue when working on 2007 or 2010 forms.

And nowadays, very few of our forms have their own custom code (the ones that need code-only features use qRules), which makes the whole process a lot easier. We can just have each form checked in as a folder of XSN source files, and there's no complicated coordination with .csproj projects.

Hi Patrick & Jimmy,

Thank you for your empathy and relating your shared frustrations.  When I started using IP I thought "what a great tool" for our purposes.  I work in a hospital and I have built managed code forms to help nursing units submit patient information to our Infection Control department and directly into a database. Intense government regulations have "influenced" many of our approaches.

I need to back up for a moment and tell you a story:  Several years ago I noticed a severe bug in conjunction with a .Net 2.0 rollout.  I am not in I.T. but I produce software like I am.  Our I.T. department authorized me to track down the bug on the Premier Support contract they had with Microsoft.  It took me over a month to do so and I wound up talking with developers in Texas at the heart of InfoPath development.  We actually found a couple bugs, one in System.XML and the other with how IP handled schema references in XML resource files.

Back to topic relevancy: During this process I talked with the developers and explained what I was doing and why.  Paraphrasing, the response was that IP was generally envisioned to behave a certain way and IP development was originally and generally intended to be done with rules; however, although what I was doing was pushing the envelope, nothing was inherently wrong with my approach and in fact IP supported that in that IP supports managed code processing.

So what am I doing that requires code?

First, HIPPA and other government regulations require that health information be tied to a source, in other words, we can't receive anonymous patient information without knowing who sent it.  Furthermore, we use Single Sign On in our facility.  So, in order to ascertain who is sending the information we need code to interface with the system to determine who is logged on.

Second, our validation rules are too complex for the standard rule based approach.

Third, in filling out the form, utilization of Windows forms dialog boxes were necessary.  Using other views was not sufficient and switching back and forth was not satisfactory.

Forth, we needed custom event handling that just worked better in code and in some cases was really only viable in code.

So, I think I need to stay with code.  I will check out qRules.  I find it interesting that IP 2010 seems only to use VB and C# and no longer appears to support JavaScript or VB script.  It used to be with IP 2003 that if you wanted a managed code form you had to go out of your way to do it with Visual Studio 2003.  Now, with VSTA part of IP 2010 it is all too easy to create managed code forms from within the IP application itself.

Jimmy,

Could you please clarify, are you advocating a directory structure with everything in one folder as in

My Project Folder
   manifest.xsf
   schema.xsd
   view1.xsl
   FormCode.cs
   Assembly.cs

or something along the lines of

My Project Folder
   XSN Files Folder
      manifest.xsl
      schema.xsd
      view1.xsl
   Code Files Folder
      FormCode.cs
      Assembly.cs

Also, I recall the proviso about Read Only in the video.  It didn't make any sense to me.  Do you know why it does that and what is going on with this?  You mentioned that if the files are Read Only that updated/new files get copied to another location.  I didn't think this was what was happening to me as my files are not yet under source control but maybe this is the beast which is afflicting us all?  I haven't investigated this yet, bet maybe if this is what's happening I'll have to write an add-in or something to remove the Read Only attributes.  Similarly, maybe an add-in to check vanishing assembly references and automatically put them back.  Maybe you can try testing IP 2010 with the Microsoft.Office.Interop.InfoPath.SemiTrust assembly.  I'd be curious to see if this assembly vanishes for you as well in IP 2010 with CSharp.

Thank you Patrick and Jimmy for your comments.  It looks like I will just have to bite my tongue and grin and bear it for the time being.  It may be that we will have to abandon InfoPath if it is going to remain so quirky and (at least not in spirit) support managed code development. 

Cheers,
Tony