Accelerate your InfoPath managed code development

Like most developers, I'm always looking for ways to speed up the code/test/get feedback cycle. There are many ways to do this in SharePoint development, and I guess a typical example would be to do application pool recycles rather than full IISResets. Along similar lines, anyone who has spent time doing Visual Studio/WF workflow development in SharePoint would hopefully have discovered the DEPLOY QUICK parameter on the build script MS supply - this will simply GAC the updated workflow assembly rather than perform a full deployment of the workflow Solution/Feature. This alone will probably shave many hours off a significant workflow project.

When working with InfoPath forms which have managed code, we need to deploy as an administrator-approved form rather than publish directly to a list or content type. The process is:

• publish the form to the filesystem
• upload the form via 'Manage form templates' in Central Admin

In the background, the last step actually wraps the form .xsn and associated assembly in a Solution and Feature, and deploys throughout your farm. Understandably this is S-L-O-W for development, so I started looking at ways to speed this up. Interestingly the assembly doesn't get deployed to the GAC or web application bin directory, but resides solely in the folder for the Feature (click image to enlarge):

Nevertheless, instead of publishing the form we can do the following:

• compile VSTA/VSTO project
• copy .dll (and .pdb if we're in debug mode) over the ones in the Feature folder
• recycle app pool

This will then load the updated code. Note because we've only deployed the updated code to the local machine, only form sessions on the local machine will be affected (I'm assuming you're not using a load-balanced URL in dev) - this has a nice side-effect of isolating your changes from other developers in the farm until you're ready to release them.

I'm interested to know how InfoPath accomplishes the trick of loading assemblies from this location at run-time -there are no custom 'probing' entries in my web.config (instructions to tell .Net to probe custom locations for assemblies) so I'm assuming it's done via reflection.

If you have your own tips for speeding up SharePoint development which aren't commonly-known, I'd be interested to hear...