Migración de ASP.NET 1.1 a 4.0: eventos que no funcionan

Question

Recientemente he comenzado a migrar un proyecto de ASP.NET desde .NET versión 1.1 a 4.0. Este sistema actualmente se ejecuta en el sitio del cliente y funciona. Cuando migro la solución a través del asistente VS, no obtengo ningún error. El error es que no hay eventos de control del servidor y viewstate siempre está vacío.

He intentado establecer explícitamente ViewStateMode en habilitado y AutoEventWireup en true.Por desgracia, nada funciona. El proyecto no está escrito como una Aplicación Web (la conversión no resuelve el problema).

También compruebo si todos los controles del servidor tienen ID configurados (lo hacen).

El proyecto tiene su propio sistema de página maestra y hay una capa gruesa en System.Web.UI.Page que podría romper muchas cosas, pero hasta ahora no he podido encontrar la fuente de problemas.

¿Hay alguna configuración particular que deba verificar (es decir, los valores predeterminados modificados desde .NET 1.1) o me puede dar algunos consejos sobre por qué podría suceder esto?

EDIT 1: Estos son los valores que llegan a ser destinadas al hacer clic en un LinkButton:

CRC = -2134936892 & _ EventTarget = mpage% 24BC% 24TestButton & _EVENTARGUMENT = & _ VIEWSTATE = & _EVENTVALIDATION =% 2FwEWAwL% 2BraDpAgLB49K8A wKy8rFAt4Axk3NlUEWxrtY% 2FRtaexH% 2F634CkJe6G9Im5EOPXtVw% 3D

EDIT 2: He examinado el mecanismo de la página maestra personalizada de cerca y me encontré con que hace un amplio uso de Server.Transfer(...) método antes de saltar a la página correcta. ¿Es esta una posible causa del ViewState faltante? (Entonces sería extraño que EventTarget siempre se mantenga) Y lo más importante, ¿podría haber habido algún cambio entre 1.1 y 4.0?

Answer 1

Esto puede o no puede resolver el problema, pero si revisa esta publicación en la pila Why is the form action attribute empty on production server? habla de un cambio radical introducido en ASP.NET 3.5 sp1 centrado en el atributo de acción del formulario - podría ser un lugar para ¡comienzo!

He tenido que hacer cosas similares en el pasado y puede ser un proceso arduo, especialmente cuando tienes la funcionalidad de "página maestra personalizada" (he tenido que hacer lo mismo). Elegiría una página realmente básica: teníamos una BasePage heredada por una página personalizada, que podría ser heredada por AdminBasePage y luego por la página de administración, etc. Si seleccionas una página relativamente simple y estableces un punto de ruptura tan pronto como en el proceso de construcción de página como sea posible y luego solo F10 hasta que muestre que puede mostrar dónde se llaman dos veces (esto sucedió mucho en nuestro caso y fue la causa de algunos problemas con valores sobrescritos, etc.).

En respuesta a su pregunta server.transfer "Editar 2" encontré este recurso http://www.codeproject.com/Tips/74472/ViewState-and-Server-Transfer-Best-practices que explica cómo asegurar (con suerte) que viewstate y server.transfer continúen trabajando en armonía. Sigo recurriendo a esta pregunta todos los días: deje caer más actualizaciones sobre cómo se pone. ¡Tienes mi más profunda simpatía!

Answer 2

Una vez que migra es completa,

Si se trata de una aplicación web:

Aquí está una lista de comprobación:

1. trate de cambiar los valores de los controles de servidor .NET en modo de diseño en Visual Studio 2010. (desde su framework 4.0, usará visual studio 2010) Cambiarlo incluye: cambiar el tamaño de un control de servidor , o cualquier otra propiedad. Esto obligará al diseñador a generar código de diseñador del lado del servidor.

2. Asegúrese de limpiar la solución y reconstruirla. Solía ​​tener problemas similares y solían corregirse después de cambiar el diseño del diseñador, ocasionalmente daba errores. No dio errores durante la migración.

3. Guarde el formulario y pruébelo.

4. Compruebe con Firebug en Firefox si hay errores de script de JavaScript al cargar la página web.

   Espero que esto sea útil.

Answer 3

¿Ha revisado este enlace? http://www.asp.net/whitepapers/aspnet4/breaking-changes

más profundo en la página se afirma que, cuando la acción FORM 's está vacía, ocurre lo siguiente:

1. una página .aspx se envía al navegador con atributo de acción del elemento de la forma establecida en " ".
2. El formulario se publica en ASP.NET.
3. Un módulo HTTP gestionado lee alguna parte del cuerpo de la entidad. Por ejemplo, un módulo lee Request.Form o Request.Params. Esto hace que el cuerpo de entidad de la solicitud POST se lea en la memoria administrada. Como resultado, el cuerpo de entidad ya no está disponible para ningún módulo de código nativo que se ejecute en el modo integrado IIS 7 o IIS 7.5.
4. El objeto IIS DefaultDocumentModule finalmente se ejecuta y crea una solicitud secundaria para el documento Default.aspx. Sin embargo, dado que el cuerpo de la entidad ya ha sido leído por una parte del código administrado, no existe un cuerpo de entidad disponible para enviar a la solicitud del niño.
5. Cuando la interconexión HTTP se ejecuta para la solicitud secundaria, el controlador para archivos .aspx se ejecuta durante la fase de ejecución del controlador.
6. Como no hay cuerpo de entidad, no hay variables de formulario ni estado de vista, y por lo tanto no hay información disponible para que el manejador de página .aspx determine qué evento (si lo hay) se debe generar. Como resultado, no se ejecuta ninguno de los controladores de eventos de devolución de la página .aspx afectada. Puede solucionar este comportamiento de las siguientes maneras:

EDIT: Llevamos a cabo en un problema similar cuando se migra a 3,5 hace dos años ... y lo que hicimos fue utilizar VS2005 con el tipo de proyecto de aplicación web como un puente, por lo que nuestra ruta de migración fue:

• 1.1 a 2.0
• 2.0 a 3,5

Este fue nuestro último recurso, y que fue antes de descubrir este documento.