Problemas de migración de .NET Framework 4

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 y la seguridad de los estándares y los cambios en función de los comentarios de los clientes. La mayoría de estos cambios no requieren ninguna modificación de programación en las aplicaciones. Para aquellos que pueden implicar modificaciones, consulte 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 general de nivel superior sobre los problemas de este artículo, consulte Guía de migración a .NET Framework 4.

Para obtener información sobre las nuevas características, consulte 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 desde 3.5 SP1	Cambios recomendados
Archivos de definición del explorador	Los archivos de definición del explorador se han actualizado para incluir información sobre los exploradores y dispositivos nuevos y actualizados. Se han quitado los exploradores y dispositivos más antiguos, como Netscape Navigator, y se han agregado navegadores 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, verá un error. El HttpBrowserCapabilities objeto (que está expuesto por 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 accediendo a una propiedad de este objeto en ASP.NET 4 podría ser diferente de la información que se devolvió en una versión anterior de ASP.NET.	Si la aplicación se basa en los archivos de definición de explorador antiguos, puede copiarlos desde la carpeta siguiente: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browser Copie los archivos en la carpeta \CONFIG\Browser correspondiente para 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, consulte el https://www.asp.net/mobile sitio web.
Aplicaciones secundarias que se ejecutan en versiones mixtas de ASP.NET	ASP.NET 4 aplicaciones configuradas como elementos secundarios de aplicaciones que ejecutan versiones anteriores de ASP.NET podrían no iniciarse debido a errores de configuración o compilación. El error específico que se produce depende de si la aplicación se ejecuta en IIS 6.0 o en IIS 7 o 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 ASP.NET 4. Para obtener información sobre los cambios que debe realizar, consulte la sección "Las aplicaciones secundarias de ASP.NET 4 no se inician cuando se ejecutan bajo aplicaciones de ASP.NET 2.0 o ASP.NET 3.5" en el documento Cambios disruptivos de ASP.NET 4 en el sitio web de ASP.NET.
Cambios de ClientID	La nueva `clientIDMode` configuración de ASP.NET 4 le permite especificar cómo ASP.NET genera el `id` atributo para los elementos HTML. En versiones anteriores de ASP.NET, el comportamiento predeterminado era equivalente a la configuración de `AutoID` en `clientIDMode`. La configuración predeterminada es ahora `Predictable`. Para obtener más información, consulte ASP.NET Identificación del control de servidor web.	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 al archivo Web.config que conserva el comportamiento de versiones anteriores de .NET Framework. Sin embargo, si actualiza una aplicación cambiando el grupo de aplicaciones de IIS a .NET Framework 4 como destino, ASP.NET usa el nuevo modo de forma predeterminada. Para deshabilitar el nuevo modo de identificador de cliente, agregue la siguiente configuración al archivo Web.config: `<pages clientIDMode="AutoID" />`
Seguridad de acceso al código (CAS)	Las características de .NET de ASP.NET 2.0 que se agregaron en ASP.NET 3.5 utilizan el modelo de seguridad de acceso a código (CAS) del .NET Framework 1.1 y .NET Framework 2.0. Sin embargo, la implementación del CAS en ASP.NET 4 se ha revisado sustancialmente. 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. Las aplicaciones de confianza parcial que dependen de modificaciones exhaustivas en la directiva CAS de la máquina también pueden producir errores y producir excepciones de seguridad.	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: Revertir al modelo CAS anterior podría representar una seguridad reducida. Para obtener más información sobre el nuevo modelo de seguridad de acceso de código ASP.NET 4, consulte Seguridad de acceso al código en ASP.NET 4 Aplicaciones.
Archivos de configuración	Los archivos de configuración raíz (el archivo machine.config y el archivo Web.config raíz) para .NET Framework y ASP.NET 4 se han actualizado para incluir la mayoría de la información de configuración predefinida que se encontraba en los archivos Web.config de la aplicación en ASP.NET 3.5. Debido a la complejidad de los sistemas de configuración de IIS 7 y IIS 7.5 administrados, la ejecución de aplicaciones ASP.NET 3.5 en ASP.NET 4 y en IIS 7 e IIS 7.5 puede producir errores de ASP.NET o errores de IIS.	Actualice las aplicaciones de ASP.NET 3.5 a ASP.NET 4 mediante las herramientas de actualización del proyecto en Visual Studio. Visual Studio 2010 modifica automáticamente el archivo Web.config de la aplicación ASP.NET 3.5 para que contenga la configuración adecuada para ASP.NET 4. Sin embargo, puede ejecutar aplicaciones de ASP.NET 3.5 mediante .NET Framework 4 sin volver a compilar. En ese caso, es posible que tenga que modificar manualmente el archivo Web.config de la aplicación antes de ejecutar la aplicación 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 el que trabaja, incluidas las versiones de Service Pack (SP). Para obtener información sobre las posibles combinaciones de software afectadas por este cambio y cómo resolver problemas con combinaciones específicas, vea la sección "Errores de configuración relacionados con la nueva configuración raíz de ASP.NET 4" en el documento ASP.NET 4 Cambios importantes en el sitio web de ASP.NET.
Representación de controles	En versiones anteriores de ASP.NET, algunos controles emitían marcados que no se podían 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 `Image` controles y `ImageButton` ya no representan un `border="0"` atributo. * Los `BaseValidator` controles de clase y validación que derivan de él ya no representan texto rojo de forma predeterminada. * El `HtmlForm` control no representa un `name` atributo. * El `Table` control ya no representa un `border="0"` atributo. Los controles que no están diseñados para la entrada del usuario (por ejemplo, el control `Label`) ya no renderizan el atributo `disabled="disabled"` si su propiedad `Enabled` está establecida en `false` (o si heredan esta configuración de un control de 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 al archivo Web.config que conserva la representación heredada. Sin embargo, si actualiza una aplicación cambiando el grupo de aplicaciones de IIS a .NET Framework 4 como destino, ASP.NET usa el nuevo modo de representación de forma predeterminada. Para deshabilitar el nuevo modo de representación, agregue la siguiente configuración al archivo Web.config: `<pages controlRenderingCompatibilityVersion="3.5" />`
Controladores de eventos en documentos predeterminados	ASP.NET 4 representa el valor de atributo del `form` elemento HTML `action` 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 para `http://contoso.com` produciría una solicitud para Default.aspx. En ese documento, la etiqueta de apertura `form` se representaría como en el ejemplo siguiente: `<form action="Default.aspx" />` En ASP.NET 4, una solicitud para `http://contoso.com` también da como resultado una solicitud para Default.aspx, pero ASP.NET ahora representa la etiqueta de apertura `form` HTML como en el ejemplo siguiente: `<form action="" />` Cuando el `action` atributo es una cadena vacía, el objeto IIS `DefaultDocumentModule` crea una solicitud secundaria para 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 normalmente. Sin embargo, una posible interacción entre el código administrado y el modo integrado de IIS 7 o IIS 7.5 puede hacer que las páginas de .aspx administradas dejen de funcionar correctamente durante la solicitud secundaria. Si se producen las condiciones siguientes, la solicitud secundaria a un documento de .aspx predeterminado producirá un error o un comportamiento inesperado: * Se envía una página .aspx al explorador con el `form` atributo del `action` elemento establecido en "". * El formulario se vuelve a publicar en ASP.NET. * Un módulo HTTP administrado lee 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 ningún módulo de código nativo que se ejecute en modo integrado de IIS 7 o IIS 7.5. * El objeto IIS `DefaultDocumentModule` 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 el controlador de página de .aspx para determinar qué evento (si existe) se debe generar. Como resultado, ninguno de los controladores de eventos de postback para la página .aspx afectada se ejecuta.	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 de hash	ASP.NET usa algoritmos de cifrado y 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 HMACSHA256 algoritmo para las operaciones hash en las cookies y el estado de visualización. Las versiones anteriores de ASP.NET usaron el algoritmo anterior HMACSHA1 .	Si ejecuta aplicaciones que combinan ASP.NET 2.0 y ASP.NET 4, donde los datos como las cookies de autenticación de formularios deben funcionar en versiones de .NET Framework, configure una aplicación web ASP.NET 4 para usar el algoritmo anterior HMACSHA1 agregando la siguiente configuración en el archivo Web.config: `<machineKey validation="SHA1" />`
Controles de hospedaje en Internet Explorer	Ya no puede hospedar controles de Windows Forms en Internet Explorer, ya que hay mejores soluciones para hospedar controles en la Web. Por lo tanto, los ensamblados IEHost.dll y IEExec.exe se han quitado de .NET Framework.	Puede usar las siguientes tecnologías para el desarrollo de controles personalizados en aplicaciones web: * Puede crear una aplicación silverlight y configurarla para que se ejecute fuera del explorador. Para obtener más información, consulte Compatibilidad fuera del explorador. * Puedes crear una aplicación de explorador XAML (XBAP) para aprovechar las funcionalidades de WPF (requiere .NET Framework en máquinas cliente). Para obtener más información, consulta Introducción a las aplicaciones de explorador XAML de WPF.
Métodos HtmlEncode y UrlEncode	Los `HtmlEncode` métodos y `UrlEncode` de las HttpUtility clases y HttpServerUtility se han actualizado para codificar el carácter de comillas simples (') de la siguiente manera: * El `HtmlEncode` método codifica las instancias de la comilla simple como `'` * El `UrlEncode` método codifica las instancias de la comilla simple como `%27`	Examine el código en busca de lugares en los que use los `HtmlEncode` métodos y `UrlEncode` y asegúrese de que el cambio en la codificación no da lugar a un cambio que afectaría a la aplicación.
Errores de HttpException en aplicaciones de ASP.NET 2.0	Después de habilitar ASP.NET 4 en IIS 6, ASP.NET 2.0 aplicaciones que se ejecutan en IIS 6 (en Windows Server 2003 o Windows Server 2003 R2) pueden generar errores como los siguientes: `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 para usar ASP.NET 2.0 en su lugar. -o- * Si se requiere ASP.NET 4 para ejecutar el sitio web, mueva los directorios virtuales de ASP.NET 2.0 secundarios a otro sitio web asignado a ASP.NET 2.0. -o- * Deshabilitar direcciones URL sin extensión. Para obtener más información, vea "Las aplicaciones de ASP.NET 2.0 podrían generar errores HttpException que hagan referencia a eurl.axd" en el documento 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 membresía de ASP.NET se han movido del ensamblaje System.Web.dll al ensamblaje System.Web.ApplicationServices.dll. Los tipos se trasladaron para resolver las dependencias de capas arquitectónicas entre los tipos del cliente y las SKU extendidas del .NET Framework.	Las bibliotecas de clases que se han actualizado desde versiones anteriores de ASP.NET y que usan tipos de pertenencia que se han movido podrían no compilarse cuando se usan en un proyecto de ASP.NET 4. Si es así, agregue una referencia en el proyecto de biblioteca de clases a System.Web.ApplicationServices.dll.
Cambios en el control de menú	Los cambios en el Menu control dan como resultado el siguiente comportamiento: * Si MenuRenderingMode se establece en `List`, o si MenuRenderingMode se establece en `Default` y ControlRenderingCompatibilityVersion se establece en `4.0` o después, la propiedad PopOutImageUrl no tiene ningún efecto. * Si la ruta de acceso establecida en las propiedades StaticPopOutImageUrl y DynamicPopOutImageUrl contiene una barra diagonal inversa (\), las imágenes no se muestran. (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 el StaticPopOutImageUrl o el DynamicPopOutImageUrl del control primario Menu. -o- Establezca MenuRenderingMode en `Table`, o establezca MenuRenderingMode en `Default` y ControlRenderingCompatibilityVersion en `3.5`. Esta configuración hace que el Menu control use el diseño basado en tablas HTML que usó 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 incluyó una referencia al ensamblado System.Web.Mobile.dll en el archivo raíz Web.config en la sección `assemblies` bajo `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 se incluyen en ASP.NET 4, pero están en desuso.	Si desea usar tipos de este ensamblado, agregue una referencia al ensamblado en el archivo de Web.config raíz o en un archivo de Web.config de aplicación.
Almacenamiento en caché de resultados	En ASP.NET 1.0, un error provocó que las páginas almacenadas en caché que especificaban `Location="ServerAndClient"` como una configuración de caché de salida emitieran un `Vary:` encabezado HTTP en la respuesta. Esto tuvo el efecto de indicar a los exploradores cliente que nunca almacenen en caché la página localmente. En ASP.NET 1.1, se agregó el SetOmitVaryStar método , al que se podría llamar para suprimir el `Vary:` encabezado. Sin embargo, los informes de errores sugieren que los desarrolladores no conocen el comportamiento existente `SetOmitVaryStar` . En ASP.NET 4, el `Vary:` encabezado HTTP ya no se emite a partir de respuestas que especifican la siguiente directiva: `<%@ OutputCache Location="ServerAndClient" %>` Como resultado, el SetOmitVaryStar método ya no es necesario para suprimir el `Vary:` encabezado. En las aplicaciones que especifican "ServerAndClient" para el `Location` atributo, las páginas se almacenarán en caché en el explorador sin necesidad de llamar a SetOmitVaryStar.	Si las páginas de la aplicación deben emitir `Vary:`, llame al AppendHeader método como se muestra en el ejemplo siguiente: `System.Web.HttpResponse.AppendHeader("Vary","");` Como alternativa, puede cambiar el valor del atributo de almacenamiento en caché `Location` de salida a "Server".
Análisis de páginas	El analizador de páginas para ASP.NET 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 más marcado como no válido que en versiones anteriores.	Examine los mensajes de error que se producen cuando se ejecuta una página y corrige los errores resultantes del 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 `ObsoleteAttribute` atributo .	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 `PathInfo` valor en los valores devueltos de propiedades como FilePath, AppRelativeCurrentExecutionFilePathy CurrentExecutionFilePath. En su lugar, la `PathInfo` información está disponible en PathInfo. Por ejemplo, imagine el siguiente fragmento de dirección URL: `/testapp/Action.mvc/SomeAction` En versiones anteriores de ASP.NET, HttpRequest las propiedades tienen los siguientes valores: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (vacío) En ASP.NET 4, HttpRequest las propiedades tienen en su lugar los siguientes valores: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Examine el código en busca de lugares en los que se basa en las propiedades de la HttpRequest clase para devolver información de ruta de acceso; cambie el código para reflejar los cambios en la forma 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 ASP.NET se invoca anteriormente en el ciclo de vida de la solicitud. Como consecuencia, se realiza la validación para las solicitudes que no son para archivos .aspx, como para las llamadas a servicios 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 distintos de .aspx archivos podrían producir errores de validación de solicitudes. El código personalizado que se ejecuta en la canalización de solicitudes (por ejemplo, módulos HTTP personalizados) también podría producir errores de validación de solicitudes.	Si es necesario, puede revertir al comportamiento anterior de tener solo .aspx páginas que desencadenan la validación de solicitudes mediante la siguiente configuración 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, módulos y otro código personalizado existente realiza comprobaciones de 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 el sitio web está en una carpeta que contiene un punto (.) en el nombre de la carpeta, el enrutamiento de direcciones URL no funcionará de forma confiable. Se devuelve un error HTTP 404 de algunas rutas de acceso virtuales. Esto ocurre porque 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 `Virtual Path` atributo a "/". -o- * 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 la carpeta del proyecto tiene un punto en su nombre. -o- * Cree un sitio web basado en HTTP hospedado en IIS. Los sitios web hospedados en IIS pueden tener puntos en la ruta de acceso virtual, así como en la carpeta del archivo del proyecto.
Sitios de SharePoint	Si intenta ejecutar un sitio web de ASP.NET 4 que se implementa como 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 elemento secundario de un sitio web de SharePoint.
Estándares XHTML 1.1	Para habilitar el cumplimiento de XHTML 1.1 para los nuevos sitios web, los controles de ASP.NET de .NET Framework 4 generarán HTML compatible con XHTML 1.1. Esta representación se habilita mediante la siguiente opción en el archivo Web.config dentro del `<system.Web>` elemento : `<pages controlRenderingCompatibilityVersion="4.0"/>` Esta opción se establece de forma predeterminada en 4.0. Los proyectos web que se actualizan desde Visual Studio 2008 tienen habilitada la configuración 3.5 para la compatibilidad.	Ninguno.

Núcleo

Características generales

Característica	Diferencias desde 3.5 SP1	Cambios recomendados
CardSpace	Windows CardSpace ya no se incluye en .NET Framework; se proporciona por separado.	Descargue Windows CardSpace desde el Centro de descarga de Microsoft.
Archivos de configuración	Se han realizado correcciones en el modo en que .NET Framework accede a los archivos de configuración de la aplicación.	Si el archivo de configuración de la aplicación se denomina application-name.config, cámbielo por application-name.exe.config. Por ejemplo, cambie el nombre deMyApp.config a MyApp.exe.config.
Compilador de código de C#	Las `Compiler`clases , `CompilerError`y `ErrorLevel` que estaban en el Microsoft.CSharp espacio de nombres ya no están disponibles y su ensamblado (cscompmgd.dll) ya no se incluye en .NET Framework.	Usa la clase CodeDomProvider y otras clases en el espacio de nombres System.CodeDom.Compiler. Para obtener más información, consulte Uso de CodeDOM.
Hospedaje (API no administrada)	Para mejorar las funcionalidades de hospedaje, algunas de las API de activación de hospedaje han quedado en desuso. Las características de ejecución en paralelo en proceso permiten que una aplicación cargue e inicie varias versiones de .NET Framework en el mismo proceso. Por ejemplo, puede ejecutar aplicaciones que carguen complementos (o componentes) basados en .NET Framework 2.0 SP1 y complementos basados en .NET Framework 4 en el mismo proceso. Los componentes anteriores siguen usando la versión anterior de .NET Framework y los nuevos componentes usan la nueva versión de .NET Framework.	Use las configuraciones descritas en In-Process ejecución en paralelo.
Nuevo modelo de seguridad	La directiva de seguridad de acceso de código (CAS) se ha desactivado y reemplazado por un modelo simplificado, como se describe en Cambios de seguridad en .NET Framework 4.	Es posible que se requieran modificaciones si depende del CAS en las aplicaciones. Para obtener más información, consulte Compatibilidad y migración de directivas de seguridad de acceso de código.

Fecha y hora

Espacio de nombres: System

ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias desde 3.5 SP1	Cambios recomendados
Horario de verano	Para ser coherente con el reloj del sistema, las propiedades de hora (como Local y Now) ahora usan reglas del sistema operativo en lugar de otros datos de .NET Framework para las operaciones de horario de verano.	Ninguno.
Formato de cadenas	Para admitir el formato que tiene en cuenta la referencia cultural, la estructura TimeSpan incluye nuevas sobrecargas de los métodos `ToString`, `Parse` y `TryParse`, además de los nuevos métodos `ParseExact` y `TryParseExact`.	Ninguno.

Globalización

Para obtener una lista de nuevas referencias culturales neutras y específicas, consulte Novedades de globalización y localización.

Espacio de nombres: System.Globalization

ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias desde 3.5 SP1	Cambios recomendados
Nombres de referencia cultural	Los siguientes cambios de nombre afectan a las culturas alemanas, divehi y africanas: * CurrencyEnglishName: El nombre de la moneda para la cultura alemana (Suiza) (de-CH) ha cambiado de "sFr." a "Fr.". * LongDatePattern: el patrón de fecha larga de la referencia cultural de divehi (Maldivas) (dv-MV) ha cambiado de "dd/MMMM/aaaa" a "dd/MM/aaaa". * PMDesignator: el designador P.M. de la referencia cultural de afrikáans (Sudáfrica) (af-ZA) ha cambiado de "nm" a "PM".	Tenga en cuenta los cambios en los nombres de las referencias culturales.
Parámetro LCID	Para ser coherente con el comportamiento esperado en la configuración del servidor de automatización, el CLR ya no pasa la cultura actual para el parámetro `LCID` a aplicaciones no administradas basadas en COM. En su lugar, pasa 1033 (en-us) para la referencia cultural.	No es necesario realizar modificaciones excepto para las aplicaciones nativas que requieren una referencia cultural especificada.
Tipos de culturas obsoletas	Los tipos de cultura CultureTypes y CultureTypes ahora están obsoletos. Para la compatibilidad con versiones anteriores, CultureTypes ahora devuelve referencias culturales neutras y específicas que se incluyeron con .NET Framework anterior y CultureTypes ahora devuelve una lista vacía.	Use otros valores de la CultureTypes enumeración.
Recuperar cultura	A partir de Windows 7, .NET Framework 4 recupera información de referencia cultural del sistema operativo en lugar de almacenar los datos en sí. Además, .NET Framework se sincroniza con Windows para ordenar los datos y aplicarles mayúsculas y minúsculas.	Ninguno.
Estándares Unicode 5.1	.NET Framework ahora admite todos los caracteres Unicode 5.1: una adición de aproximadamente 1400 caracteres. Entre los caracteres adicionales se incluyen nuevos símbolos, flechas, marcas diacríticas, puntuación, símbolos matemáticos, ideogramas y trazos de CJK, caracteres numéricos adicionales de malayalam y telugu, y varios caracteres de birmano, latino, árabe, griego, mongol y cirílico. Los siguientes scripts nuevos se admiten con Unicode 5.1: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu, Malayalam y Cham.	Ninguno.

Excepciones

Espacios de nombres: System, System.Runtime.ExceptionServices

ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias desde 3.5 SP1	Cambios recomendados
Excepciones para el estado de proceso dañado	CLR ya no entrega excepciones para el estado de proceso dañado a los controladores de excepciones en código administrado.	Estas excepciones indican que el estado de un proceso está dañado. No se recomienda ejecutar la aplicación en este estado. Para obtener más información, vea HandleProcessCorruptedStateExceptionsAttribute y la entrada Controlar excepciones de estado dañado en MSDN Magazine.
Excepciones del motor de ejecución	ExecutionEngineException ahora está obsoleto, ya que una excepción capturable permitirá que un proceso inestable continúe ejecutándose. Este cambio mejora la previsibilidad y la confiabilidad en el tiempo de ejecución.	Utilice un InvalidOperationException para señalar la condición.

Reflexión

Espacio de nombres: System.Reflection

ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias desde 3.5 SP1	Cambios recomendados
Algoritmos hash de ensamblado	La HashAlgorithm propiedad ahora devuelve AssemblyHashAlgorithm, porque el tiempo de ejecución no conoce el algoritmo hash del ensamblado al que se hace referencia cuando no se carga el ensamblado. (Esto se refiere al uso de la propiedad en un ensamblado de referencia como el devuelto por el método GetReferencedAssemblies).	Ninguno.
Carga de ensamblados	Para evitar la carga redundante de ensamblados y para ahorrar espacio de direcciones virtuales, CLR carga ahora ensamblados mediante solo la función Win32 `MapViewOfFile` . Ya no llama también a la función `LoadLibrary`. Este cambio afecta a las aplicaciones de diagnóstico de las maneras siguientes: * Un ProcessModuleCollection ya no contendrá módulos de una biblioteca de clases (archivo.dll), como se obtiene mediante una llamada a `Process.GetCurrentProcess().Modules`. * Las aplicaciones Win32 que usan la `EnumProcessModules` función no verán todos los módulos administrados enumerados.	Ninguno.
Declaración de tipo	La DeclaringType propiedad ahora devuelve correctamente null cuando el tipo no tiene un tipo declarante.	Ninguno.
delegados	Ahora, un delegado lanza una ArgumentNullException en lugar de una NullReferenceException cuando se pasa un valor nulo al constructor del delegado.	Asegúrese de que el control de excepciones capture ArgumentNullException.
Cambio en la ubicación de la caché global de ensamblados	Para los ensamblados de .NET Framework 4, la caché global de ensamblados se ha movido del directorio de Windows (%WINDIR%) al subdirectorio de Microsoft.Net (%WINDIR%\Microsoft.Net). Los ensamblados de versiones anteriores permanecen en el directorio anterior. La enumeración no administrada ASM_CACHE_FLAGS contiene la nueva marca `ASM_CACHE_ROOT_EX`. Este indicador obtiene la ubicación de caché de los ensamblados de .NET Framework 4, la cual se puede obtener mediante la función GetCachePath.	Ninguno, suponiendo que las aplicaciones no usen rutas de acceso explícitas a los ensamblados, lo que no es una práctica recomendada.
Herramienta Caché global de ensamblados	La Gacutil.exe (Global Assembly Cache Tool) ya no admite el visor de plugins de shell.	Ninguno.

Interoperabilidad

Espacio de nombres: System.Runtime.InteropServices

ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias desde 3.5 SP1	Cambios recomendados
Longitud del búfer (API no administrada)	Para guardar memoria, se ha cambiado la funcionalidad del `pBufferLengthOffset` parámetro para el método ICorProfilerInfo2::GetStringLayout para que coincida con el `pStringLengthOffset` parámetro . Ambos parámetros ahora apuntan a la ubicación de desplazamiento de la longitud de la cadena. La longitud del búfer se ha quitado de la representación de la clase String.	Quite cualquier dependencia de la longitud del búfer.
Depuración de JIT	Para simplificar el registro de la depuración just-in-time (JIT), el depurador de .NET Framework ahora solo usa la clave del registro AeDebug, la cual controla el comportamiento de depuración JIT en el código nativo. Este cambio da como resultado lo siguiente: * Ya no puede registrar dos depuradores diferentes para código administrado y nativo. * Ya no puede iniciar el depurador automáticamente para un proceso no interactivo, pero puede solicitar al usuario un proceso interactivo. * Ya no se le notifica cuando el depurador no se inicia o cuando no hay ningún depurador registrado que se debe iniciar. * Las directivas de inicio automático que dependen de la interactividad de la aplicación ya no se admiten.	Ajuste las operaciones de depuración según sea necesario.
Invocación de plataforma	Para mejorar el rendimiento en la interoperabilidad con código no administrado, las convenciones de llamada incorrectas en una invocación de plataforma ahora hacen que se produzca un error en la aplicación. En versiones anteriores, la capa de serialización resolvía estos errores hacia arriba en la pila.	Cuando depure las aplicaciones en Microsoft Visual Studio, se le avisará de estos errores para que pueda corregirlos. Si tiene archivos binarios que no se pueden actualizar, puede incluir el elemento <NetFx40_PInvokeStackResilience> en el archivo de configuración de la aplicación para permitir que los errores de llamada se resuelvan en la pila como en versiones anteriores. Sin embargo, esto puede afectar al rendimiento de la aplicación.
Interfaces eliminadas (API no administrada)	Para evitar confusiones para desarrolladores, se quitaron las siguientes interfaces, ya que no proporcionaron escenarios de tiempo de ejecución útiles y CLR no proporcionó ni aceptó ninguna implementación: * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImageConverter * ICorModule * IMetaDataConverter	Ninguno.

Datos

En esta sección se describen los problemas de migración para usar conjuntos de datos y clientes SQL, Entity Framework, LINQ to SQL y servidores de datos WCF (anteriormente conocidos como ADO.NET Data Services).