Problemas de migración de .NET Framework 4

Artículo
04/03/2023

En este artículo se describen los problemas de migración entre .NET Framework versión 3.5 Service Pack 1 y .NET Framework versión 4, incluidas las correcciones, los cambios para el cumplimiento de estándares y la seguridad, y los cambios basados en los comentarios de los clientes. La mayoría de estos cambios no exigen que realice ningún tipo de modificación de programación en sus aplicaciones. Para obtener los que podrían implicar modificaciones, vea la columna Cambios recomendados de la tabla. Los cambios importantes se desglosan por área, por ejemplo, ASP.NET y Windows Presentation Foundation (WPF).

Para obtener información más general sobre las incidencias de este artículo, vea Guía de migración para .NET Framework 4.

Para obtener información sobre las características nuevas, vea Novedades de .NET Framework 4.

ASP.NET y web

Espacios de nombres: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls

Ensamblado: System.Web (en System.Web.dll)

Característica	Diferencias respecto a 3.5 SP1	Cambios recomendados
Archivos de definición de explorador	Los archivos de definición de explorador se han actualizado para que incluyan información sobre exploradores y dispositivos nuevos y actualizados. Se han quitado exploradores y dispositivos anteriores, como Netscape Navigator, y se han agregado exploradores y dispositivos más recientes, como Google Chrome y Apple iPhone. Si la aplicación contiene definiciones de explorador personalizadas que heredan de una de las definiciones de explorador que se han quitado, aparecerá un error. El objeto HttpBrowserCapabilities (que se expone mediante la propiedad `Request.Browse` de la página) está controlado por los archivos de definición del explorador. Por lo tanto, la información que se devuelve mediante el acceso a una propiedad de este objeto en ASP.NET 4 podría ser diferente de la información devuelta en una versión anterior de ASP.NET.	Si la aplicación se basa en los archivos de definición del explorador antiguo, puede copiarlos de la siguiente carpeta: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Copie los archivos en la carpeta \CONFIG\Browsers correspondiente de ASP.NET 4. Después de copiar los archivos, ejecute la herramienta de línea de comandos Aspnet_regbrowsers.exe. Para obtener más información, vea el sitio web https://www.asp.net/mobile.
Aplicaciones secundarias que se ejecutan en versiones mixtas de ASP.NET	Las aplicaciones de ASP.NET 4 configuradas como elementos secundarios de aplicaciones que ejecutan versiones anteriores de ASP.NET podrían no iniciarse debido a errores de configuración o de compilación. El error que aparezca dependerá de si la aplicación se ejecuta en IIS 6.0, en IIS 7 o en IIS 7.5.	Puede realizar cambios en los archivos de configuración de las aplicaciones afectadas para que el sistema de configuración reconozca correctamente la aplicación de ASP.NET 4. Para obtener información sobre los cambios que debe realizar, vea la sección "ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications" (Las aplicaciones secundarias de ASP.NET 4 no se inician cuando se ejecutan en aplicaciones de ASP.NET 2.0 o ASP.NET 3.5) en el documento ASP.NET 4 Breaking Changes (Cambios importantes de ASP.NET 4) en el sitio web de ASP.NET.
Cambios de ClientID	La nueva opción `clientIDMode` de ASP.NET 4 permite especificar cómo genera ASP.NET el atributo `id` para los elementos HTML. En versiones anteriores de ASP.NET, el comportamiento predeterminado era equivalente al valor `AutoID` de `clientIDMode`. Ahora, el valor predeterminado es `Predictable`. Para obtener más información, vea Identificación de controles de formularios Web Forms.	Si usa Visual Studio para actualizar la aplicación desde ASP.NET 2.0 o ASP.NET 3.5, la herramienta agrega automáticamente una configuración en el archivo Web.config que conserva el comportamiento de versiones anteriores de .NET Framework. Pero si actualiza una aplicación y cambia el grupo de aplicaciones en IIS para elegir como destino .NET Framework 4, ASP.NET usa el nuevo modo de forma predeterminada. Para deshabilitar el nuevo modo de identificador de cliente, agregue el valor siguiente al archivo Web.config: `<pages clientIDMode="AutoID" />`
Seguridad de acceso del código (CAS)	Las características de .NET de ASP.NET 2.0 que se han agregado a ASP.NET 3.5 usan el modelo de seguridad de acceso del código (CAS) de .NET Framework 1.1 y .NET Framework 2.0. Aun así, la implementación de CAS en ASP.NET 4 se ha mejorado considerablemente. Como resultado, podría producirse un error con varias excepciones de seguridad en las aplicaciones de ASP.NET de confianza parcial que se basan en código de confianza que se ejecuta en la caché global de ensamblados. También se podrían producir errores y excepciones de seguridad en las aplicaciones de confianza parcial que se basan en modificaciones extensas de la directiva de CAS del equipo.	Puede revertir las aplicaciones de ASP.NET 4 de confianza parcial al comportamiento de ASP.NET 1.1 y 2.0 mediante el uso del nuevo atributo `legacyCasModel` en el elemento de configuración `trust`, como se muestra en el ejemplo siguiente: `<trust level= "Medium" legacyCasModel="true" />` Importante: El hecho de revertir al modelo anterior de CAS podría reducir la seguridad. Para obtener más información sobre el nuevo modelo de seguridad de acceso del código de ASP.NET 4, vea Seguridad de acceso del código para aplicaciones ASP.NET 4.
Archivos de configuración	Los archivos de configuración raíz (machine.config y el archivo raíz Web.config) para .NET Framework y ASP.NET 4 se han actualizado para incluir la mayor parte de la información de configuración reutilizable que se encontraba en los archivos de aplicación Web.config de ASP.NET 3.5. Dada la complejidad de los sistemas de configuración administrados de IIS 7 e IIS 7.5, la ejecución de aplicaciones de ASP.NET 3.5 en ASP.NET 4 y en IIS 7 e IIS 7.5 puede producir errores de ASP.NET o de IIS.	Actualice las aplicaciones de ASP.NET 3.5 a ASP.NET 4 mediante las herramientas de actualización de proyectos de Visual Studio. Visual Studio 2010 modifica automáticamente el archivo Web.config de la aplicación de ASP.NET 3.5 para que contenga la configuración adecuada para ASP.NET 4. Pero puede ejecutar aplicaciones ASP.NET 3.5 con .NET Framework 4 sin necesidad de volver a compilar. En ese caso, es posible que tenga que modificar manualmente el archivo Web.config de la aplicación antes de ejecutarla en .NET Framework 4 y en IIS 7 o IIS 7.5. El cambio específico que debe realizar depende de la combinación de software con la que trabaje, incluidas las versiones de Service Pack (SP). Para obtener información sobre las combinaciones de software que se pueden ver afectadas por este cambio y saber cómo resolver los problemas de combinaciones específicas, vea la sección "Configuration Errors Related to New ASP.NET 4 Root Configuration" (Errores de configuración relacionados con la nueva configuración raíz de ASP.NET 4) en el documento ASP.NET 4 Breaking Changes (Cambios importantes de ASP.NET 4) en el sitio web de ASP.NET.
Representación de controles	En versiones anteriores de ASP.NET, algunos controles emitían un marcado que no se podía deshabilitar. De forma predeterminada, este tipo de marcado ya no se genera en ASP.NET 4. Los cambios de representación afectan a los siguientes controles: * Los controles `Image` y `ImageButton` ya no representan un atributo `border="0"`. * La clase `BaseValidator` y los controles de validación que derivan de ella ya no representan texto rojo de forma predeterminada. * El control `HtmlForm` no representa un atributo `name`. * El control `Table` ya no representa un atributo `border="0"`. Los controles que no están diseñados para la entrada del usuario (por ejemplo, el control `Label`) ya no representan el atributo `disabled="disabled"` si su propiedad `Enabled` está establecida en `false` (o si heredan esta configuración de un control contenedor).	Si usa Visual Studio para actualizar la aplicación desde ASP.NET 2.0 o ASP.NET 3.5, la herramienta agrega automáticamente una configuración en el archivo Web.config que conserva la representación heredada. Pero si actualiza una aplicación y cambia el grupo de aplicaciones en IIS para elegir como destino .NET Framework 4, ASP.NET usa de forma predeterminada el nuevo modo de representación. Para deshabilitar el nuevo modo de representación, agregue el valor siguiente al archivo Web.config: `<pages controlRenderingCompatibilityVersion="3.5" />`
Controladores de eventos en documentos predeterminados	ASP.NET 4 representa el valor de atributo `action` del elemento HTML `form` como una cadena vacía cuando se realiza una solicitud a una dirección URL sin extensión que tiene asignado un documento predeterminado. En versiones anteriores de ASP.NET, una solicitud a `http://contoso.com` daría como resultado una solicitud a Default.aspx. En ese documento, la etiqueta `form` de apertura se representaría como en el ejemplo siguiente: `<form action="Default.aspx" />` En ASP.NET 4, una solicitud a `http://contoso.com` también daría como resultado una solicitud a Default.aspx, pero ASP.NET ahora representa la etiqueta de apertura HTML `form` como en el ejemplo siguiente: `<form action="" />` Cuando el atributo `action` es una cadena vacía, el objeto `DefaultDocumentModule` de IIS crea una solicitud secundaria a Default.aspx. En la mayoría de las condiciones, esta solicitud secundaria es transparente para el código de la aplicación y la página Default.aspx se ejecuta con normalidad. A pesar de ello, una interacción potencial entre el código administrado y el modo integrado de IIS 7 o IIS 7.5 puede hacer que las páginas .aspx administradas dejen de funcionar correctamente durante la solicitud secundaria. Si se producen las condiciones siguientes, la solicitud secundaria a un documento .aspx predeterminado producirá un error o un comportamiento inesperado: * Una página .aspx se envía al explorador con el atributo `action` del elemento `form` establecido en "". * El formulario se envía de vuelta a ASP.NET. * Un módulo HTTP administrado lee una parte del cuerpo de la entidad, como `Request.Form` o `Request.Params`. Esto hace que el cuerpo de la entidad de la solicitud POST se lea en la memoria administrada. Como resultado, el cuerpo de la entidad ya no está disponible para los módulos de código nativo que se ejecutan en el modo integrado de IIS 7 o IIS 7.5. * El objeto `DefaultDocumentModule` de IIS finalmente se ejecuta y crea una solicitud secundaria al documento Default.aspx. Sin embargo, dado que un fragmento del código administrado ya ha leído el cuerpo de la entidad, no hay ningún cuerpo de entidad disponible para enviarlo a la solicitud secundaria. * Cuando se ejecuta la canalización HTTP para la solicitud secundaria, el controlador de archivos .aspx se ejecuta durante la fase de ejecución de controlador. Dado que no hay ningún cuerpo de entidad, no hay variables de formulario ni estado de vista. Por lo tanto, no hay información disponible para que el controlador de páginas .aspx determine qué evento se debe generar (en caso de que sea necesario). Como resultado, no se ejecuta ninguno de los controladores de eventos postback para la página .aspx afectada.	Para obtener información sobre las formas de solucionar los problemas que pueden surgir como resultado de este cambio, vea "Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode" (Podrían no producirse eventos de controladores en un documento predeterminado en el modo integrado de IIS 7 o IIS 7.5) en el documento ASP.NET 4 Breaking Changes (Cambios importantes de ASP.NET 4) en el sitio web de ASP.NET.
Algoritmo hash	ASP.NET usa cifrado y algoritmos hash para ayudar a proteger los datos, como las cookies de autenticación de formularios y el estado de vista. De forma predeterminada, ASP.NET 4 usa el algoritmo HMACSHA256 para las operaciones de hash en las cookies y el estado de vista. Las versiones anteriores de ASP.NET usaban el algoritmo HMACSHA1, más antiguo.	Si ejecuta aplicaciones que combinan ASP.NET 2.0 y ASP.NET 4, en las que los datos como las cookies de autenticación de formularios deben funcionar en diferentes versiones de .NET Framework, configure una aplicación web de ASP.NET 4 de modo que use el algoritmo HMACSHA1 antiguo. Para ello, agregue el valor de configuración siguiente en el archivo Web.config: `<machineKey validation="SHA1" />`
Hospedar controles en Internet Explorer	Ya no se pueden hospedar controles de formularios Windows Forms en Internet Explorer, dado que existen soluciones mejores para hospedar controles en la Web. Por tanto, se han quitado de .NET Framework los ensamblados IEHost.dll e IEExec.exe.	Puede usar las siguientes tecnologías para el desarrollo de controles personalizados en aplicaciones web: * Puede crear una aplicación de Silverlight y configurarla para que se ejecute fuera del explorador. Para obtener más información, vea Out-of-Browser Support (Compatibilidad fuera del explorador). * Puede compilar una aplicación de explorador XAML (XBAP) para aprovechar las ventajas de las funciones de WPF (requiere .NET Framework en los equipos cliente). Para obtener más información, vea Información general sobre las aplicaciones de explorador XAML de WPF.
Métodos HtmlEncode y UrlEncode	Los métodos `HtmlEncode` y `UrlEncode` de las clases HttpUtility y HttpServerUtility se han actualizado para codificar el carácter de comilla simple (') como se indica a continuación: * El método `HtmlEncode` codifica las instancias de la comilla simple como `'` * El método `UrlEncode` codifica las instancias de la comilla simple como `%27`	Busque en el código los lugares en los que usa los métodos `HtmlEncode` y `UrlEncode` y asegúrese de que el cambio en la codificación no produce un cambio que afecte a la aplicación.
Errores HttpException en aplicaciones de ASP.NET 2.0	Una vez que se ha habilitado ASP.NET 4 en IIS 6, las aplicaciones de ASP.NET 2.0 que se ejecutan en IIS 6 (en Windows Server 2003 o Windows Server 2003 R2) podrían generar errores como el siguiente: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Si no se requiere ASP.NET 4 para ejecutar el sitio web, vuelva a asignar el sitio de modo que use ASP.NET 2.0 en su lugar. o bien * Si se requiere ASP.NET 4 para ejecutar el sitio web, mueva los directorios virtuales secundarios de ASP.NET 2.0 a otro sitio web que esté asignado a ASP.NET 2.0. o bien * Deshabilite las direcciones URL sin extensión. Para obtener más información, vea "ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd" (Las aplicaciones de ASP.NET 2.0 pueden generar errores HttpException que hacen referencia a eurl.axd) en el documento ASP.NET 4 Breaking Changes (Cambios importantes de ASP.NET 4) en el sitio web de ASP.NET.
Tipos de pertenencia	Algunos tipos (por ejemplo, MembershipProvider) que se usan en la pertenencia a ASP.NET se han movido del ensamblado System.Web.dll al ensamblado System.Web.ApplicationServices.dll. Estos tipos se han movido para resolver las dependencias de capas de arquitectura entre los tipos del cliente y de las SKU de .NET Framework extendidas.	Las bibliotecas de clases que se han actualizado desde versiones anteriores de ASP.NET y que usan tipos de pertenencia movidos podrían no compilarse cuando se usan en un proyecto de ASP.NET 4. En ese caso, agregue una referencia a System.Web.ApplicationServices.dll en el proyecto de biblioteca de clases.
Cambios en el control Menu	Los cambios en el control Menu provocan el siguiente comportamiento: * Si MenuRenderingMode está establecido en `List`, o si MenuRenderingMode está establecido en `Default` y ControlRenderingCompatibilityVersion está establecido en `4.0` o una versión posterior, la propiedad PopOutImageUrl no tiene ningún efecto. * Si la ruta de acceso que se establece en las propiedades StaticPopOutImageUrl y DynamicPopOutImageUrl contiene una barra diagonal inversa (\), las imágenes no se representan. (En versiones anteriores de ASP.NET, la ruta de acceso podría incluir una barra diagonal inversa).	* En lugar de establecer la propiedad PopOutImageUrl para los elementos de menú individuales, establezca las propiedades StaticPopOutImageUrl o DynamicPopOutImageUrl del control primario Menu. o bien Establezca MenuRenderingMode en `Table`, o establezca MenuRenderingMode en `Default` y ControlRenderingCompatibilityVersion en `3.5`. Esta configuración hace que el control Menu use el diseño basado en la tablas HTML que se usaba en versiones anteriores de ASP.NET. * Si la ruta de acceso de la propiedad StaticPopOutImageUrl o DynamicPopOutImageUrl contiene una barra diagonal inversa (\), sustitúyala por un carácter de barra diagonal (/).
Ensamblado móvil en el archivo Web.config	En versiones anteriores de ASP.NET, se incluía una referencia al ensamblado System.Web.Mobile.dll en el archivo raíz Web.config en la sección `assemblies` de `system.web`/`compilation`. Para mejorar el rendimiento, se ha quitado la referencia a este ensamblado. Nota: El ensamblado System.Web.Mobile.dll y los controles móviles de ASP.NET están incluidos en ASP.NET 4, pero están en desuso.	Si quiere usar tipos de este ensamblado, agregue una referencia al ensamblado en el archivo raíz Web.config o en un archivo de aplicación Web.config.
Almacenamiento en caché de resultados	En ASP.NET 1.0, un error hacía que las páginas en caché que especificaban `Location="ServerAndClient"` como valor de la caché de resultados emitiesen un encabezado HTTP `Vary:` en la respuesta. Como consecuencia, se indicaba a los exploradores de cliente que nunca almacenasen en caché la página localmente. En ASP.NET 1.1 se agregó el método SetOmitVaryStar, al que se podía llamar para suprimir el encabezado `Vary:`. A pesar de ello, los informes de errores sugieren que los desarrolladores no son conscientes del comportamiento de `SetOmitVaryStar`. En ASP.NET 4, ya no se emite el encabezado HTTP `Vary:` desde las respuestas que especifican la directiva siguiente: `<%@ OutputCache Location="ServerAndClient" %>` Como resultado, ya no es necesario el método SetOmitVaryStar para suprimir el encabezado `Vary:`. En las aplicaciones que especifican "ServerAndClient" para el atributo `Location`, las páginas se podrán almacenar en caché en el explorador sin necesidad de llamar a SetOmitVaryStar.	Si las páginas de la aplicación deben emitir `Vary:`, llame al método AppendHeader como se muestra en el ejemplo siguiente: `System.Web.HttpResponse.AppendHeader("Vary","");` Como alternativa, puede cambiar el valor del atributo `Location` de la caché de resultados a "Server".
Análisis de página	El analizador de páginas de ASP.NET para páginas web (archivos .aspx) y controles de usuario (archivos .ascx) es más estricto en ASP.NET 4 que en versiones anteriores de ASP.NET, y marca como no válido un mayor porcentaje de marcado que en versiones anteriores.	Examine los mensajes de error que se producen cuando se ejecuta una página y corrija los errores derivados de un marcado no válido.
Tipos de Passport	La compatibilidad con Passport integrada en ASP.NET 2.0 está obsoleta y no se admite debido a los cambios que se han producido en Passport (ahora Live ID SDK). Como resultado, los tipos relacionados con Passport en System.Web.Security ahora se marcan con el atributo `ObsoleteAttribute`.	Cambie el código que use tipos de Passport en el espacio de nombres System.Web.Security (por ejemplo, PassportIdentity) para que use el SDK de Windows Live ID.
Información de PathInfo en la propiedad FilePath	ASP.NET 4 ya no incluye el valor `PathInfo` en los valores devueltos desde propiedades como FilePath, AppRelativeCurrentExecutionFilePath y CurrentExecutionFilePath. Ahora, la información de `PathInfo` está disponible en PathInfo. Por ejemplo, veamos el siguiente fragmento de dirección URL: `/testapp/Action.mvc/SomeAction` En versiones anteriores de ASP.NET, las propiedades HttpRequest tienen los valores siguientes: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (vacío) En cambio, en ASP.NET 4, las propiedades HttpRequest tienen los siguientes valores: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Busque en el código los lugares en los que las propiedades de la clase HttpRequest deben devolver información de la ruta de acceso y cambie el código de modo que refleje los cambios en la manera en que se devuelve la información de la ruta de acceso.
Validación de solicitudes	Para mejorar la validación de solicitudes, la validación de solicitudes de ASP.NET se invoca antes en el ciclo de vida de la solicitud. Como resultado, la validación de solicitudes se ejecuta para las solicitudes que no son de archivos .aspx, como las llamadas al servicio web y los controladores personalizados. La validación de solicitudes también estará activa cuando se ejecuten módulos HTTP personalizados en la canalización de procesamiento de solicitudes. Como resultado de este cambio, las solicitudes de recursos que no sean archivos .aspx podrían producir errores de validación de solicitudes. El código personalizado que se ejecuta en la canalización de solicitud (por ejemplo, los módulos HTTP personalizados) también podría producir errores de validación de solicitudes.	Si es necesario, puede revertir al comportamiento anterior, en el que solo las páginas .aspx desencadenan la validación de solicitudes. Para ello, use el valor siguiente en el archivo de configuración web: `<httpRuntime requestValidationMode="2.0" />` Advertencia: Si revierte al comportamiento anterior, asegúrese de que todo el código de los controladores, los módulos y el resto de código personalizado realice comprobaciones en busca de las entradas HTTP potencialmente no seguras que podrían ser vectores de ataque XSS.
Enrutamiento	Si crea un sitio web del sistema de archivos en Visual Studio 2010 y dicho sitio web se encuentra en una carpeta que contiene un punto (.) en el nombre de carpeta, el enrutamiento de direcciones URL no funcionará de forma confiable. Se devolverá un error HTTP 404 desde algunas rutas de acceso virtuales. Esto se debe a que Visual Studio 2010 inicia el Servidor de desarrollo de Visual Studio mediante una ruta de acceso incorrecta para el directorio virtual raíz.	* En la página Propiedades del sitio web basado en archivos, cambie el atributo Virtual Path a "/". o bien * Cree un proyecto de aplicación web en lugar de un proyecto de sitio web. Los proyectos de aplicación web no tienen este problema, y el enrutamiento de direcciones URL funciona incluso si el nombre de la carpeta del proyecto tiene un punto. o bien * Cree un sitio web basado en HTTP que se hospede en IIS. Los sitios web hospedados en IIS pueden tener puntos en la ruta de acceso virtual, así como en la carpeta de archivos de proyecto.
Sitios de SharePoint	Si intenta ejecutar un sitio web de ASP.NET 4 que se implementa como un elemento secundario de un sitio web de SharePoint que contiene un nivel de confianza parcial personalizado denominado `WSS_Minimal`, verá el siguiente error: `Could not find permission set named 'ASP.Net'.`	Actualmente, ninguna versión de SharePoint es compatible con ASP.NET. Como resultado, no debe intentar ejecutar un sitio web de ASP.NET 4 como un elemento secundario de un sitio web de SharePoint.
Estándares de XHTML 1.1	Para habilitar el cumplimiento de XHTML 1.1 en sitios web nuevos, los controles de ASP.NET en .NET Framework 4 generarán código HTML compatible con XHTML 1.1. Esta representación se habilita mediante la opción siguiente en el archivo Web.config dentro del elemento `<system.Web>`: `<pages controlRenderingCompatibilityVersion="4.0"/>` Esta opción está establecida de forma predeterminada en 4.0. Los proyectos web que se actualizan desde Visual Studio 2008 tienen habilitado el valor 3.5 para la compatibilidad.	Ninguno.

Principal