Scenario: Follow the instructions here and here to package and deploy InfoPath 2010 browser-enabled forms. You should have a SharePoint 2010 solution package with the following structure:
- A site collection scoped feature
A custom content type for the form
A list definition for the content type
A feature receiver that installs the form template and sets the render mode to browser
A module containing the InfoPath Form (.xsn)
- A web scoped feature
A list instance of above list definition
The problem is that even if you follow all these steps, the form still opens in the client tool rather than in the browser. It is hard to know what went wrong since there are many steps and configurations involved, and there is a lack of detailed warning information in the last step for troubleshooting.
Here is a check list to help you quickly identify the problem:
- Check to make sure all the dependency features are activated in order to support the InfoPath form service and store the administrator-approved form templates.
Make sure the following features are activated:
Site collection scope: Enterprise site collection feature
Web scope: Enterprise web feature and team collaboration list feature
- Make sure your InfoPath forms can be published manually as browser compliable forms.
Publish your InfoPath form through InfoPath designer to a SharePoint library manually and make sure there is no error saying they are not browser compatible. Note the security level has to be domain or full trust.
This is especially important when you upgrade or covert old forms which are not browser enabled. The browser enabled forms require much stricter XSD schema and support less controls. You have to eliminate or substitute all the controls and features which are not supported by the InfoPath Form Service.
- Make sure the form templates appear under administrator approved templates in Central Admin.
Go to Center Admin->General Application Settings->Manage Form Templates. Make sure all the forms appear.
If the forms did not appear as expected, check the ULS logs and look for the error messages for your feature events to register the forms. One issue I run into is that the code snippet was trying to register the form template from featureInstalled event, after I added some code using SPWeb.features.add to active the dependency features in featureinstalled event, forms won’t show up under the template library anymore. By looking into the ULS logs, I can see that since FeatureInstalled Event handler cannot get hold of SPSite or SPWeb, which causes the event handler to throw an exception and therefore prevent the form templates from being registered. Another exception is the code snippet assumes the .xsn files are deployed to the top folder of the feature rather than under the module names as the default setting. After change the deployment location of the files to the top folder of the feature, the forms were registered without exception and show on under the template library.
- Make sure the forms under formtemplates library can be opened in the browser.
Go to the site, click Site Actions-> View All site contents->Form Templates. Make sure all the forms templates appear and can be opened in the browser rather than in the client filler application. If not, the form templates are not registered properly. Review step 3.
- Make sure the Content type references the right path of the form template.
Go to content type -> advanced setting. Make sure Edit Template link appears. If not, check the setting for the path to the form template file in the content type declaration.
- Lastly, make sure the list definition is set to allow the change content type.
Go to Form Library-> Library Settings->Advanced Settings and make sure the setting are as in the following screenshot. If not, make sure you add the setting DisallowContentTypes="FALSE" to the list definition elements.xml and EnableContentTypes="TRUE" in list schema.xml.