\n<\/p>\n
\r\n\r\n\r\n \r\n \r\n <\/FieldRefs>\r\n The important sections from the above markup are the ID<\/em> and RequireClientRenderingOnNew<\/em> attributes.<\/p>\nFor your new content type to be usable in a Forms library (or for that matter the XmlFormView class) and use a web compatible InfoPath form it must inherit from the Form content type, which has an ID of 0x010101. To inherit from this all you have to do is add two zeros and then your own identifier.<\/p>\n
The second attribute, RequireClientRenderingOnNew<\/em>, specifies if the browser should use the application specified by the ProgId attribute (not shown here) when creating or viewing a form. By default this is set to true, setting to false will configure the content type to render the form in the browser, using the FormServer aspx<\/em> page that’s located in the LAYOUTS<\/em> folder.<\/p>\nThe next step is to create your InfoPath form. My post here<\/a> describes the necessary steps for publishing a web compatible form. The content type used in that post is designed for a workflow’s instantiation page. Deploying it that way automatically tries to register the form for web browsing.<\/p>\nOf course, that’s not much use if you want to deploy the form as content in a Forms library, for instance.<\/p>\n
Now that you have your form and have added it to your project, the next thing you should do is change the deploy location for the xsn file. This is an important step, as the InfoPath feature receiver (mentioned in the next paragraph) will only look in the root folder of the feature for candidate files and by default when you add a file to a module it is deployed to its folder. To do this, select you xsn file in the Solution Explorer, then bring up the Properties pane.<\/p>\n
![\"\"](\"http:\/\/www.stuartroberts.net\/wp-content\/uploads\/2010\/12\/XSN-Properties.jpg\" "\\"XSN")
<\/a>XSN Properties<\/p><\/div>\n
Expand the Deployment Location<\/em> node and clear the Path<\/em> attribute. This will change the deployment location for your xsn file to the root of the relevant feature.<\/p>\nImportant<\/strong>, now edit the elements xml file and ensure the type attribute is set to GhostableInLibrary for the form. Failing to do this will mean the file will not be editable and the feature activation will not process the form and enable it for web browsing. I also set the Url for the module to point to the FormServerTemplates library, which will be created automatically as the feature code attempts to web browser enable the form(s).<\/p>\n\r\n\r\n Here you have three options. The first is good if you are not bothered about the content type that is used. If this is the case, you can ignore the creation of the content type from the start of this post. This is because if you deploy the form as part of a feature and specify the XsnFeatureReceiver class from the Microsoft.Office.InfoPath.Server assembly as the receiver, your form is automatically registered for web browsing and a suitable content type is created under the Microsoft Office InfoPath<\/em> group with your form associated. The assembly and class values are shown below.<\/p>\nReceiver Assembly<\/em> = Microsoft.Office.InfoPath.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
\nReceiver Class<\/em> = Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver<\/p>\nWhen using this feature receiver, you’ll also have to add an activation dependency to your feature, otherwise the receiver may not fire. The dependency is for the InfoPath Forms Service support<\/em> feature with the GUID C88C4FF1-DBF5-4649-AD9F-C6C426EBCBF5<\/em>.<\/p>\n![\"\"](\"http:\/\/www.stuartroberts.net\/wp-content\/uploads\/2010\/12\/Activation-Dependency-300x48.png\" "\\"Activation")
<\/a>Activation Dependency<\/p><\/div>\n
With the second method if you were to deploy the above content type and then the form with the XsnFeatureReceiver feature receiver, not only will your form be registered, but your content type will also be enabled for displaying the form in the browser. This is only the case if your content type directly inherits from the Form<\/em> content type. If your content type is once removed then this step will fail.<\/p>\nThe last method is for content types that do not directly inherit from the Form<\/em> type.<\/p>\nAdd an event handler to the feature that deploys your form, this will remove the reference to any existing receiver that you may be referencing.<\/p>\n
Add the Microsoft.Office.InfoPath.Server.dll<\/em> assembly to your project.<\/p>\nNext add the following using declarations:<\/p>\n
\r\nusing System;\r\nusing System.Collections.Generic;\r\nusing System.IO;\r\nusing System.Runtime.InteropServices;\r\nusing System.Security.Permissions;\r\n\r\nusing Microsoft.SharePoint;\r\nusing Microsoft.SharePoint.Administration;\r\nusing Microsoft.SharePoint.Utilities;\r\nusing Microsoft.SharePoint.Security;\r\nusing Microsoft.Office.InfoPath.Server.Administration;\r\n<\/pre>\nThis feature will implement the FeatureInstalled, FeatureActivated and FeatureUninstalling events. On installation we will register all forms that are being deployed as part of your feature. The activated event will update the content type to allow web rendering and uninstalling will unregister the forms from the site collection.<\/p>\n
The installed method is shown below.<\/p>\n
\r\npublic override void FeatureInstalled(SPFeatureReceiverProperties properties)\r\n{\r\n base.FeatureInstalled(properties);\r\n\r\n FormsService formsService = GetFormsService();\r\n if (formsService == null)\r\n {\r\n throw new ArgumentNullException(\"formsService\",\r\n string.Format(\"Unable to retrieve FormsService during installation of \\\"{0}\\\". Argument formsService was null.\"),\r\n properties.Feature.Definition.Name);\r\n }\r\n\r\n \/\/ Get list of form templates that are being deployed as part of this feature.\r\n List formTemplates = GetInfoPathFormTemplates(properties.Definition.Properties, properties.Definition.RootDirectory);\r\n foreach (string formTemplate in formTemplates)\r\n {\r\n if (formsService.FormTemplates.ItemFromFile(formTemplate) == null)\r\n {\r\n FormTemplateCollection.RegisterFormTemplate(formTemplate, properties.Definition, false);\r\n }\r\n }\r\n}\r\n<\/pre>\nThis method gets the FormsService using a custom private method which we’ll come to later. The FormsService object allows you to access the currently registered forms.<\/p>\n
Next we call the GetInfoPathFormTemplates method, which again is a custom private method. This method returns a generic list of paths to the forms that are referenced in your feature. As with the previous method, I’ll show this later.<\/p>\n
The last step of this event is to call the static method RegisterFormTemplate<\/em> of the FormTemplateCollection<\/em> class. The full namespace for this class is Microsoft.Office.InfoPath.Server.Administration<\/em>. This method will register the form on the farm.<\/p>\nThe uninstall event is very similar but this time unregisters the forms.<\/p>\n
\r\npublic override void FeatureUninstalling(SPFeatureReceiverProperties properties)\r\n{\r\n base.FeatureUninstalling(properties);\r\n\r\n FormsService formsService = GetFormsService();\r\n if (formsService == null)\r\n {\r\n throw new ArgumentNullException(\"formsService\",\r\n string.Format(\"Unable to retrieve FormsService during uninstallation of \\\"{0}\\\". Argument formsService was null.\"),\r\n properties.Feature.Definition.Name);\r\n }\r\n\r\n \/\/ Get list of form templates that were deployed as part of this feature.\r\n List formTemplates = GetInfoPathFormTemplates(properties.Definition.Properties, properties.Definition.RootDirectory);\r\n foreach (string formTemplate in formTemplates)\r\n {\r\n if (formsService.FormTemplates.ItemFromFile(formTemplate) != null)\r\n {\r\n formsService.FormTemplates.UnregisterFormTemplate(formTemplate, properties.Definition);\r\n }\r\n }\r\n}\r\n<\/pre>\nThe main difference here is that to unregister we don’t call a static method of FormTemplateCollection<\/em> but instead call the UnregisterFormTemplate<\/em> method of the FormTemplates<\/em> property contained in the FormsService<\/em> object that was retrieved at the start of the method.<\/p>\nThe two methods used by the installing and activated events are shown below:<\/p>\n
\r\nprivate List GetInfoPathFormTemplates(SPFeaturePropertyCollection properties, string featureRootPath)\r\n{\r\n FileInfo[] filesInfo = new DirectoryInfo(featureRootPath).GetFiles(\"*.xsn\");\r\n List infoPathFormFileSpecs = new List();\r\n foreach (FileInfo fileInfo in filesInfo)\r\n {\r\n infoPathFormFileSpecs.Add(Path.Combine(fileInfo.DirectoryName, fileInfo.Name));\r\n }\r\n\r\n return infoPathFormFileSpecs;\r\n}\r\n\r\nprivate FormsService GetFormsService()\r\n{\r\n FormsService formsService = null;\r\n if (SPFarm.Local != null)\r\n {\r\n formsService = SPFarm.Local.Services.GetValue(string.Empty);\r\n }\r\n else\r\n {\r\n formsService = SPContext.Current.Site.WebApplication.Farm.Services.GetValue(string.Empty);\r\n }\r\n return formsService;\r\n}\r\n<\/pre>\nGetInfoPathFormTemplates<\/em> looks in the root path of the feature for any file with the xsn extension and returns the path information.<\/p>\nGetFormsService<\/em> attempts to get the FormsService object from the local farm, first by referencing the SPFarm object directly. Where this is null, it tries to retrieve it from SPContext.<\/p>\nThe last piece of code to complete the registration is for the activated event. Here we will be updating a custom content type, twice removed from the Form<\/em> type.<\/p>\n\r\nprivate const string MINIMALACTIVEXTOOPEN = \"SharePoint.OpenXmlDocuments.2\";\r\n\r\npublic override void FeatureActivated(SPFeatureReceiverProperties properties)\r\n{\r\n SPSite site = properties.Feature.Parent as SPSite;\r\n SPWeb currentWeb = site.RootWeb;\r\n\r\n \/\/ Update the custom content type to allow rendering in web browser.\r\n SPContentType ct = currentWeb.ContentTypes[new SPContentTypeId(\"0x0101010076AEDEA7CA2A44B59ECB3D491618E05200726740CD03C4478FB0897E6993DDE8D0\")];\r\n if (ct.NewDocumentControl != MINIMALACTIVEXTOOPEN || ct.RequireClientRenderingOnNew)\r\n {\r\n ct.NewDocumentControl = MINIMALACTIVEXTOOPEN;\r\n \/\/ Ensure the RequireClientRenderingOnNew property is correctly set for web browsing.\r\n ct.RequireClientRenderingOnNew = false;\r\n\r\n \/\/ Don't forget to update the content type with the changes.\r\n ct.Update(true, false);\r\n }\r\n}\r\n<\/pre>\nAs this example feature is scoped to site level, we only need to cast the Parent<\/em> object to SPSite.<\/p>\nUsing the root SPWeb object the custom content type is retrieved by its identifier. This could just as easily be a collection of content types, but for this example we are only updating one.<\/p>\n
The two properties that are being updated are NewDocumentControl<\/em> and RequireClientRenderingOnNew<\/em>.<\/p>\nNewDocumentControl<\/em> identifies the application used to create new document, which for InfoPath forms should be set to “SharePoint.OpenXmlDocuments.2”.<\/p>\nThe second property, RequireClientRenderingOnNew<\/em> will have already been defined in the content type markup, but it’s worthwhile making sure at this stage, otherwise you won’t be able to view the form in the web browser.<\/p>\nNow when you activate the feature you will have an InfoPath form that is able to be viewable within the browser. Remember that for this to work you will require the Enterprise version of SharePoint.<\/p>\n","protected":false},"excerpt":{"rendered":"
A topic that is not particularly well document with SharePoint is how to deploy a web browser compatible InfoPath form via a feature. Deploying a form through the Central Administration site provides such a form. This isn’t much use if … Continue reading