ASP.NET 1.1 to 4.0 migration: events not working

Question

I've recently begun migrating an ASP.NET project from .NET version 1.1 to 4.0. This system currently runs on customer site and works. When I migrate the solution via the VS wizard, I don't get any errors. The error is that no server control events work and the viewstate is always empty.

I've tried explicitly setting ViewStateMode to Enabled and AutoEventWireup to true.Unfortunately nothing works. The project is not written as a Web Application (converting does not solve the problem).

I've also check whether all server controls hav IDs set (they do).

The project has its own master page system and there is a thick layer upon System.Web.UI.Page that might break a lot of things, but so far I haven't been able to find the source of trouble.

Is there any particular setting that I should check (i.e. the default values changed since .NET 1.1) or can you give me some tips why this might happen?

EDIT 1: These are the values that get posted when clicking on a LinkButton:

CRC=-2134936892&_EVENTTARGET=MPage%24BC%24TestButton&_EVENTARGUMENT=&_VIEWSTATE=&_EVENTVALIDATION=%2FwEWAwL%2BraDpAgLB49K8AwKy8rFAt4Axk3NlUEWxrtY%2FRtaexH%2F634CkJe6G9Im5EOPXtVw%3D

EDIT 2: I've examined the custom master page mechanism closely and I found that it makes extensive use of Server.Transfer(...) method before jumping to the right page. Is this a possible cause of the missing ViewState? (then it would be strange that the EventTarget is always persisted) And more importantly, could there have been any change between 1.1 and 4.0?

Answer 1

Did you check this link? http://www.asp.net/whitepapers/aspnet4/breaking-changes

Deeper in the page it is stated that, when FORM's action is empty, the following happens:

1. An .aspx page is sent to the browser with the form element’s action attribute set to "".
2. The form is posted back to ASP.NET.
3. A managed HTTP module reads some part of the entity body. For example, a module reads Request.Form or Request.Params. This causes the entity body of the POST request to be read into managed memory. As a result, the entity body is no longer available to any native code modules that are running in IIS 7 or IIS 7.5 Integrated mode.
4. The IIS DefaultDocumentModule object eventually runs and creates a child request to the Default.aspx document. However, because the entity body has already been read by a piece of managed code, there is no entity body available to send to the child request.
5. When the HTTP pipeline runs for the child request, the handler for .aspx files runs during the handler-execute phase.
6. Because there is no entity body, there are no form variables and no view state, and therefore no information is available for the .aspx page handler to determine what event (if any) is supposed to be raised. As a result, none of the postback event handlers for the affected .aspx page run. You can work around this behavior in the following ways:

EDIT: We run on a similar issue when migrating to 3.5 two years ago... and what we did was to use VS2005 with Web App project type as a bridge, so our migration path was:

• 1.1 to 2.0
• 2.0 to 3.5

This was our last resort, and that was before finding out this document.

Answer 2

This may or may not solve the problem but if you check out this post on stack Why is the form action attribute empty on production server? it talks about a breaking change introduced in ASP.NET 3.5 sp1 centred around the action attribute of the form - it could be a place to start!

I've had to do similar things in the past and it can be a painstaking process especially when you have "custom masterpage" functionality (I've had to do the same). I'd pick a really basic page - we had a BasePage which was in herited by a CustomPage which inturn could be inherited by AdminBasePage and then Admin page etc. If you pick a relatively simple page and set a break point as early on in the process of page construction as possible and then just F10 all the way through until it renders it may show where things are being called twice (this happened a lot in our case and was the cause of some issues with values being overwrriteen etc).

In response to your server.transfer question "Edit 2" I found this resource http://www.codeproject.com/Tips/74472/ViewState-and-Server-Transfer-Best-practices which explains how to ensure (hopefully) that viewstate and server.transfer continue to work in harmony. I keep popping back to this question every day - do drop more updates as to how your getting on. You have my deepest sympathy!

Answer 3

Once migrating is complete,

If it is a web application:

Here is a checklist :

1. Try changing the values of .NET server controls in Design Mode in Visual Studio 2010. (since its framework 4.0, you will be using visual studio 2010) Changing it includes: changing the size of a server control, or any other properties. This will force the designer to generate server sided designer code.

2. Make sure you clean the solution and rebuild it. I used to have similar problems and they used to be fixed after changing the design from the designer, would occasionally give errors. It didn't give errors during migration.

3. Save the form and test it.

4. Check using Firebug in Firefox whether there are any javascript script errors when you load the webpage.

   Hope this would be helpful.