I’ve spent a little while trying to get to the bottom of a deployment problem when updating an existing InfoPath form that had previously been deployed to a SharePoint site via a feature. The change was a simple textual change, adding some descriptive text to the top of a form. Simple you might think…
Actually making the change was easy enough, I opened the design form from within Visual Studio. Interestingly even though I had double-clicked the file from within my source tree it was actually opening it from a path that was stored within the file. Saving the form template to my source tree has got around that. Its something that I wouldn’t have noticed apart from the fact that the location it was actually opening it from was write-protected and hence it couldn’t save it. Otherwise I would have made my changes and blindly checked it in thinking I was actually checking in my files. It would have appeared to have worked but the actual changes would have been in a file that wasn’t under source control!
I then published the form template to where it was stored in TFS in my feature folder. I wasn’t sure what options had been previously used during the original publishing so I just accepted the defaults (this was where I went wrong…). I then updated my wsp and upgraded my feature. Upgrading didn’t work as the file is actually uploaded into SharePoint via a module definition so I had to change my deployment to do a retract/redeploy instead. I realised this as post upgrading nothing seemed to have changed within the form. After doing a retract/redeploy I now got something different which was basically a ‘form has been closed’ error on trying to access any workflows that were using this form.
Doing some digging using the following useful stsadm command:
stsadm.exe -o verifyformtemplate -filename <complete path to your xsn including the name.xsn>
I got the following back:
FatalErrorNoThrow : This form template has not been correctly published to be browser-enabled. Open the form template in InfoPath Design mode, and click Publish Form Template in the Design task pane. Follow the steps in the Publishing Wizard to republish the form template, and then try again.
Well I did this many times, trying different combinations of settings, even trying to modify the access location to be the path to the installed feature in the 12 hive. I thought this might be something to do with the fact that it was originally trying to open it from a different source location and I thought it might be something to do with me moving it to my source location however nothing seemed to work. I then did some more searching and came across a really good post by Sahil Malik that explains the correct process to follow to deploy InfoPath forms via features, and in there he mentions leaving the access path blank, as this information is stored in the feature. This was the key thing that I was doing wrong. It appears that anything you put in the Access Path property during the Publishing path overrides what is supplied in the feature and stops the form from deploying correctly, in fact if you go to the Manage Form Templates page within Central Administration you will see your deployed form stuck in a Status of Installing and the Workflow enabled option will be No.
Here is a link to Sahil’s post as it really explains in good detail the correct process to follow to deploy InfoPath forms using features:
Blanking the access path and then rebuilding my wsp, retracting/redeploying and now everything works. Existing workflows have been updated and new ones pick up the new form too. Finally, and all I was doing was adding some text to the form… 🙂