My team has been working on an InfoPath 2007 form (using Visual Studio Tools for Applications) for a while. The form is bound to an XML structure having approximately 100 fields/properties. Since its initial build, the form has been modified, recompiled and re-packaged for quite a lot of times.
Users complained that form load times are quite long. It seemed that by every version they are getting even worse. The initial thought was that the delay was due to loading of SharePoint data (through secondary data sources). However, profiling showed that it takes less than a second to load them.
Recently, we found out that by each build the manifest.xsf file becomes larger and larger. The initial version was less than 100K, while the current one is 500K. The reason for such growth was – automatically generated “InfoPath variables” in the form. Something like this:
<xsf:xmlToEdit name="SomeFieldName_3721" item="/my:SomeContainer/my:SomeSubNode/my:SubSubNode">
<xsf:editWith autoComplete="no" component="xField"></xsf:editWith>
</xsf:xmlToEdit>
The variables can be later referenced in InfoPath’s own XSLT views as well as in context menu definitions in the manifest.xsf. However, these variables are never cleaned up. The list is growing each time you save your form using form designer.
It seems that Infopath initializes each variable upon form load. The more variables you have, the longer it takes to load the form.
When there are thousands of such variables, cleanup is not very easy. Hence, I wrote a PowerShell script to do the job. It enumerates all the variables and looks for references to this variable in manifest.xsf and in all .xsd views of your InfoPath form.