Migración de aplicaciones

Migre sus aplicaciones ASP.NET 1.1 a Visual Studio 2010

Jonathan Waldman

Si ha trabajado con ASP.NET varios años, es posible que haya escrito soluciones con Visual Studio 2003 para Microsoft .NET Framework 1.1. En los últimos años, han debutado versiones de .NET Framework 2.0, 3.0 y 3.5 más recientes y con múltiples funciones, y probablemente se pregunte si valdría la pena o si sería factible actualizar sus aplicaciones confiables de Framework 1.1 a una de ellas.

En la actualidad, a medida que desarrolladores de todo el mundo adoptan el nuevo .NET Framework 4, es posible que se sienta más atraído que nunca a considerar seriamente la posibilidad de realizar una migración. Si decide hacerlo, tenga la seguridad de que Microsoft ha proporcionado herramientas útiles para facilitar la realización de ese tipo de proyectos, lo que resulta en aplicaciones ASP.NET modernizadas que pueden aprovechar las innovaciones más recientes de .NET Framework. Específicamente, mostraré cómo intensificar las soluciones de ASP.NET 1.1 al migrarlas a Visual Studio 2010 (Professional, Premium o Ultimate), lo que les permite destinarlas a las versiones 2.0, 3.0, 3.5 ó 4 de .NET Framework.

¿Por qué migrar?

Incluso si su objetivo es simplemente mantener sus sitios de ASP.NET 1.1, sus opciones de compatibilidad y extensibilidad disminuyen. Como desarrollador de 1.1, debe preocuparse de que Microsoft retiró el soporte estándar de Visual Studio 2003 el 14 de octubre de 2008, y ha declarado que no emitirá más Service Pack para Visual Studio 2003 o para .NET Framework 1.1. (Sin embargo, Microsoft ofrece soporte extendido para Visual Studio 2003 hasta el 8 de octubre de 2013).

Sin embargo, debe estar muy alarmado debido a que un número creciente de proveedores de terceros han dejado de ofrecer o entregar compatibilidad a componentes que se pueden ejecutar en .NET Framework o que amplíen el IDE de Visual Studio 2003. En efecto, las aplicaciones web de .NET Framework 1.1 y el IDE de Visual Studio 2003 se están aislando y están cayendo en el olvido.

 Y abundan otras razones. Ha habido tantas mejoras en los lenguajes de programación .NET Framework, C# y Visual Basic .NET y en el IDE de Visual Studio que la migración de sus sitios de .NET 1.1 a .NET 2.0 o superior (a los que en lo sucesivo, nos referiremos como 2.0+) finalmente le permitiría mejorarlos con las herramientas y tecnologías más recientes, así como también todas las características modernas de lenguaje y Framework (como páginas maestras, AJAX, Windows Communication Foundation [WCF], Silverlight, LINQ, clases parciales, genéricos, expresiones lambda y métodos anónimos) que los desarrolladores .NET líderes ya adoptaron. En general, mientras más reciente sea la versión de Framework que elija para destinar su aplicación de ASP.NET, mayor potencial y poder tendrá a su alcance. También podría encontrar soporte técnico sólido no sólo desde Microsoft (en el momento de la redacción de este artículo, Microsoft ofrece soporte estándar para todas las versiones de Framework 2.0+), sino que también dentro de foros activos para desarrolladores y mediante proveedores de herramientas de terceros. También hay libros disponibles para muchos usuarios que abarcan todos los aspectos de las tecnologías más recientes, además de muchos sitios que ofrecen cursos basados en vídeo, blogs, notas de productos y otras opciones de aprendizaje.

 El IDE de Visual Studio 2010 más reciente y moderno es prácticamente por sí mismo una justificación para realizar la migración. Está muy por delante del IDE de Visual Studio 2003, es compatible con características nuevas como IntelliTrace y se puede ampliar con una variedad de potentes complementos de terceros que prácticamente garantizan nuevos niveles de productividad de la programación. A pesar de que unos pocos usuarios deberán seguir usando versiones anteriores de Visual Studio por diversos motivos, Visual Studio 2010 hace que la ejecución de instalaciones en paralelo de Visual Studio 2005 y Visual Studio 2008 sea prácticamente innecesaria, puesto que Visual Studio 2010 puede apuntar a las versiones 2.0+ de Framework. Incluso así, tal como Visual Studio
2005 y Visual Studio 2008, Visual Studio 2010 no puede apuntar a la versión 1.1 de Framework. Esto significa que tendrá que seguir ejecutando Visual Studio 2003, o bien, que tendrá que migrar su proyecto de ASP.NET 1.1 a una versión más reciente de Framework.

Finalmente, los desarrolladores que sólo tienen experiencia en la versión 1.1 de Framework no son tan comercializables como los que tienen experiencia en versiones 2.0+ de Framework. La competencia por ocupar puestos de desarrolladores es alta, por lo que desea obtener cualquier ventaja posible; aprovechar las características de Framework más recientes en su código mejorará su candidatura y su credibilidad como desarrollador de software profesional.

Problemas de migración

¿Por qué nadie ha migrado todavía desde ASP.NET 1.1 durante ninguno de los lanzamientos importantes de Visual Studio y .NET Framework desde Visual Studio 2003? Una razón es que los desarrolladores deberían implementar la opción de migración ASP.NET 1.1 a ASP.NET 2.0 que ofrecía Visual Studio 2005. No suena tan mal, pero tenga en cuenta que cuando se implementó por primera vez Visual Studio 2005 se requería convertir un proyecto de ASP.NET en un tipo de proyecto web moderno. Esto significaba que la arquitectura misma en que se basaba un sitio de ASP.NET 1.1 debía cambiarse minuciosamente y la regresión se debía probar con rigurosidad. Muchos desarrolladores consideraron que este proceso equivalía a volver a escribir el sitio desde el comienzo, lo que presentaba un desafío técnico y de costos considerado insuperable. Como resultado, los responsables de la toma de decisiones a menudo dejaron los sitios de ASP.NET 1.1 tal como eran.

Para apreciar mejor este desafío de aplicación de ASP.NET 1.1 a ASP.NET 2.0, es importante comprender que todos los proyectos web de ASP.NET 1.1 se organizan con una configuración de archivo-carpeta determinada por proyecto. Este tipo de proyecto se llamaba originalmente “el modelo de proyecto web 2003” y ahora se conoce como Proyecto de aplicación web (WAP). Cuando se lanzó Visual Studio 2005, Microsoft introdujo un nuevo tipo de proyecto determinado por carpeta que estaba diseñado para .NET Framework 2.0. Este tipo de proyecto se llamaba originalmente “el modelo de proyecto web 2005” y ahora se conoce como Proyecto de sitio web (WSP). (¿Está confundido? Use el simple truco de recordar los acrónimos en orden alfabético: WAP viene antes de WSP, tal como Visual Studio 2003 viene antes de Visual Studio 2005).

Como un análisis profundo de los WAP y los WSP se encuentra fuera del ámbito de este artículo, basta decir que la idea original de Microsoft era que todas las aplicaciones web 1.1 migradas se convirtieran en WSP a través del Asistente para la conversión incluido. Los desarrolladores, preocupados, protestaron inmediatamente puesto que el tipo de proyecto WAP original ofrecía ventajas técnicas y de rendimiento específicas que no aparecía en el tipo de proyecto WSP más reciente. Siguió rápidamente un furor en la comunidad para desarrolladores de ASP.NET cuando los desarrolladores, administradores y partes interesadas supieron que Microsoft sólo había proporcionado una opción de migración de un WAP de ASP.NET 1.1 a un WSP de ASP.NET 2.0, la que demostró ser lenta y costosa, especialmente para los sitios con algún grado de complejidad. Detallar los problemas técnicas que surgen de dicha migración significaría redactar un artículo separado de varias partes; puede obtener más información si lee el artículo de MSDN Library “Common Web Project Conversion Issues and Solutions”(Problemas comunes en la conversión de proyectos web y sus soluciones) (msdn.microsoft.com/library/aa479312).

Afortunadamente, Microsoft respondió con rapidez y pronto ofreció un Asistente para la conversión revisado en Visual Studio 2005 SP1. En esta ocasión, el Asistente para la conversión convertía un WAP de ASP.NET 1.1 en un WAP de ASP.NET 2.0. Aún así, muchos desarrolladores no se enteraron de esta opción de migración y, por lo tanto, nunca la investigaron. En Visual Studio 2010, el Asistente para la conversión convierte un WAP de ASP.NET 1.1 a un WAP de ASP.NET 2.0+ (2.0+ se refiere al hecho de que, una vez convertido, puede apuntar a 2.0, 3.0, 3.5 ó 4), lo que sigue dando la oportunidad de migrar aplicaciones web más antiguas. (No es posible convertir una aplicación de ASP.NET 1.1 en una aplicación de WSP, ni tampoco querría hacerlo, con el Asistente para la conversión de Visual Studio 2010; necesitaría obtener acceso al Asistente para la conversión que se proporcionó en Visual Studio original lanzado antes de SP1).

Puede resultar interesante saber que cada vez que comienza un proyecto nuevo en Visual Studio 2010, puede elegir si desea crear un WAP o un WSP. Microsoft prometió ofrecer compatibilidad con WAP y WSP en todas las versiones actuales y futuras de .NET Framework.

El proceso

La migración de las aplicaciones de ASP.NET 1.1 con Visual Studio 2010 consta de los siguientes pasos generales (analizaré cada uno en mayor detalle):

• Ejecute el Asistente para la conversión.
• Defina el marco de destino y la página de inicio.
• Compile y corrija.
• Convierta las páginas y los controles de usuario en clases parciales.
• Compile y corrija.

Ejecute el Asistente para la conversión Para usar el Asistente para la conversión en una conversión de WAP 1.1 a WAP 2.0+ (nuestro objetivo), debe instalar la opción Visual Web Developer durante la instalación de Visual Studio 2010. Si no lo hizo, necesita agregarla ejecutando nuevamente la instalación de Visual Studio 2010 y usando su opción Cambiar o quitar Microsoft Visual Studio 2010; luego elija Agregar o quitar características y asegúrese de que la característica Visual Web Developer esté marcada (vea la figura 1).

Figura 1 Asegúrese de que el componente Visual Web Developer esté instalado antes de iniciar el Asistente para la conversión

Si Visual Web Developer no está instalado, el Asistente para la conversión se sigue iniciando y se ejecuta. Podrá convertir todos los proyectos de su solución, excepto su proyecto web. Indicará que debe instalar Visual Web Developer para poder convertir el proyecto web.

Antes de realizar una conversión, es recomendable asegurarse de que la aplicación no sólo se compile y se ejecute, sino que también esté lo más limpia y organizada posible. Por lo tanto:

1. Limpie la aplicación quitando todos los archivos no usados e innecesarios, con lo que la aplicación web se reduce a sus componentes esenciales.
2. Asegúrese de que cada proyecto de la solución se compile sin errores en tiempo de compilación.
3. A pesar de que recomiendo que agregue su solución al control de código fuente si todavía no se configura, compruebe que no se haya desprotegido ningún archivo exclusivamente desde el repositorio. Tener la solución bajo control de código fuente permitirá examinar cambios específicos hechos por el asistente una vez finalizado el proceso de conversión.
4. Asegúrese de que no haya archivos ni carpetas fuera del control de código fuente marcados como de sólo lectura. Esto permite que el asistente actualice esos archivos o carpetas según sea necesario.
5. Cree una copia de seguridad. Si ejecuta la solución en una máquina virtual, es mejor simplemente crear una copia de seguridad de la máquina virtual completa (o crear una instantánea de ella). De lo contrario, cree una copia de seguridad de toda la aplicación, incluidas todas las dependencias. Si no está seguro acerca de las dependencias, un buen lugar para mirar es el archivo de solución (.sln) de la aplicación, así como también los archivos individuales del proyecto (.proj). Son archivos de texto que se pueden inspeccionar de manera visual. Muchas soluciones de ASP.NET contienen proyectos que apuntan a ubicaciones de red o a carpetas fuera de las carpetas de la aplicación o raíz web. No crear copias de seguridad de estas dependencias puede provocar enormes complicaciones cuando desee restaurar la aplicación desde los archivos de copia de seguridad. Tenga en cuenta que el proceso completo de la migración realiza cambios en cada proyecto de la aplicación, por lo que comprender las dependencias de su aplicación antes de comenzar representa una ventaja. Además, si usa proyectos que se comparten entre varias aplicaciones de ASP.NET 1.1, tenga en cuenta que una vez que se hayan migrado estas soluciones, ya no se podrán abrir en Visual Studio 2003. Si trabaja en un entorno de trabajo en equipo, hacer cambios en proyectos compartidos también afectará las soluciones de los miembros del equipo, lo que podría hacer referencia a los proyectos convertidos. De esta manera, ya sean compartidos entre proyectos o equipos, debe desacoplar los proyectos compartidos creando copias de ellos y asegurándose de que exista una copia local en su estación de trabajo de desarrollo. El archivo de solución cambiará si mueve un proyecto (por ejemplo, para desacoplarlo), por lo que quizás desee crear una copia de seguridad del archivo de la solución antes de hacer cambios en cualquiera de los proyectos a los que hace referencia, y luego volver a crear una copia de seguridad una vez que las dependencias del proyecto se hayan desacoplado correctamente, pero antes de ejecutar el Asistente para la conversión. Finalmente, es posible que detecte errores en sus archivos originales de la solución una vez finalizado el proceso de conversión; tener una copia de seguridad útil de la solución previa a la conversión le facilitará el proceso de volver y corregir esos errores antes de volver a ejecutar el Asistente para la conversión.
6. Considere configurar un entorno paralelo: Visual Studio 2003 y Visual Studio 2010 pueden ejecutarse en paralelo en la misma máquina, por lo que puede ejecutar su sitio de ASP.NET 1.1 junto con su sitio de ASP.NET 2.0+. Con esto será más fácil realizar pruebas de control de calidad posteriores a la migración.

Para iniciar el asistente, abra su archivo de la solución Visual Studio 2003 con la opción de menú Archivo, Abrir, Proyecto/Solución en Visual Studio 2010. Pronto verá el diálogo de introducción al Asistente para la conversión de Visual Studio (consulte la figura 2). Haga clic en Siguiente.

Figura 2 El diálogo de introducción del Asistente para la conversión de Visual Studio

El Asistente para la conversión puede identificar problemas mientras se procesa y es posible que desee restaurar la solución desde una copia de seguridad, hacer algunos cambios y volver a comenzar el proceso desde cero. Este paso hace que sea más fácil crear una copia de seguridad (consulte la figura 3), aunque ubica todas las dependencias de su solución dentro de la carpeta de copia de seguridad que especifica, lo que significa que, a fin de realizar la restauración correctamente, debe estar completamente seguro de saber la disposición original de todas esas carpetas de copia de seguridad.

Figura 3 El Asistente para la conversión le brinda la oportunidad de crear una copia de seguridad antes de continuar

Por lo tanto, para crear una copia de seguridad de la solución en este paso, simplemente proporcione una ruta de carpetas y el asistente creará una carpeta secundaria llamada Copia de seguridad en la que colocará los archivos de la solución. Se creará una copia de seguridad de cada proyecto de la solución en una subcarpeta correspondiente dentro de la carpeta Copia de seguridad, incluso si se origina fuera de la raíz de la solución original; por lo tanto, y para que la copia de seguridad se realice correctamente, es importante asegurarse de que los nombres de proyecto son únicos en toda la solución. Haga clic en Siguiente.

Ahora verá un cuadro de diálogo final con un aviso respecto del control de código fuente y de los permisos de lectura/escritura (consulte la figura 4).

Figura 4 El Asistente para la conversión le avisa antes de permitirle continuar

Si eligió crear una copia de seguridad, verá el tipo de copia de seguridad y la ubicación en que se van a escribir los archivos de copia de seguridad. Verá un resumen del nombre de la solución convertido junto con todos sus proyectos. Si todo se ve preciso y aceptable, haga clic en Finalizar.

Ahora es posible que se le soliciten credenciales de inicio de sesión para el repositorio de control de código fuente (como Visual SourceSafe) para poder comprobar el proyecto.

Verá una barra de progreso a medida que se convierte cada proyecto de la solución. El proceso puede demorar varios minutos, puesto que el asistente itera entre los proyectos de la solución.

El Asistente para la conversión muestra un mensaje que explica que finalizó el primer paso y que ahora es necesario convertir la aplicación web (vea la figura 5).

Figura 5 El Asistente para la conversión le permite saber que necesitará convertir el proyecto web para así finalizar la migración

Luego le alerta respecto de la finalización de su proceso inicial (consulte la figura 6).

Figura 6 El Asistente para la conversión le alerta cuando la conversión finaliza

Puede revisar el registro de conversión con la plantilla Informe de conversión. Este archivo, llamado Upgrade¬Log.XML, se coloca en la misma carpeta que el archivo .sln de la solución. El registro de la actualización muestra los archivos del proyecto que se convirtieron y despliega cualquier error y mensaje de advertencia importante. También proporciona comentarios útiles, además de comentarios relativos a la versión de Framework a la que apunta cada proyecto. Incluí un extracto de este informe en la figura 7.

Figura 7 El registro de la conversión muestra detalles acerca de la aplicación web convertida

Se deben revisar todas las advertencias y todos los errores. Las advertencias (como un cambio en la ruta relativa de una ruta de copia de seguridad) normalmente tienen que ver con dudas técnicas pequeñas que, por lo general, no requiere una acción adicional para que pueda compilar correctamente la solución convertida. Sin embargo, los mensajes de error (como la referencia a un archivo faltante) deben ser revisados cuidadosamente y se deben realizar las acciones correspondientes, puesto que normalmente implican problemas que no le permitirán compilar correctamente su solución convertida. Si tiene muchos errores, el registro de conversión realiza un buen trabajo al articular el tipo de acción que debe realizar y, por lo general, puede encontrar gran cantidad de ayuda adicional en los archivos de ayuda de Visual Studio 2010 o en diversos sitios web técnicos. En algunos casos, es posible que considere mejor tomar nota de los errores que aparecen en el registro de conversión y abordarlos en los archivos de proyecto Visual Studio 2003 originales en lugar de hacerlo en la solución convertida (y es en este punto en que la copia de seguridad que realizó demuestra ser útil). Siempre tiene la posibilidad de volver a ejecutar el Asistente para la conversión en su solución Visual Studio 2003 modificada.

Una vez que haya revisado todas las advertencias y que haya solucionado todos los errores, puede descartar las pantallas finales del Asistente para la conversión. El Asistente para la conversión ha finalizado sus tareas. El archivo de la solución (.sln) y sus archivos de proyecto (.proj) ahora están en formato de Visual Studio 2010. Sin embargo, todavía tiene algo de trabajo por delante antes de finalizar la migración.

Defina el marco de destino y la página de inicio Cuando finaliza el Asistente para la conversión, habrá configurado el proyecto web de Visual Studio para que se ejecute en .NET Framework 4, a la vez que define los otros proyectos de su solución para que se ejecuten en .NET Framework 2.0. A pesar de que es aceptable combinar y asociar versiones de marco, recomiendo usar un destino de marco único para todos los proyectos de la solución, a menos que la empresa de alojamiento web o la infraestructura de su organización impongan restricciones. (Visual Studio 2010 modifica su conjunto de características de IDE según el marco de destino vigente para el proyecto activo. Si los proyectos apuntan a distintas versiones de marco, es posible que encuentre que el comportamiento del IDE sea confuso cuando cambia entre los proyectos. Tener todos los proyectos en la misma versión de marco permite que el IDE presente una interfaz coherente entre todos los proyectos, y además le permite programar en un marco coherente).

Si desea cambiar el marco de destino para cualquier de sus proyectos convertidos, simplemente haga clic con el botón secundario en la raíz del proyecto en Explorador de soluciones y seleccione Propiedades. En la página de configuración que aparece (consulte la figura 8), seleccione la pestaña Aplicación y cambie el Marco de destino a cualquiera de los valores de Framework 2.0+.

Figura 8 Cambie el marco de destino de cualquier proyecto a 2.0, 3.0, 3.5 ó 4

Finalmente, defina la página de inicio para el proyecto web. Para hacerlo, encuentre la página en el Explorador de soluciones, haga clic en ella con el botón secundario y seleccione la opción Definir como página de inicio.

Compile y corrija Ahora que los archivos de la solución y del proyecto se actualizaron al formato de Visual Studio 2010, su WAP de ASP.NET 2.0+ está listo para compilación. Para forzar la creación de todos los proyectos de la solución, recomiendo compilar dentro de Visual Studio 2010 con la opción de menú Generar, volver a generar solución. Después de la regeneración, puede ver cualquier problema de generación si muestra la ventana Lista de errores (puede desplegarla si selecciona el menú Ver y la opción Lista de errores). La ventana Lista de errores muestra errores, advertencias y mensajes (puede especificar cuáles de estos ver en la ventana si activa los correspondientes botones de Errores, Advertencias y Mensajes). Visual Studio 2010 normalmente ofrece instrucciones claras sobre cómo resolver los elementos de la ventana Lista de errores. Si no entiende el texto del error, advertencia o mensaje, sólo seleccione la línea de la ventana Lista de errores que contiene el aviso y presione <F1>. Aparecerá una ventana de ayuda con información más detallada sobre el problema (si no instaló la ayuda local, puede conectarse a Internet para verla). De todos modos, la mayoría de los errores que vea tendrá que ver con cambios en el marco que provocan conflictos de nombres con su propio código. Normalmente puede resolverlos si califica completamente sus referencias con un espacio de nombres. Y la mayoría de las advertencias tienen que ver con miembros obsoletos. A pesar de que todavía puede usar miembros obsoletos, debe saber que probablemente no sean compatibles con la versión siguiente superior de .NET Framework. Si ve miembros obsoletos y apunta al marco 2.0, probablemente no podrá usar ese miembro cuando decida apuntar a un marco 3.x o 4.

Prepárese para dedicar algo de tiempo para solucionar estos problemas de la ventana Lista de errores. Debe poder solucionar todos los errores y la mayoría, si no todas, de las advertencias antes de realizar los próximos pasos.

Convierta las páginas y los controles de usuario en clases parciales El paso siguiente implica la ejecución de un comando Convertir en aplicación web (en lo sucesivo, CWA). A pesar de que puede ejecutar este comando sobre una página o un control de usuario individual para saber el
tipo de cambio que realiza, es más rápido ejecutarlo sobre toda la solución. Para ello, haga clic con el botón secundario en el nodo Solución en Explorador de soluciones y seleccione Convertir en aplicación web. Este proceso hace lo siguiente:

1. Implementa clases parciales al agregar un nuevo documentos de “diseñador” para páginas y control de usuario.
2. Define AutoEventWireup para páginas y control de usuario.
3. Agrega controladores de eventos declarativos para cada control sobre páginas y controles de usuario.

Las aplicaciones de ASP.NET 1.1 tienen módulos de código subyacente (aspx.cs y ascx.cs para C# y aspx.vb y ascx.vb para Visual Basic .NET) que contienen código de autoría de desarrolladores y generado por diseñador de formularios web. Cuando crea páginas o controles de usuario en Visual Studio 2003 y les agrega controles con el diseñador del formulario web, el IDE agrega campos de instancia protegida a los módulos de código subyacente para que pueda hacer referencia a esos controles agregados. Después de ejecutar el comando CWA, aparece un documento de diseñador para cada página y control de usuario (el Explorador de soluciones muestra este archivo únicamente cuando la opción Mostrar todos los archivos está habilitada). Observará que los nombres de archivo de diseñador son iguales a la página o al control de usuario junto con una extensión de designer.cs (C#) o designer.vb (Visual Basic .NET).

Por ejemplo, si tiene una página llamada MyPage.aspx en C#, habrá un documento nuevo llamado MyPage.aspx.designer.cs. Este documento de diseñador contiene campos de instancia protegida que estaban en su módulo de código subyacente. Esos campos cambiaron al módulo de diseñador, por lo tanto, ya no se combinan con su propio código. Esto es posible debido a que los módulos de diseñador son clases parciales, lo que significa que el comando CWA también convierte el código del código subyacente para la página o el control de usuario correspondiente en una clase parcial.

Por ejemplo, los campos de instancia en C# y Visual Basic .NET aparecen en los documentos de código subyacente de los proyectos de Visual Studio 2003 de la siguiente manera:

[VB]
Protected WithEvents MyButton As System.Web.UI.WebControls.Button

[C#]
protected System.Web.UI.WebControls.Button MyButton;
The CWA command moves each to a corresponding designer file:
[VB]
Protected WithEvents MyButton As Global.System.Web.UI.WebControls.Button

[C#]
protected global::System.Web.UI.WebControls.Button MyButton;

(global:: indica que la búsqueda de espacio de nombres System debe comenzar en el nivel de espacio de nombres global y así se asegura de que el espacio de nombres System del marco no estará oculto por su propio espacio de nombre System).

La creación del archivo de diseñador es dinámica y se puede volver a generar en cualquier momento. De esta manera, puede eliminar sin riesgos el documento designer.cs o designer.vb y volver a generarlo (o restaurarlo si falta) simplemente con un clic con el botón secundario en el nodo de página o de control de usuario en el Explorador de soluciones y volviendo a ejecutar el comando CWA sobre él. El comando CWA detecta los controles de servidor en el marcado HTML de una página o un control de usuario y genera las variables de instancia necesarias en el archivo de clase parcial del diseñador. Luego quita cualquier variable de instancia que siga apareciendo en su propio archivo de código subyacente (aspx.cs, ascx.cs, aspx.vb o ascx.vb).

Las clases parciales permiten que el código fuente de una clase, estructura o interfaz se escriba en dos o más archivos físicos dentro de un espacio de nombres. Más adelante, el compilador une estas definiciones parciales para formar una declaración única de cada tipo. Mientras las clases parciales siguen siendo el mecanismo de facto que Visual Studio usa para separar claramente el código creado por desarrollador del código generado por IDE, los desarrolladores también pueden usarlas en los módulos de código subyacente, especialmente cuando se trabaja en un entorno de trabajo en equipo.

Como las clases parciales son la norma para las aplicaciones de ASP.NET 2.0+, debe separar sus clases de ASP.NET 1.1 en clases parciales. Si omite este paso, las páginas y controles de usuario seguirán funcionando pero tendrá que actualizar manualmente las declaraciones de campos de control en los archivos de código subyacente cuando modifique los controles de una página (.aspx) o un control de usuario (.ascx).

El comando CWA también cambia el valor de AutoEvent¬Wireup, además de la manera en que se declaran y transmiten los eventos, y creo que el impacto de esto es importante y que debe analizarse en detalle. AutoEventWireup es un atributo booleano que especifica si los controladores de eventos del objeto de página se transmiten implícitamente (cuando es True) o explícitamente (cuando es False). En el caso de las páginas, AutoEventWireup se define en la etiqueta @Page; para los controles de usuario, AutoEventWireup se define en la etiqueta @Control. El comando CWA define AutoEventWireup en True para las páginas y controles de usuario de C# y lo define en False para las páginas y controles de usuario de Visual Basic .NET.

Los desarrolladores tienen distintas preferencias, y es muy posible que algunas páginas o controles de usuario en la aplicación de ASP.NET 1.1 definan AutoEventWireup en True o False, o que no lo especifiquen de ninguna manera, en cuyo caso se define de manera predeterminada desde web.config o, si no se especifica ahí, desde machine.config. Es importante saber que el valor de AutoEventWireup puede cambiar después de ejecutar el comando CWA. Esto cambio puede provocar un comportamiento no anticipado, como que los eventos de página se activen dos veces. Esto ocurre con mayor frecuencia cuando creó su propia convención de nomenclatura para eventos del objeto Página en la aplicación de ASP.NET 1.1. Por ejemplo, considere este código de C# en el que un controlador Page_Load2 se transmite al delegado de evento Page.Load:

this.Load += new System.EventHandler(this.Page_Load2);

Cuando AutoEventWireup es False, el evento se activará una vez, tal como se espera, incluso si hay una función de código subyacente llamada Page_Load. Sin embargo, cuando AutoEventWireup es True, se activan ambos eventos, una vez para el código de transmisión explícito que se muestra aquí y una vez para el código de transmisión implícito que suscribe el controlador de eventos Page_Load al evento Page.Load. Observe, por ejemplo, el código en la Figura 9.

Figura 9 Prueba del comportamiento de AutoEventWireup

public partial class _Default : System.Web.UI.Page
{
  override protected void OnInit(EventArgs e)
  {
    InitializeComponent();
    base.OnInit(e);
  }

  private void InitializeComponent()
  {
    this.Load += new System.EventHandler(this.Page_Load2);
  }

  protected void Page_Load()
  {
    Response.Write("In Page_Load().<br />");
  }

  protected void Page_Load2(object sender, EventArgs e)
  {
    Response.Write("In Page_Load2().<br />");
  }
}

El código que aparece en la figura 9 genera este resultado:

In Page_Load().
In Page_Load2().
Top of Form 1
Bottom of Form 1

Ocurre lo mismo en Visual Basic .NET cuando AutoEventWireup se define en True. Observe el siguiente código:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)

  Response.Write("In Page_Load.<br />")

End Sub

Private Sub Page_Load2(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles MyBase.Load

  Response.Write("In Page_Load2.<br />")

End Sub

Cuando AutoEventWireup es True, se activan ambos controladores de eventos, lo que hace que se muestre la página:

In Page_Load2.
  In Page_Load.

Puede ver que no sólo se ejecutan dos controladores de eventos, sino que también el orden en que se ejecutan (como ocurre con todos los delegados en multidifusión) posiblemente no sea el esperado. Finalmente, observe que cuando AutoEventWireup es True, los controladores de eventos de página con el nombre de función correcto, como Page_Load, se activarán independientemente de si están definidos con o sin argumentos. Por ejemplo:

protected void Page_Load()
  {
    Response.Write("In Page_Load().<br />");
  }

es igual que:

protected void Page_Load(object sender, EventArgs e)
  {
    Response.Write("In Page_Load().<br />");
  }

Si ambos están presentes, sólo se activa el que tiene argumentos, lo cual es otro asunto que hay que considerar cuando se realiza la solución de problemas. Por eso, en general, tenga cuidado al probar páginas y controles de usuario, especialmente si el comando CWA cambió la configuración de AutoEvent¬Wireup.

Finalmente, el comando CWA quita el código explícito de C# y Visual Basic .NET que transmite los eventos de control y, en su lugar, usa atributos de eventos declarativos en el marcado de la página o del control de usuario. Por ejemplo, en ASP.NET 1.1, un evento Click en un botón normalmente tendrá un controlador de eventos en código subyacente, como:

this.MyButton.Click += new System.EventHandler(this.MyButton_Click);

El comando CWA lo quita y en su lugar agrega un atributo OnClick a la declaración de control de servidor de la siguiente manera:

<asp:Button ID="MyButton" runat="server" Text="MyButton" onclick="MyButton" />

No se agregan eventos declarativos en Visual Basic .NET. En lugar de eso, se agrega la palabra clave Handles al código subyacente. De esta manera, el marcado de un control de botón aparecerá de la siguiente forma:

<asp:Button ID="MyButton" runat="server" Text="Button" />

mientras que el código subyacente transmite el control al controlador:

Protected Sub MyButton_Click(
  ByVal sender As Object, ByVal e As EventArgs) _
Handles MyButton.Click

End Sub

Los delegados de eventos para estas construcciones de controladores de eventos declarativos se crean en tiempo de compilación.

Compile y corrija La migración ahora está completa. Le recomiendo volver a generar la solución y pasar por el ejercicio de enfrentar cualquier error de compilador o advertencia restante que pueda recibir. Observe que necesita solucionar los errores de compilación antes de poder generar correctamente su proyecto web y antes de poder ver su sitio web migrado en un explorador. También debe abordar las advertencias de la compilación, pero no se les considera críticas y no evitarán que use su aplicación web. Finalmente, tome nota de todos los mensajes del compilador, dado que generalmente proporcionan recomendaciones útiles para las mejoras que debe considerar implementar en la medida en que el tiempo lo permita. Más allá de los errores y las advertencias, es importante realizar pruebas de regresión y pruebas de control de calidad en el código migrado. Tenga especial cuidado para asegurarse de que los eventos se activan de la manera esperada.

Consideraciones posteriores a la migración

Como el proyecto de ASP.NET ahora apunta a un marco más reciente y se ejecuta bajo una versión más moderna del IDE, debe tener en cuenta algunos problemas adicionales.

Si migró su solución de ASP.NET 1.1 desde un sistema operativo de 32 bits a uno de 64 bits, debe saber que IIS 6.0 y posteriores son compatibles con modos de operación de 32 bits y 64 bits. Como ASP.NET 1.1 sólo se ejecuta en modo de 32 bits, es posible que se encuentre con que su aplicación de ASP.NET convertida todavía tiene dependencias de 32 bits (como llamadas COM o P/Invoke), las que probablemente no funcionen correctamente después de la migración. Para corregir esto, obtenga acceso a las configuraciones avanzadas del grupo de aplicaciones de la aplicación y defina el valor Habilitar aplicaciones de 32 bits en True.

Visual Studio 2010 espera que las páginas web sean compatibles con XHTML. Es probable que sus páginas de ASP.NET 1.1 no lo sean. Por lo tanto, la mayoría de las páginas mostrarán advertencias de validación de XHTML (para verlas, vea su página en modo de Diseño o Código fuente, obtenga acceso al menú Ver y seleccione Lista de errores). A pesar de que estas advertencias no impedirán que se ejecute una página, sí indican que es posible que las páginas no se presenten correctamente en exploradores modernos. Cuando el tiempo lo permita, debe actualizar sus páginas y controles de usuario para que sean compatibles con XHTML, lo que garantizará que se presenten correctamente en exploradores modernos. Si la aplicación web apunta específicamente a un explorador anterior, o si no desea ver errores de validación de marcado en este momento, puede cambiar la manera de validar el marcado en el menú Herramientas, Opciones y yendo al nodo Editor de texto y ahí cambie Destino a Internet Explorer 6 (consulte la figura 10). Este enfoque sólo es adecuado para desarrolladores que deben apuntar a Internet Explorer 6, como probablemente sea el caso si la aplicación es una aplicación de intranet corporativa, por ejemplo. Con esto se define eficazmente la validación de presentación en un nivel similar al que probablemente usaba en Visual Studio 2003.

Figura 10 Puede suprimir los errores de validación de XHTML si cambia el destino de la validación HTML a Internet Explorer 6

Para las aplicaciones que se deberán mostrar correctamente en exploradores que no sean Internet Explorer o en versiones de Internet Explorer posteriores a la versión 6, debe continuar mostrando los errores de marcado de XHTML en el editor de HTML, y debe usar el valor de configuración controlRenderingCompatibilityVersion de .NET Framework 4, disponible como propiedad en la sección Web.config system.web:

<system.web>
  <pages controlRenderingCompatibilityVersion="4.0"/>
</system.web>

Si controlRenderingCompatibilityVersion no está definido en Web.config, se define de manera predeterminada en la versión de ASP.NET en ejecución. Sin embargo, cuando especifica el valor de controlRenderingCompatibilityVersion, puede definirlo en “3.5” ó “4.0” (el Asistente para la conversión lo define en “3.5”, lo que presenta las páginas de la misma manera que en ASP.NET 3.5). Esta configuración determina cómo el marcado especificado en sus archivos .aspx se presenta finalmente en el explorador. Para citar un ejemplo de la ayuda en línea de Visual Studio 2010, cuando controlRenderingCompatibilityVersion se define en “3.5,” un control de etiqueta ASP.NET de lado servidor con su propiedad IsEnabled definida en False presentará un elemento span HTML con su atributo “disabled” definido en “disabled”; cuando controlRenderingCompatibilityVersion se define en “4.0,” el elemento span resultante incluirá en su lugar un atributo “class” con una referencia a una clase CSS.

Debe tener en cuenta que usar la definición “4.0” genera un marcado XHTML moderno, y esto puede interrumpir un script de cliente o reglas CSS que funcionaban correctamente en la versión ASP.NET 1.1 de la página, lo que afecta el comportamiento y/o la estética del contenido presentado. Por lo tanto, y hasta que esté completamente comprometido con la generación de XHTML válido, le sugiero que defina controlRenderingCompatibilityVersion en “3.5.”, y si usa esta definición “3.5”, tiene que saber acerca de xhtmlConformance (que sólo se aplica si controlRenderingCompatibilityVersion se define en “3.5”), que se puede definir en “Legacy,” “Strict” o “Transitional” (el valor predeterminado). “Strict” presenta un marcado XHTML 1.0 estricto; “Transitional” presenta un marcado XHTML 1.0 de transición; “Legacy” presenta el HTML de manera similar (pero no necesariamente igual) a la manera en que se presentaba en ASP.NET:

<system.web>
  <pages controlRenderingCompatibilityVersion="4.0"/>
  <xhtmlConformance mode="Transitional"/>
</system.web>

Según mi experiencia, debe evitar el uso del modo “Legacy”, porque puede interferir con el funcionamiento adecuado de ASP.NET AJAX UpdatePanel. Además, observe que el valor controlRenderingCompatibilityVersion no cambia el DOCTYPE de su página web, sino que simplemente cambia la manera en que se presentan los controles de ASP.NET. De esta manera, hacer que sus páginas se presenten correctamente se debe en gran medida a la combinación de los valores controlRenderingCompatibilityVersion, xhtmlConformance y DOCTYPE, así como también al tipo de explorador de destino y a la versión usada.

Otro punto a considerar: Es posible que desee cambiar el directorio virtual bajo el cual se ejecuta el sitio recientemente migrado, especialmente si planea ejecutarlo en paralelo con la versión ASP.NET 1.1. Para ello, haga clic con el botón secundario en el proyecto web en el Explorador de soluciones, seleccione Propiedades y obtenga acceso a la pestaña Web. En Servidores, verá una opción para Usar servidor web de IIS local. Para asegurarse de que se seleccionó esta opción, especifique la dirección URL de un proyecto (como http://localhost/mysitemigrated) y haga clic en el botón Crear directorio virtual si el directorio virtual no existe.

Las aplicaciones ASP.NET 1.1 usan el usuario Windows ASPNET para asignar privilegios sobre archivos y carpetas bajo la raíz virtual. ASP.NET 2.0+ usa el usuario NETWORK SERVICE. Si su aplicación requiere que ASP.NET tenga acceso de escritura a ciertos archivos o carpetas, por ejemplo, es importante otorgar esos derechos al usuario NETWORK SERVICE. Si no está seguro de qué usuario necesita este acceso, puede ver ese nombre de usuario si examina el valor de la propiedad Environment.UserName mientras se ejecuta una aplicación ASP.NET.

Si usa completos o dependencias de terceros (ya sea binaria o de código fuente), querrá comprobar con el proveedor para asegurarse de tener la versión más reciente. Por ejemplo, NLog, el popular programa de registro, ofrece compilaciones de biblioteca 1.1 y 2.0. Tome la compilación 2.0 y ahórrese el esfuerzo de migrar usted mismo el código 1.1. Además, los proveedores proporcionar actualizaciones de los complementos de productividad diseñados para el IDE de Visual Studio. Asegúrese de actualizar hasta obtener las versiones más actuales de los productos para su nuevo IDE de Visual Studio 2010.

Después de migrar sus aplicaciones web de ASP.NET 1.1, obtendrá dos beneficios inmediatos. Primero, ya no requerirá extensiones Front Page Server Extensions (FPSE) para potenciar su sitio (a menos que, de manera opcional, desee seguir usándolo). Segundo, ya no será necesario que tenga instalado IIS en su máquina de desarrollo, puesto que Visual Studio 2010 ofrece su propio servidor de desarrollo ASP.NET integrado. Y mientras puede seguir ejecutando aplicaciones de ASP.NET de Visual Studio 2003 de manera paralela a las aplicaciones de ASP.NET de Visual Studio 2010 ASP.NET (por ejemplo, para control de calidad o depuración), la aplicación de ASP.NET de Visual Studio 2010 convertida no requerirá más Visual Studio 2003 u obtener acceso a .NET Framework 1.1.

 Si es desarrollador de C#, es posible que observe que ya no aparecen eventos de página o de control de usuario en la ventana Propiedades como un icono de rayo amarillo cuando los ve en el modo de diseño. Para ver o crear estos eventos como en Visual Studio 2003, tendrá que hacer clic con el botón secundario en la página (.aspx) o en el control de usuario (.ascx) en el Explorador de solución y elegir Ver diseñador de componentes. En ese punto, verá una ventana Propiedades que contiene la lista de eventos familiar. Puede hacer doble clic en cualquiera de los eventos de al lista para crear el procedimiento de eventos y delegar código de transmisión (esto se agrega a la función InitializeComponent).

Cuando sea momento de alojar el sitio, tendrá que saber qué CLR se requiere. Cuando usa 3.0 y 3.5 .NET Framework, realiza la ejecución contra CLR 2.0; cuando usa .NET Framework 4, ejecuta contra CLR 4.0. Su empresa de alojamiento también debe ser compatible con CLR 4.0 para poder alojar su solución ASP.NET 4.0.

Espero haberle ayudado a realizar la transición de sus aplicaciones de ASP.NET de Visual Studio 2003 a Visual Studio 2010. Cuando lo haga, tendrá a su disposición todo un mundo nuevo de tecnologías para la programación. Creo que es una decisión relativamente sencilla sobre la tecnología de la cual no se arrepentirá.

Jonathan Waldman ha trabajado para PC Magazine y es un Microsoft Certified Professional senior que usa las tecnologías de .NET Framework para crear soluciones de software personalizadas para escritorios y para la Web. Puede ponerse en contacto con él en la dirección jonathan.waldman@live.com.

Gracias al siguiente experto técnico por su ayuda en la revisión de este artículo: Scott Hanselman