Last week I got an interesting question from a customer, apparently easy but something I really had never thought before…
They have some ASP.NET 1.1 applications running in their environment, while the new apps they are currently developing, are based on ASP.NET 2.0: from one of those new pages they need to post some form values to an ASP.NET 1.1 page (both running on the same Win2003 server but in different application pools, to avoid the limitation of having just one CLR version per process); they use cross-page postback through the PostBackPage property for the submit button to target the 1.1 page, but this throws an InvalidCastException on LoadPageViewState() (which I guess is expected since 1.1 and 2.0 Viewstates are encoded differently).
Question: is this scenario supported at all? How could this work? Well… it turns out that the ASP.NET 1.1 and 2.0 viewstate are encoded differently and are not compatible; moreover even if you set EnableViewState=”false” at page level this does not completely turns viewstate off, so every time you’ll execute the page you’ll get the InvalidCastException as before.
Based on customer’s requirements, we identified the following possible solutions:
- POST from a classic ASP or HTML page: of course, since there is no viewstate posted with the form, we also don’t get the exception
- From 2.0 POST to the same page (ASP.NET default, without using CrossPagePostback) and then do a server side Response.Redirect() to the target 1.1 page passing the parameters to the Query String. Unfortunately it’s not possible to use Server.Transfer() because this works only between pages in the same application (while here we had two separate applications). Using the query string is not the best approach if you need to pass sensitive values…
- If the target page does not need to rely on viewstate, override the LoadPageStateFromPersistenceMedium() method (we simply returned an empty object) so the posted viewstate will be ignored and we’ll not throw the InvalidCastException; this has the advantage to be a “standard” POST (we don’t use the query string) so the values are not passed in clear text
Probably I’m missing some other possible solutions, but the above (the latest point) at least fit the customer’s requirements…
Cheers