Problemas de migración de .NET Framework 4

Artículo
08/10/2011

En este tema se describen los problemas de migración entre .NET Framework versión 3.5 Service Pack 1 y .NET Framework versión 4. Se incluyen las correcciones, los cambios conforme a los estándares y los realizados por motivos de seguridad, así como los cambios derivados de 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 ver los cambios que podrían implicar modificaciones, vea la columna Cambios recomendados de la tabla.

En este tema se describen los cambios notables en las siguientes áreas:

ASP.NET y web
Principal
Datos
Windows Communication Foundation (WCF)
Windows Presentation Foundation (WPF)
XML

Para obtener información general de más alto nivel sobre los problemas que se describen en este tema, vea Guía de migración para .NET Framework 4.

Para obtener información sobre los problemas de migración posteriores a la versión Beta 2, vea Migration Issues for .NET Framework 4 Applications: Beta 2 to RTM.

Para obtener información sobre las características nuevas, vea Lo nuevo en .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 del explorador	Los archivos de definición del explorador se han actualizado a fin de 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 otros más nuevos, como Google Chrome y Apple iPhone. Si su aplicación contiene definiciones de explorador personalizadas que heredan de alguna de las definiciones del explorador que se han quitado, aparecerá un error. Los archivos de definición del explorador controlan el objeto HttpBrowserCapabilities (expuesto por la propiedad Request.Browser de la página). Por consiguiente, la información que se devuelve al tener acceso a una propiedad de este objeto en ASP.NET 4 podría ser diferente de la que se devolvía en una versión anterior de ASP.NET.	Si su aplicación se basa en los archivos de definición del explorador anteriores, puede copiarlos desde la siguiente carpeta: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Copie los archivos en la carpeta \CONFIG\Browsers 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, vea el sitio web https://www.asp.net/mobile.
Aplicaciones secundarias que se ejecutan en diversas versiones de ASP.NET	Es posible que en las aplicaciones de ASP.NET 4 que están configuradas como aplicaciones secundarias de otras que se ejecutan en versiones anteriores de ASP.NET se produzcan errores de configuración o compilación que impidan que estas aplicaciones se inicien correctamente. El error concreto que se produce dependerá de si la aplicación se ejecuta bajo IIS 6.0 o bajo 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 deben realizarse, vea la sección "ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications" del documento ASP.NET 4 Beta 2 Breaking Changes en el sitio web de ASP.NET.
Cambios de ClientID	El nuevo valor ClientIDMode de ASP.NET 4 permite especificar cómo ASP.NET genera el atributo id para los elementos HTML. En las 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 servidor web ASP.NET.	Si utiliza Visual Studio 2010 para actualizar la aplicación a partir de ASP.NET 2.0 o ASP.NET 3.5, la herramienta agrega automáticamente un valor al archivo Web.config que conserva el comportamiento de las versiones anteriores de .NET Framework. Sin embargo, si actualiza una aplicación cambiando el grupo de aplicaciones en IIS de modo que su destino sea .NET Framework 4, ASP.NET utilizará el nuevo modo de manera 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 agregaron en ASP.NET 3.5 utilizan y modelo de seguridad de acceso del código (CAS) de .NET Framework 1.1 y .NET Framework 2.0. Sin embargo, la implementación de CAS en ASP.NET 4 se ha remodelado en gran medida. Como resultado, se podría producir un error con varias excepciones de seguridad en las aplicaciones ASP.NET de confianza parcial que se basan en el código de confianza que se ejecuta en la memoria caché global de ensamblados. También podrían producirse errores con 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 confianza parcial ASP.NET 4 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 siguiente ejemplo: <trust level= "Medium" legacyCasModel="true" /> Nota sobre la seguridad Revertir al modelo de CAS anterior podría suponer una reducción de la seguridad. Para obtener más información acerca del 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 (el archivo machine.config y el archivo raíz Web.config) para .NET Framework y ASP.NET 4 se han actualizado de modo que incluyan la mayoría de la información de configuración del código reutilizable que se encontró en los archivos Web.config de aplicación en ASP.NET 3.5. Debido a la complejidad de los sistemas de configuración IIS 7 e IIS 7.5 administrados, ejecutar aplicaciones ASP.NET 3.5 en ASP.NET 4 y con IIS 7 e IIS 7.5 puede dar lugar a 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 proyecto en Visual Studio 2010. Visual Studio 2010 modifica automáticamente el archivo Web.config de la aplicación de ASP.NET 3.5 de modo que contenga los valores adecuados para ASP.NET 4. Sin embargo, puede ejecutar aplicaciones ASP.NET 3.5 aplicaciones mediante .NET Framework 4 sin recompilarlas. En tal 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 con IIS 7 o IIS 7.5. La modificación concreta 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 posibles combinaciones de software a las que afecta este cambio y cómo resolver los problemas con combinaciones concretas, vea la sección "Configuration Errors Related to New ASP.NET 4 Root Configuration" del documento ASP.NET 4 Breaking Changes en el sitio web de ASP.NET.
Presentación de controles	En versiones anteriores de ASP.NET, algunos controles emitían un marcado que no se podía deshabilitar. De manera predeterminada, este tipo de marcado ya no se genera en ASP.NET 4. Los cambios de presentación afectan a los siguientes controles: Los controles Image e ImageButton ya no presentan un atributo border="0". La clase BaseValidator y los controles de validación que se derivan de ella ya no presentan el texto en rojo de forma predeterminada. El control HtmlForm no presenta un atributo name. El control Table ya no presenta un atributo border="0". Los controles que no están diseñados para datos proporcionados por el usuario (por ejemplo, el control Label) ya no presentan el atributo disabled="disabled" si su propiedad Enabled está establecida en false (o si heredan este valor de un control contenedor).	Si utiliza Visual Studio 2010 para actualizar la aplicación desde ASP.NET 2.0 o ASP.NET 3.5, la herramienta agrega automáticamente un valor al archivo Web.config que conserva la presentación heredada. Sin embargo, si actualiza una aplicación cambiando el grupo de aplicaciones en IIS de modo que su destino sea .NET Framework 4, ASP.NET utilizará el nuevo modo de presentación de manera predeterminada. Para deshabilitar el nuevo modo de presentación, agregue el valor siguiente al archivo Web.config: <pages controlRenderingCompatibilityVersion="3.5" />
Controladores de eventos en documentos predeterminados	ASP.NET 4 presenta el valor de atributo action del elemento form de HTML como una cadena vacía cuando se realiza una solicitud a una dirección URL sin extensiones que tiene asignado un documento predeterminado. El las versiones anteriores de ASP.NET, una solicitud a https://contoso.com habría dado lugar a una solicitud a Default.aspx. En ese documento, la etiqueta form de apertura se presentaría como en el siguiente ejemplo: <form action="Default.aspx" /> En ASP.NET 4, una solicitud a https://contoso.com también da lugar a una solicitud a Default.aspx, pero ahora ASP.NET presenta la etiqueta form de apertura de HTML como en el siguiente ejemplo: <form action="" /> Cuando el atributo action es una cadena vacía, el objeto de IIS DefaultDocumentModule crea una solicitud secundaria a Default.aspx. En la mayoría de las condiciones, esta solicitud secundaria es transparente al código de aplicación y la página Default.aspx se ejecuta normalmente. Sin embargo, si se produjera una interacción entre el código administrado y el modo integrado de IIS 7 o IIS 7.5, las páginas .aspx administradas podrían dejar de funcionar correctamente durante la solicitud secundaria. Si se cumplen las siguientes condiciones, la solicitud secundaria a un documento .aspx predeterminado producirá un error o un comportamiento inesperado: Se envía una página .aspx al explorador con el atributo action del elemento de form establecido en "". El formulario se envía de vuelta a ASP.NET. Un módulo HTTP administrado lee alguna 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 y copie 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 estén ejecutando en el modo integrado de IIS 7 o IIS 7.5. El objeto DefaultDocumentModule de IIS se ejecuta en un momento dado y crea una solicitud secundaria al documento Default.aspx. Sin embargo, como una parte del código administrado ha leído ya el cuerpo de la entidad, este último no está disponible para enviárselo a la solicitud secundaria. Cuando la canalización HTTP se ejecuta para la solicitud secundaria, el controlador para los archivos .aspx se ejecuta durante la fase de ejecución de controlador. Dado que no hay ningún cuerpo de la entidad, no hay ninguna variable de formulario y ni ningún estado de vista. Por consiguiente, no hay ninguna información disponible que permita al controlador de la página .aspx determinar qué evento se debe generar (si lo hubiera). Como resultado, no se ejecuta ninguno de los controladores de eventos de postback de la página .aspx afectada.	Para obtener información sobre las maneras de evitar los problemas que podrían surgir a consecuencia de este cambio, vea "Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode" en el documento ASP.NET 4 Breaking Changes del sitio web de ASP.NET.
Algoritmo de hash	ASP.NET utiliza algoritmos de cifrado y de hash para ayudar a proteger datos como las cookies de autenticación de formularios y el estado de vista. De forma predeterminada, ASP.NET 4 utiliza el algoritmo HMACSHA256 para las operaciones hash con cookies y con el estado de vista. En las versiones anteriores de ASP.NET se utilizaba el algoritmo HMACSHA1 anterior.	Si ejecuta aplicaciones en que se combinan ASP.NET 2.0 y ASP.NET 4, donde hay datos como cookies de autenticación de formularios que tiene que funcionar en todas las versiones de .NET Framework, la aplicación web de ASP.NET 4 se debe configurar de modo que utilice el algoritmo HMACSHA1 anterior agregando el siguiente valor al archivo Web.config: <machineKey validation="SHA1" />
Hospedar controles en Internet Explorer	Los controles de Windows Forms ya no pueden hospedarse en Internet Explorer, ya que existen soluciones más adecuadas para el hospedaje en Web de los controles. Por este motivo, se han quitado de .NET Framework los ensamblados IEHost.dll e IEExec.exe.	Puede usar las tecnologías siguientes para desarrollar 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, vea Out-of-Browser Support. Puede crear una aplicación del explorador XAML (XBAP) para aprovechar las capacidades de WPF (requiere .NET Framework en 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 de modo que codifiquen el carácter de comilla simple (') como sigue: 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.	Examine su código para buscar los lugares donde se utilizan los métodos UrlEncode y HtmlEncode, y asegúrese de que el cambio de codificación no dé lugar a un cambio que afecte a su aplicación.
Errores HttpException en las aplicaciones ASP.NET 2.0	Tras habilitar ASP.NET 4 en IIS 6, en las aplicaciones ASP.NET 2.0 que se ejecuten en IIS 6 (en Windows Server 2003 o Windows Server 2003 R2) pueden producirse errores como los siguientes: System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.	Si ASP.NET 4 no se necesita para ejecutar el sitio web, cambie las asociaciones del sitio para que use en su lugar ASP.NET 2.0. O bien Si se necesita ASP.NET 4 para ejecutar el sitio web, mueva los directorios virtuales secundarios de ASP.NET 2.0 a un sitio web distinto 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" en el documento ASP.NET 4 Breaking Changes, en el sitio web de ASP.NET.
Tipos de pertenencia	Algunos tipos (por ejemplo, System.Web.Security.MembershipProvider) que se utilizan en la pertenencia a ASP.NET se han movido del ensamblado System.Web.dll al ensamblado System.Web.ApplicationServices.dll. Los tipos se han transferido para resolver las dependencias de los niveles arquitectónicos entre los tipos del cliente y las SKU extendidas de .NET Framework.	Es posible que las bibliotecas de clases que se han actualizado a partir de versiones anteriores de ASP.NET y que usan tipos de pertenencia que se han movido no puedan compilarse correctamente cuando se usan en un proyecto de ASP.NET 4. En este caso, agregue una referencia del proyecto de biblioteca de clases a System.Web.ApplicationServices.dll.
Cambios del control Menu	Los cambios realizados en el control Menu pueden producir el comportamiento siguiente: Si System.Web.UI.WebControls.MenuRenderingMode se establece en List o si System.Web.UI.WebControls.MenuRenderingMode se establece en Default y PagesSection.ControlRenderingCompatibilityVersion se establece en 4.0 o una versión posterior, la propiedad MenuItem.PopOutImageUrl no tiene ningún efecto. Si la ruta de acceso que se establece en las propiedades Menu.StaticPopOutImageUrl y Menu.DynamicPopOutImageUrl contiene una barra diagonal inversa (\), no se presenta la imagen. (En versiones anteriores de ASP.NET, la ruta de acceso podía incluir una barra diagonal inversa).	En lugar de establecer la propiedad MenuItem.PopOutImageUrl en cada uno de los elementos de menú, establezca la propiedad Menu.StaticPopOutImageUrl o Menu.DynamicPopOutImageUrl del control System.Web.UI.WebControls.Menu primario. O bien Establezca System.Web.UI.WebControls.MenuRenderingMode en Table o System.Web.UI.WebControls.MenuRenderingMode en Default y establezca PagesSection.ControlRenderingCompatibilityVersion en 3.5. Esta configuración hace que el control Menu use el diseño basado en tablas HTML que se utilizaba en versiones anteriores de ASP.NET. Si la ruta de acceso de la propiedad Menu.StaticPopOutImageUrl o Menu.DynamicPopOutImageUrl contiene una barra diagonal inversa (\), sustitúyala por un carácter de barra diagonal (/).
Ensamblado móvil del archivo Web.config	En las versiones anteriores de ASP.NET, se incluía una referencia al ensamblado System.Web.Mobile.dll en el archivo Web.config raíz de la sección assemblies, bajo system.web/compilation. Para mejorar el rendimiento, la referencia a este ensamblado se ha quitado. Nota El ensamblado de System.Web.Mobile.dll y los controles ASP.NET para dispositivos móviles están incluidos en ASP.NET 4, pero están en desuso.	Si desea usar tipos de este ensamblado, agregue una referencia al ensamblado en el archivo Web.config raíz o en un archivo Web.config de la aplicación.
Almacenar resultados en la memoria caché	En ASP.NET 1.0, un error hacía que las páginas almacenadas en memoria caché que especificaban Location="ServerAndClient" como valor de caché de resultados emitieran un encabezado Vary:* de HTTP en la respuesta. Con ello se indicaba a los exploradores cliente que nunca almacenaran la página en la memoria caché local. En ASP.NET 1.1, se agregó el método HttpCachePolicy.SetOmitVaryStar, al que se podía llamar para suprimir el encabezado Vary:. Sin embargo, los informes de errores sugieren que los desarrolladores desconocen el comportamiento del método SetOmitVaryStar existente. En ASP.NET 4, el encabezado Vary: de HTTP ya no se emite a partir de las respuestas que especifican la siguiente directiva: <%@ OutputCache Location="ServerAndClient" %> Como resultado, ya no se necesita el método HttpCachePolicy.SetOmitVaryStar para suprimir el encabezado Vary:*. En las aplicaciones que especifican "ServerAndClient" para el atributo Location, las páginas se podrán almacenar en la memoria caché del explorador sin tener que llamar a HttpCachePolicy.SetOmitVaryStar.	Si las páginas de la aplicación deben emitir Vary:, llame al método HttpResponse.AppendHeader como se muestra en el siguiente ejemplo: HttpResponse.AppendHeader("Vary",""); Como alternativa, puede cambiar el valor del atributo Location de almacenamiento en caché de los resultados a "Server".
Análisis de páginas	El analizador de páginas de ASP.NET Web Pages (archivos .aspx) y controles de usuario (archivos .ascx) es más estricto en ASP.NET 4 que en versiones anteriores de ASP.NET y señala más cantidad de marcado como no válido que en las versiones anteriores.	Examine los mensajes de error que aparecen cuando se ejecuta una página y corrija los errores derivados del marcado no válido.
Tipos de Passport	La compatibilidad con Passport integrada en ASP.NET 2.0 ha quedado obsoleta y ya no se admite debido a los cambios realizados en Passport (ahora SDK de Live ID). En consecuencia, los tipos relacionados con Passport de System.Web.Security se marcan ahora con el atributo ObsoleteAttribute.	Cambie todo el código que tenga que utilice tipos de Passport en el espacio de nombres System.Web.Security (por ejemplo, System.Web.Security.PassportIdentity) de modo que utilice 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 de propiedades como HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath y HttpRequest.CurrentExecutionFilePath. En cambio, la información de PathInfo está disponible en HttpRequest.PathInfo. Por ejemplo, tomemos el siguiente fragmento de una dirección URL: /testapp/Action.mvc/SomeAction El las versiones anteriores de ASP.NET, las propiedades System.Web.HttpRequest tienen los siguientes valores: HttpRequest.FilePath: /testapp/Action.mvc/SomeAction HttpRequest.PathInfo: (vacío) En cambio, en ASP.NET 4, las propiedades System.Web.HttpRequest tienen los siguientes valores: HttpRequest.FilePath: /testapp/Action.mvc HttpRequest.PathInfo: SomeAction	Examine el código para hallar dónde se ha basado en las propiedades de la clase System.Web.HttpRequest para devolver información de ruta de acceso; cambie el código para reflejar los cambios respecto al modo en que se devuelve la información de ruta de acceso.
Validación de solicitudes	Para mejorar la validación de solicitudes, en ASP.NET esta se invoca en un punto anterior del ciclo de vida de la solicitud. En consecuencia, la validación de solicitudes se ejecuta para aquellas solicitudes que no sean para archivos .aspx, como para las llamadas al servicio Web y para 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 para recursos que no sean archivos .aspx podrían producir errores de la validación de solicitudes. El código personalizado que se ejecuta en la canalización de solicitudes (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 que solamente las páginas .aspx activaban la validación de solicitudes; para ello, utilice el siguiente valor en el archivo de configuración web: <httpRuntime requestValidationMode="2.0" /> Nota sobre la seguridad Si revierte al anterior comportamiento, asegúrese de que todo el código de los controladores y los módulos existentes, así como cualquier otro código personalizado, compruebe las entradas HTTP que podrían no ser seguras y podrían ser vectores de ataque XSS.
Enrutamiento	Si crea un sitio web del sistema de archivos de Visual Studio 2010 y el sitio web está en una carpeta cuyo nombre contiene un punto (.), el enrutamiento de direcciones URL no funcionará de manera confiable. Se devolverá un error HTTP 404 de algunas rutas de acceso virtuales. Esto se produce porque Visual Studio 2010 inicia el servidor de desarrollo de Visual Studio (Cassini) utilizando una ruta de acceso incorrecta en el directorio virtual raíz.	En la página Propiedades del sitio web basado en archivos, cambie el atributo Virtual Path por "/". 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 aunque el nombre de la carpeta de proyecto contenga 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 archivo de proyecto.
Sitios de SharePoint	Si intenta ejecutar un sitio web de ASP.NET 4 implementado como un elemento secundario de un sitio web de SharePoint que contiene un nivel de confianza parcial personalizado denominado WSS_Minimal, aparecerá el siguiente error: Could not find permission set named 'ASP.Net'.	Actualmente, ninguna versión de SharePoint es compatible con ASP.NET. Por tanto, no debería intentar ejecutar un sitio web de ASP.NET 4 como un elemento secundario de un sitio web de SharePoint.
Normas XHTML 1.1	Para habilitar la conformidad con XHTML 1.1 en los nuevos sitios web, los controles ASP.NET de .NET Framework 4 generarán código HTML conforme a XHTML 1.1. Esta representación se habilita utilizando la siguiente opción del archivo Web.config: <system.Web> <pages controlRenderingCompatibilityVersion="4.0"/> </system.Web> De forma predeterminada, esta opción está establecida en 4.0. Los proyectos web que se actualicen a Visual Studio desde Visual Studio 2008 tendrán la configuración 3.5 habilitada para tener compatibilidad.	Ninguno.

Volver al principio

Principal

Características generales

Característica	Diferencias respecto a 3.5 SP1	Cambios recomendados
CardSpace	Windows CardSpace ya no se incluye en .NET Framework, sino que se proporciona por separado.	Puede descargar Windows CardSpace desde el Centro de descarga de Microsoft.
Archivos de configuración	Se han realizado correcciones en el modo en el que .NET Framework obtiene acceso a los archivos de configuración de la aplicación.	Si el nombre del archivo de configuración de la aplicación es nombreDeAplicación.config, cámbielo por nombreDeAplicación.exe.config. Por ejemplo, cambie MyApp.config por MyApp.exe.config.
Compilador de código C#	Las clases Compiler, CompilerError y ErrorLevel que estaban en el espacio de nombres Microsoft.CSharp ya no están disponibles. Su ensamblado (cscompmgd.dll) tampoco está incluido ya en .NET Framework.	Use la clase CodeDomProvider y otras clases del espacio de nombres System.CodeDom.Compiler. Para obtener más información, vea Usar CodeDOM.
Hospedaje (API no administrada)	Para mejorar las capacidades de hospedaje, algunas de las API de activación de hospedaje se han desusado. 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, se pueden ejecutar aplicaciones que cargan en el mismo proceso complementos (o componentes) basados en .NET Framework 2.0 SP1 y complementos basados en .NET Framework 4. Los componentes más antiguos siguen usando la versión anterior de .NET Framework y los nuevos componentes emplean la nueva versión de .NET Framework.	Utilice las configuraciones descritas en Ejecución en paralelo y en proceso.
Nuevo modelo de seguridad	La directiva de seguridad de acceso del código (CAS) se ha desactivado y reemplazado por un modelo simplificado, tal y como se describe en Cambios de seguridad en .NET Framework 4.	Puede que se necesiten modificaciones si sus aplicaciones dependen de CAS. Para obtener más información, vea Compatibilidad con la directiva de seguridad de acceso del código y migración.

Volver al principio

Fecha y hora

Espacio de nombres: System; ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias respecto a 3.5 SP1	Cambios recomendados
Horario de verano	Para que sean coherentes con el reloj del sistema, ahora las propiedades de tiempo (como TimeZoneInfo.Local y DateTime.Now) utilizan reglas del sistema operativo, en lugar de otros datos de .NET Framework, para las operaciones del horario de verano.	Ninguno.
Aplicar formato a cadenas	Para admitir el formato dependiente de la referencia cultural, la estructura TimeSpan incluye nuevas sobrecargas de los métodos ToString, TryParse y Parse, además de nuevos métodos TryParseExact y ParseExact.	Ninguno.

Volver al principio

Globalización

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

Espacio de nombres: System.Globalization; ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias respecto a 3.5 SP1	Cambios recomendados
Nombres de referencia cultural	Los siguientes cambios del nombre afectan a las referencias culturales de alemán, divehi y africanas: CurrencyEnglishName: el nombre de divisa de la referencia cultural Alemán (Suiza) (de-CH) ha cambiado de "sFr." a "Fr.". LongDatePattern: el modelo de fecha larga de la referencia cultural Divehi (Maldivas) (dv-MV) ha cambiado de "dd/MMMM/aaaa" a "dd/MM/aaaa". PMDesignator: el designador p. m. de la referencia cultural "Afrikáans (Sudáfrica)" (af-ZA) ha cambiado de "nm" a "PM".	Tenga en cuenta los cambios de los nombres de las referencias culturales.
Parámetro LCID	Para que sea coherente con el comportamiento esperado en las configuraciones de servidor de automatización, el CLR ya no pasa la referencia cultural actual para el parámetro LCID a las aplicaciones no administradas basadas en COM. En cambio, pasa 1033 (en-us) para la referencia cultural.	No se necesita ninguna modificación, salvo para las aplicaciones nativas que requieren una referencia cultural concreta.
Tipos de referencia cultural obsoletos	Ahora, los tipos FrameworkCultures y WindowsOnlyCultures de referencia cultural están obsoletos. Con fines de compatibilidad con versiones anteriores, ahora FrameworkCultures devuelve las referencias culturales neutrales y concretas que se incluían con la versión anterior de .NET Framework, y WindowsOnlyCultures devuelve una lista vacía.	Use otros valores de la enumeración CultureTypes.
Recuperar la referencia cultural	A partir de Windows 7, .NET Framework 4 recupera la 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 y determinar la grafía de los datos.	Ninguno.
Normas de Unicode 5.1	.NET Framework admite ahora todos los caracteres Unicode 5.1, lo que ha supuesto la adición de unos 1400 caracteres. Los caracteres adicionales incluyen nuevos símbolos, flechas, signos diacríticos, puntuación, símbolos matemáticos, trazos de CJK e ideogramas, caracteres numéricos de malayo y telugu, así como varios caracteres birmanos, latinos, árabes, griegos, mongoles y cirílicos. Los siguientes alfabetos nuevos se admiten con Unicode 5.1: sudanés, lepcha, ol chiki, vai, saurashtra, kayah li, rejang, gurmukhi, oriya, tamil, telugu y caracteres de malayo y cham.	Ninguno.

Volver al principio

Excepciones

Espacios de nombres: System, System.Runtime.ExceptionServices; ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias respecto a 3.5 SP1	Cambios recomendados
Excepciones del estado de proceso dañado	CLR ya no proporciona excepciones del estado de proceso dañado a los controladores de excepciones en código administrado.	Estas excepciones indican que el estado de un proceso se ha dañado. No resulta recomendable que la aplicación se ejecute en este estado. Para obtener más información, vea HandleProcessCorruptedStateExceptionsAttribute y la entrada Handling Corrupted State Exceptions del blog CLR Inside Out.
Excepciones de motor de ejecución	ExecutionEngineException ahora está obsoleto, porque una excepción que se puede detectar permitirá que un proceso inestable se siga ejecutando. Este cambio mejora previsibilidad y confiabilidad en el runtime.	Utilice InvalidOperationException para indicar la condición.

Excepciones del estado de proceso dañado

CLR ya no proporciona excepciones del estado de proceso dañado a los controladores de excepciones en código administrado.

Estas excepciones indican que el estado de un proceso se ha dañado. No resulta recomendable que la aplicación se ejecute en este estado.

Para obtener más información, vea HandleProcessCorruptedStateExceptionsAttribute y la entrada Handling Corrupted State Exceptions del blog CLR Inside Out.

Excepciones de motor de ejecución

ExecutionEngineException ahora está obsoleto, porque una excepción que se puede detectar permitirá que un proceso inestable se siga ejecutando. Este cambio mejora previsibilidad y confiabilidad en el runtime.

Utilice InvalidOperationException para indicar la condición.

Volver al principio

Reflexión

Espacio de nombres: System.Reflection; ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias respecto a 3.5 SP1	Cambios recomendados
Algoritmos hash de ensamblados	La propiedad AssemblyName.HashAlgorithm ahora devuelve AssemblyHashAlgorithm.None, porque el runtime no conoce el algoritmo hash del ensamblado al que se hace referencia cuando no se ha cargado el ensamblado. (Esto hace referencia al uso de la propiedad en un ensamblado al que se hace referencia, como el devuelto por el método Assembly.GetReferencedAssemblies.)	Ninguno.
Carga de ensamblados	Para evitar las cargas redundantes de ensamblados y ahorrar espacio de direcciones virtuales, ahora el CLR carga los ensamblados utilizando únicamente la MapViewOfFile de Win32. Ya no llama también a la función LoadLibrary. Este cambio afecta a las aplicaciones de diagnóstico de las siguientes maneras: Una colección ProcessModuleCollection ya no contendrá ningún módulo de una biblioteca de clases (archivo .dll), tal y como se obtiene de una llamada a Process.GetCurrentProcess().Modules. Las aplicaciones Win32 que utilizan la función EnumProcessModules no verán todos los módulos administrados de la lista.	Ninguno.
Tipo declarativo	Ahora, la propiedad Type.DeclaringType devuelve correctamente null cuando el tipo no tiene un tipo declarativo.	Ninguno.
Delegados	Ahora, un delegado produce ArgumentNullException en lugar de NullReferenceException cuando se pasa un valor null al constructor del delegado.	Asegúrese de que el control de excepciones detecte ArgumentNullException.
Cambio de ubicación de caché global de ensamblados	Para los ensamblados .NET Framework 4, la memoria caché global de ensamblados se ha movido del directorio de Windows (%WINDIR%) al subdirectorio de Microsoft.Net (%WINDIR%\Microsoft.Net). Los ensamblados de las versiones anteriores permanecen en el directorio anterior. La enumeración ASM_CACHE_FLAGS no administrada contiene la nueva marca ASM_CACHE_ROOT_EX. Esta marca obtiene la ubicación en caché para los ensamblados de .NET Framework 4, que puede obtener la función GetCachePath.	Ninguno, siempre que las aplicaciones no utilicen rutas de acceso explícitas a los ensamblados, una práctica que no se recomienda.
Herramienta Caché global de ensamblados	Gacutil.exe (Herramienta Caché global de ensamblados) ya no admite el visor de complemento del shell.	Ninguno.

Interoperabilidad

Espacio de nombres: System.Runtime.InteropServices; ensamblado: mscorlib (en mscorlib.dll)

Característica	Diferencias respecto a 3.5 SP1	Cambios recomendados
Longitud de búfer (API no administrada)	Para ahorrar memoria, la funcionalidad del parámetro pBufferLengthOffset del método ICorProfilerInfo2::GetStringLayout se ha cambiado de modo que coincida con el parámetro pStringLengthOffset. Ahora, ambos parámetros señalan a la ubicación de desplazamiento de la longitud de la cadena. La longitud de búfer se ha quitado de la representación de la clase de cadena.	Quite cualquier dependencia de la longitud de búfer.
Depuración JIT	Para simplificar el registro para la depuración Just-In-Time (JIT), el depurador de .NET Framework utiliza solamente la clave del Registro AeDebug, que controla ahora el comportamiento de depuración JIT para el código nativo. Este cambio da lugar a lo siguiente: Ya no se pueden registrar dos depuradores diferentes para el código administrado y nativo. Ya no se puede iniciar automáticamente el depurador para un proceso no interactivo, pero sí se puede preguntar al usuario para un proceso interactivo. Ya no se le notifica cuando el depurador no se inicia ni cuando no hay ningún depurador registrado que deba iniciarse. 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 el código no administrado, ahora las convenciones de llamada incorrectas en una invocación de plataforma causan un error en la aplicación. En las versiones anteriores, el nivel de cálculo de referencias resolvía estos errores ascendiendo por la pila.	Al depurar las aplicaciones en Microsoft Visual Studio 2010, se le avisará de estos errores para que pueda corregirlos. Si tiene binarios que no se pueden actualizar, puede incluir el elemento <NetFx40_PInvokeStackResilience> en el archivo de configuración de la aplicación para permitir la resolución de los errores de llamada ascendiendo por la pila, como en las versiones anteriores. Sin embargo, esto puede afectar al rendimiento de la aplicación.
Interfaces quitadas (API no administrada)	Para evitar confusiones al desarrollador, se han quitado las siguientes interfaces, porque no proporcionaban ningún escenario útil en tiempo de ejecución y el CLR no proporcionaba ni aceptaba ninguna implementación: INativeImageINativeImageDependency INativeImageInstallInfo INativeImageEvaluate INativeImageConverter ICorModule IMetaDataConverter	Ninguno.

Volver al principio

Datos

En esta sección se describen los problemas de migración que se producen al usar conjuntos de datos y clientes SQL, Entity Framework, LINQ to SQL y Servidores de datos de WCF (anteriormente conocido como Servicios de datos de ADO.NET).