Share via

Forms Services and multiple IIS Web Applications

  • Article

We often get questions asking if the XmlFormView control can be used in a particular environment. Usually you will use it on a regular page that belongs to a WSS Site or on a page in _layouts folder of a WSS site. These scenarios are supported and covered in the following MSDN article on the XmlFormView control at http://msdn2.microsoft.com/en-us/library/ms778201.aspx. If you want to create an IIS application inside of your WSS site, hosting XmlFormView on the pages of this site is not supported (and actually does not work properly).

How you can get into this unsupported state

In Visual Studio, you create New -> ”Web Site” inside http://myWSSserver/_layouts. Then follow the steps to host an XmlFormView control on one of the pages. You add a SubmitToHost handler to the XmlFormView control on your hosting page. When viewing the form, everything seems to be working fine until a post back to the host happens. You either get no results or the “submitted successfully” dialog without your hosted page’s handler called.

Why it does not work (so you don’t try to use XmlFormView in this way)

Here are two things that contribute to the issue:

1. XmlFormView control uses a helper page which is located in the _layouts folder. This page handles AJAX post backs from the control. Every post back that the control makes by itself will be handled by that page. This page can also request that the hosting page performs a full page post back (i.e. for Submit to host). In this case, the Form Services code in the browser will call submit on the page which will then be directed to the original hosting page code for processing.

2. Forms Services uses the ASP.Net session state to store all of the information about the current document. The ASP.Net session state data is not shared across IIS applications even if the ASP.Net session cookies are the same.

Let’s combine these two facts with the fact that the “Web Site” that you just create under _layouts is in a different IIS web application than _layouts itself. You have the main page (i.e. _layouts/myWebSite/MyHostingPage.aspx) in one IIS web application but the Forms Services’ post back page (_layouts/postback.aspx) is in a different (default WSS) application.

From reason 1 above, we can see that most of requests will go to the _layouts/postback.aspx page. Based on reason 2, we will get one Session State data blob for all post backs going to the postback.aspx page (since it goes to the same application). This Session State data blob will contain information about the document you are editing including all changes you are making in the browser.

When the request needs to go to the hosting page (i.e. when the post back page detects a call to the SubmitToHost handler) then another Session State data blob will be created for these requests (even if they share an ASP.Net session cookie, the request goes to a different application). This new Session State data blob does not have information about the document that was created and edited during the calls to postback.aspx.

At this point, there are two unrelated Session State data blobs which are holding data about part of your editing session. As you can guess, neither of them contains complete information. Depending on what pieces of editing went to each copy of your Session State data blobs, you can get unexpected behavior after the post back. Often the Forms Services’ code will detect a complete mismatch between the data in the Session State and the information from the browser. It will end up starting a new document to get to a consistent state.

How to fix it

Note that the steps below will change your site from living in a separate application to sharing the same application as WSS. Pease make sure that you understand effect of this change (and check if you need a separate application in the first place).

1. Run IIS Manager (i.e. Start->Run->inetmgr).
2. In the IIS Manager, chose the web site (in the left pane) where you created the web site in Visual Studio (shown in figure 1).
3. Right click on the selected web site, choose “Properties”, and on the “Virtual Directory” tab, click the “Remove” button next to “Application name” (shown in figure 3).

Following image highlights what icon you should see next to supported (green) and unsupported (red) folders:

Setting on Property page for the folder where hosting of XmlFormView will work properly:

Here is sample of properties where hosting will be broken. Click Remove button to fix it. Again, note that you need to understand effect of it for your application:

Alexei Levenkov, Nicholas Lovell, and Balbir Singh
Software Design Engineers

Comments