XmlFormViewer In ASP.NET Application
In my zeal to be on the bleeding edge of technology, I'm taking an ASP.NET application that was using custom ASPX pages for UI requirements and am looking into having that UI done in InfoPath 2007. With the new (and what sounds cool) feature of being able to host InfoPath forms in the browser, I thought it would solve a revolving problem we have that requires a “developer” to create new ASPX pages for each template we want to automate. InfoPath is much more intuitive for a non-developer to use and as long as my app can get the return data, it's a really great solution to what has been a headache for a number of years.
I've spent the better portion of two days trying to make this work. The first requirement of using the XmlFormViewer is that you must develop your application on the same machine as your Forms Server (ie., Office Server). I don't know any developer that keeps their dev engine on their server and I'm still hoping this requirement is just a pre-RTM requirement but, nonetheless, I decided the easier route was to install Office Server on my development box rather than installing the dev engine on my test lab and having to keep my code over there. After getting past the various error message, installation issues (since I had Office 12 on here previously as well as SQL Server) and getting Office Server installed, I then set about to figuring out how to just get my custom apps to run under a box with Office Server on it. This wasn't necessarily the easiest task I've taken on lately!
A second requirement of using the XmlFormViewer is that you cannot cross domains to access an XSN. This meant that my custom app had to reside in the same domain. I tried many, many things to get this to work with little success. If you look in IIS after an Office Server installation you'll see plenty of VDs for Sharepoint. Office Server configuration shows you a bazillion ports. Finally this afternoon it all came together with some help from the InfoPath team and, Office Zealot's own (okay pre-own but whatever), Charles Maxson.
1. Using IIS Manager find the default WSS VirtualDirectory (this may always be Sharepoint(80), I don't know... I have 4 other Sharepoint(port#) in IIS after a clean installation).
2. Create a new VD under that VD for your custom ASP.NET application.
3. In VS, you need to go to Website/Start Options and change the “Server“ option to “Use custom server“ and set the BaseURL to the VD you just made (i.e., “http://myservername/MyApplicationName“).
4. In Sharepoint Central Administration, upload your XSN then activate it on your root site (ie., “http://myservername“). I thought you had to create a site collection but you do not. Once you activate it on your root, the path to that XSN will be http://myservername/FormServerTemplates/MyFile.XSN
Now you've got both your custom ASP.NET application and your XSN in the same domain. Your XmlFormViewer.XsnLocation can be set to the XSN path above and it should work fine with a few minor problems, most importantly, to me anyway, the text in the “title“ row of my forms is mysteriously gone when the form renders and everytime I try to have it post to an HTTP I get some ambiguous wierd error.
Now to figure out how to actually get the post back data from the form. Hey, baby steps... baby steps.
Above is the image of the InfoPath form actually displaying in my application. I don't like how it adds that bar above even though I turned off the setting for having the toolbar on, it appears that just removes the buttons from the bar. In addition, I note how the bottom bar is longer than the top and the "powered by" is shorter still. Picky, I know, but will be important to making a clean application. This ASP.NET app uses Master Pages though and I love how the XmlFormViewer ties into that so the InfoPath forms looks like it is part of my application. Of course this form is much bigger when all the checkboxes are expanded with their pertinent options but that wouldn't have looked good on a blog now would it!