I created a little experiment to serve InfoPath documents dynamically from ASP.NET. Once opened, I wanted the form to already be populated with values from a database rather then having two views (Query and Data Entry). Then, the user could make whatever changes necessary and post back to a web service. The user could also save the document for offline editing and submit to the web service when getting back online later.
I ran into a few snags while trying to get this to work and thought I'd throw up here to show how I got around them and see if there are any other solutions floating around.
An InfoPath XML document is marked with a processing instruction (PI) just like other Office 2003 XML documents. This PI (mso-application) tells the OS which application to launch in order to edit that XML document. The InfoPath document also has a PI (mso-infoPathSolution) that ties the XML document to a form that is capable of editing the file. Here's an example of the two PIs:
<?mso-infoPathSolution solutionVersion="1.0.0.1" productVersion="11.0.5531" PIVersion="1.0.0.0" href="http://localhost/Forms/CustomerForm.xsn" language="en-us" ?>
<?mso-application progid="InfoPath.Document"?>
The href tag in the mso-infoPathSolution PI points to the location of the InfoPath form that can edit this XML document.
My first attempt was to use an ASPX page that had the ContentType attribute of the @Page directory set to text/xml. I then included the PIs in at the beginning of the file and returned an XML structure that replicated the structure of my sample XML files from my InfoPath form.
The result was that Internet Explorer would only render the XML. It would not launch the InfoPath application even the PIs were present. Static XML documentes served from the web server worked fine, but my dynamic result would not. I traced this down to a problem with ASP.NET and Internet Explorer. By default, ASP.NET adds a charset parameter to the Content-Type HTTP header. It appears as “text/xml; charset=utf-8“. Due to what I guess is a bug in IE, the charset parameter causes IE to not recognize the PIs at the beginning of the file.
No problem, I turned off the charset parameter:
Response.Charset = "";
After turning off the charset parameter, InfoPath would launch when Internet Explorer received the XML document. However, it seems that InfoPath would go back out and rerequest the page using another method such as FrontPage server extensions. InfoPath would read try to read and use the actual ASPX file.
I guess there are a few ways this could be fixed. One option would be to turn off whatever method InfoPath was using to request the source ASPX file. Another option, and the one I used, was to create a quick HttpHandler that mapped to the .XML extension. The HttpHandler would rewrite the request using the .ASPX extension and call context.Server.Execute(newFileName). This way I could still use ASPX to declaratively describe the XML structure and use databinding to fill in the values.
The actual file with the XML extension does not exist, so InfoPath now uses the document I returned dynamically. It was a bit of a journey, but now I can dynamically create the InfoPath document and link it to a form definition. The user can edit the values in the form and submit it back to the web service.
To integrate it with an over all solution, the user browses a web page that allows searching for records. Once a record is located, the user can view the details, still in the web browser. On the details page, they can click on an URL that will launch InfoPath so they can edit the record using the rich UI features of the InfoPath smart client.