Problemas de migración de .NET Framework 4

.NET Framework 4

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:

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.

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 http://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 de seguridadNota 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 http://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 http://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:

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 &#39;.

  • 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:

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.

NotaNota
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:

En cambio, en ASP.NET 4, las propiedades System.Web.HttpRequest tienen los siguientes valores:

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 de seguridadNota 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

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.

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

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).

DataSet y cliente SQL

En la tabla siguiente se describen las mejoras realizadas en características que anteriormente presentaban limitaciones u otros problemas.

Espacios de nombres: System.Data, System.Data.Objects.DataClasses, System.Data.SqlClient; ensamblados: System.Data (en System.Data.dll), System.Data.Entity (en System.Data.Entity.dll)

Característica

Diferencias respecto a 3.5 SP1

Escenarios de POCO

La interfaz System.Data.Objects.DataClasses.IRelatedEnd tiene nuevos métodos para mejorar su utilidad en los escenarios de tipos de objetos CLR antiguos sin formato (POCO). Estos nuevos métodos toman como parámetro un objeto Object, en lugar de una entidad IEntityWithRelationships.

Edición de filas

El método IndexOf, tal y como lo implementa la clase DataView, ahora devuelve correctamente el valor de la fila que se edita, en lugar de devolver -1.

Eventos

Ahora, el evento DataRowView.PropertyChanged se genera cuando una fila se encuentra en estado modificado y se llama al método RejectChanges. Este cambio lo facilita la creación de controles de IU que exponen el contenido de un objeto DataSet.

Excepciones

El método Prepare genera ahora una excepción InvalidOperationException en lugar de una excepción NullReferenceException cuando no hay ninguna conexión establecida o abierta.

Asignación de vistas

Los errores de asignación de las vistas de consulta se detectan ahora en tiempo de diseño, en lugar de producir una excepción NullReferenceException en tiempo de ejecución.

La validación de asignaciones detecta ahora el error, en función del cual ahora se asignan dos conjuntos de asociaciones de esquemas conceptuales (CSDL) a la misma columna.

Transacciones

Si una aplicación intenta ejecutar una instrucción en una conexión una vez completada una transacción (incluso si se anuló o revirtió), ahora se produce una excepción InvalidOperationException. En las versiones anteriores no se producía una excepción y se permitía la ejecución de más comandos aunque se hubiera anulado una transacción.

Volver al principio

Entity Framework

En la tabla siguiente se describen las mejoras realizadas en características que anteriormente presentaban limitaciones u otros problemas.

Espacios de nombres: System.Data, System.Data.Objects y System.Data.Objects.DataClasses; ensamblado: System.Data.Entity (en System.Data.Entity.dll)

Característica

Diferencias respecto a 3.5 SP1

Objetos entidad

Ahora, existe paridad entre el método ObjectContext.Detach y el estado del objeto entidad cuando se llama al método ObjectContext.SaveChanges. Esta coherencia mejorada evita que se produzcan excepciones inesperadas.

Entity SQL

Se han mejorado las reglas para la resolución de identificadores en Entity SQL.

El analizador de Entity SQL dispone de una lógica mejorada para resolver identificadores con varias partes.

Anotaciones estructurales

Entity Framework ahora reconoce las anotaciones estructurales.

Consultas

Se han realizado las siguientes mejoras en las consultas:

  • Una consulta GroupBy que utilice una clave null en una colección vacía no devolverá ninguna fila, con independencia de que haya más selecciones en la consulta.

  • Ahora, las consultas SQL generadas en LINQ y Entity-SQL tratan de manera predeterminada los parámetros de cadena como valores no Unicode.

Volver al principio

LINQ to SQL

En la tabla siguiente se describen las mejoras realizadas en características que anteriormente presentaban limitaciones u otros problemas.

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

Característica

Diferencias respecto a 3.5 SP1

Eventos

Ahora, una colección System.Data.Linq.EntitySet<TEntity> genera el evento ListChanged para las operaciones de agregar y quitar si EntitySet<TEntity> está descargado, además de generar el evento cuando se carga la colección.

Consultas

Skip(0) ya no se omite en consultas de LINQ to SQL. Por tanto, las consultas que tienen este método podrían comportarse de manera diferente. Por ejemplo, en algunos casos, se necesita una cláusula OrderBy con Skip(0). Por tanto, la consulta producirá ahora una excepción NotSupportedException si no se incluye la cláusula OrderBy.

Volver al principio

Servicios de datos de WCF

En la tabla siguiente se describen las mejoras realizadas en características que anteriormente presentaban limitaciones u otros problemas.

Espacios de nombres: System.Data.Services, System.Data.Services.Client, System.Data.Services.Common y System.Data.Services.Providers; ensamblados: System.Data.Services (en System.Data.Services.dll) y System.Data.Services.Client (en System.Data.Services.Client.dll)

Característica

Diferencias respecto a 3.5 SP1

Contenido binario por lotes

Los servicios de datos de WCF admiten el contenido binario por lotes en las solicitudes y las respuestas.

Interceptadores de cambios

Ahora, los interceptadores de cambios se ejecutan para una solicitud de eliminación.

Un interceptador de cambios es un método que se ejecuta cada vez que el servidor recibe una solicitud de modificar una entidad del conjunto de entidades. Se ejecuta antes de que se ejecute la solicitud entrante. El interceptador de cambios proporciona acceso a la entidad que se va a cambiar y a la operación que se realiza con ella.

Excepciones

Las siguientes condiciones producen ahora excepciones más útiles en lugar de NullReferenceException:

En las aplicaciones, debe cambiar el control de excepciones para que detecte las nuevas excepciones.

Headers

Se han realizado las siguientes mejoras en los encabezados:

  • Los servicios de datos de WCF rechazan ahora correctamente un encabezado eTag que tenga un valor no especificado.

  • Ahora, los servicios de datos de WCF devuelven un error y no ejecutan la solicitud si se trata de una solicitud de eliminación de un vínculo y hay un encabezado if-* en la solicitud.

  • Ahora, los servicios de datos de WCF devuelven un error al cliente en el formato (Atom, JSON) que el cliente solicitó en el encabezado Accept.

Lector de JSON

Ahora, al procesar las cargas de JSON enviadas a un servicio de datos de WCF, el lector de la notación de objetos JavaScript (JSON) devuelve un error correctamente cuando lee el carácter de escape de barra diagonal inversa único ("\").

Combinaciones

Se han realizado las siguientes mejoras en la enumeración MergeOption:

  • La opción de combinación AppendOnly ya no modifica la entidad en el cliente como resultado de cualquier respuesta subsiguiente de un servicio de datos.

  • Ahora, la opción PreserveChanges es coherente con las actualizaciones basadas en procedimientos almacenados y SQL dinámico.

Solicitudes

Ahora se llama al método DataService<T>.OnStartProcessingRequest antes de que se procese una solicitud de servicios de datos. Esto permite que la solicitud funcione correctamente en los servicios ServiceOperation.

Flujos

Los servicios de datos de WCF ya no cierran la secuencia subyacente para las operaciones de lectura y escritura.

URI

Se ha corregido el uso de caracteres de escape en las URI con los servicios de datos de WCF.

En la tabla siguiente se describen las mejoras realizadas en características que anteriormente presentaban limitaciones u otros problemas.

Característica

Diferencias respecto a 3.5 SP1

Archivos de configuración

Para habilitar la herencia de comportamientos a través de la jerarquía del archivo de configuración, ahora WCF admite la combinación entre archivos de configuración.

El modelo de herencia de configuración se ha expandido para permitir a los usuarios definir comportamientos que se aplicarán a todos los servicios que se ejecutan en el equipo.

Puede encontrar cambios de comportamiento si hay comportamientos con el mismo nombre en niveles distintos de la jerarquía.

Hospedaje de servicios

Ya no se puede especificar el elemento de configuración <serviceHostingEnvironment> en el nivel del servicio agregando el atributo allowDefinition="MachineToApplication" a la definición de elemento.

Especificar el elemento <serviceHostingEnvironment> en el nivel del servicio es técnicamente incorrecto y produce un comportamiento incoherente.

Volver al principio

Aplicaciones

Espacios de nombres: System.Windows, System.Windows.Controls; ensamblado: PresentationFramework (en PresentationFramework.dll)

Característica

Diferencias respecto a 3.5 SP1

Cambios recomendados

Control de excepciones

Para permitir que se detecten antes los errores, WPF produce una excepción TargetInvocationException y establece la propiedad InnerException en excepciones críticas, como las excepciones NullReferenceException, OutOfMemoryException, SecurityException y StackOverflowException, en lugar de detectar la excepción original.

Ninguno.

Recursos vinculados

Para facilitar la vinculación, los archivos de recursos (como las imágenes) que se encuentran en ubicaciones distintas que la estructura de carpetas del proyecto usan al compilarse la aplicación su ruta de acceso completa como identificador de recurso, en lugar de simplemente el nombre de archivo. La aplicación podrá buscar los archivos en tiempo de ejecución.

Ninguno.

Aplicaciones de confianza parcial

Por motivos de seguridad, las aplicaciones basadas en Windows que se ejecutan en confianza parcial y contienen un control WebBrowser o un control Frame que incluye HTML producirán una excepción SecurityException cuando se cree el control.

Las aplicaciones de explorador producirán una excepción y mostrarán un mensaje si se cumplen todas las condiciones siguientes:

  • La aplicación se está ejecutando en Firefox.

  • La aplicación se está ejecutando con confianza parcial en la zona de Internet desde sitios que no son de confianza.

  • La aplicación contiene un control WebBrowser o un control Frame que incluye código HTML.

Tenga en cuenta que las aplicaciones que se ejecutan desde sitios de confianza o desde la zona de intranet no se verán afectadas.

En las aplicaciones del explorador, se puede mitigar este cambio realizando una de las acciones siguientes:

  • Ejecutar la aplicación de explorador en plena confianza.

  • Hacer que los clientes agreguen el sitio de la aplicación a la zona de sitios de confianza.

  • Hacer que los clientes ejecuten la aplicación en Internet Explorer.

Diccionarios de recursos

Para mejorar los diccionarios de recursos de nivel de tema y evitar que cambien, ahora los recursos inmovilizables que se definen en un diccionario de recursos y se combinan en un diccionario de nivel de tema se marcan siempre como inmovilizados y son inmutables. Este es el comportamiento esperado para los recursos inmovilizables.

Las aplicaciones que modifican un recurso definido en un diccionario combinado de nivel de tema deben clonar el recurso y modificar la copia clonada. O bien, el recurso se puede marcar como x:Shared="false" para que ResourceDictionary cree una nueva copia cada vez que se consulte el recurso.

Windows 7

Para que las aplicaciones WPF funcionen mejor en Windows 7, se han realizado las siguientes mejoras para corregir el comportamiento de una ventana:

  • Los estados de movimiento y acoplamiento funcionan ahora tal y como se espera según las interacciones del usuario.

  • Los comandos de la barra de tareas Ventanas en cascada, Mostrar ventanas apiladas y Mostrar ventanas en paralelo presentan ahora el comportamiento correcto y actualizan las propiedades adecuadas.

  • Las propiedades Top, Left, Width y Height para ventanas maximizadas o minimizadas contienen ahora la ubicación de restauración correcta, en lugar de otros valores, según el monitor.

Ninguno.

Estilo y transparencia de las ventanas

Se produce una excepción InvalidOperationException si se intenta establecer WindowStyle en un valor distinto de None cuando AllowsTransparency es true y WindowState es Minimized.

Si no tiene más remedio que cambiar WindowStyle cuando AllowsTransparency es true, puede llamar a la función SetWindowLongPtr de Win32.

Visor de XPS

WPF no incluye Microsoft XML Paper Specification Essentials Pack (XPSEP). XPSEP se incluye con Windows 7 y Windows Vista.

En un equipo que ejecuta Windows XP sin .NET Framework 3.5 SP1 instalado, la impresión mediante una API de WPF distinta de las de PrintDialog se basará en WINSPOOL. No se notificarán algunas capacidades de la impresora y algunas configuraciones de impresora no se aplicarán durante la impresión.

Si es preciso, instale Microsoft XML Paper Specification Essentials Pack.

Volver al principio

Controles

Espacios de nombres: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input; ensamblados: PresentationFramework (en PresentationFramework.dll), PresentationCore (en PresentationCore.dll), WindowsBase (en WindowsBase.dll)

Característica

Diferencias respecto a 3.5 SP1

Cambios recomendados

Cuadros de diálogo

Para mejorar la confiabilidad, se llama al método CommonDialog.ShowDialog en el mismo subproceso que ha creado el control Microsoft.Win32.FileDialog.

Asegúrese de crear un control FileDialog y de llamar al método ShowDialog en el mismo subproceso.

Ventanas flotantes

Para corregir la lógica de restauración de foco incorrecta que reactiva una y otra vez una ventana flotante (de tal forma que parece un cuadro de diálogo modal), ahora la restauración de foco se evita ahora si el candidato no es un elemento secundario de la ventana.

Ninguno.

Elementos de las colecciones

Cuando un elemento se mueve o agrega a una colección subyacente, aparece en CollectionView en la misma ubicación relativa si la CollectionView no está ordenada. Esto proporciona coherencia entre la posición de los elementos en la colección y la CollectionView asociada.

Use ItemContainerGenerator.ContainerFromItem o CollectionView.IndexOf para encontrar la ubicación de un elemento en una CollectionView en lugar de basarse en la ubicación fija de un elemento.

Layouts

Para eliminar la repetición innecesaria del diseño, al cambiar Page.ShowsNavigationUI ya no se invalida el diseño ni se provoca otro paso de diseño.

Si está previsto que al cambiar ShowsNavigationUI se provoque otro paso de diseño, llame a UIElement.InvalidateVisual después de establecer la propiedad.

Menús

Para habilitar el texto ClearType en los elementos emergentes de menú, se han realizado modificaciones en la clase ControlTemplate, en el control MenuItem y en otros controles.

Las aplicaciones no se deben basar en la estructura visual de las plantillas de control. Solo las partes con nombre de una plantilla ControlTemplate forman parte del contrato público. Si una aplicación debe encontrar un objeto determinado en una plantilla ControlTemplate, busque un tipo específico en el árbol visual en lugar de confiar en una ubicación fija de un objeto en el árbol.

Navegación

Si un Frame navega directamente a una ubicación, la propiedad IsNavigationInitiator es true después de la navegación inicial. Este cambio evita que se generen más eventos durante los escenarios de inicio.

Ninguno.

Elementos emergentes

Ahora, se puede llamar al delegado CustomPopupPlacementCallback varias veces durante un paso de diseño en lugar de solo una vez.

Si el delegado CustomPopupPlacementCallback calcula la posición de un Popup basándose en su posición anterior, actualice la posición solo si cambian los valores de los parámetros popupSize, targetSize u offset.

Valores de la propiedad

El método DependencyObject.SetCurrentValue presenta ahora una manera de establecer una propiedad en un valor eficiente, aunque sigue respetando cualquier enlace, estilo o desencadenador que afecte a la propiedad.

Los autores de controles deben emplear SetCurrentValue siempre que el valor de propiedad cambie por efecto secundario de alguna otra acción, incluyendo la manipulación del usuario.

Cuadros de texto

Por motivos de seguridad, los métodos TextBoxBase.Copy y TextBoxBase.Cut producen un error de forma silenciosa si se les llama en confianza parcial.

Además, la ejecución de la propiedad ApplicationCommands.Copy o ApplicationCommands.Cut mediante programación en un control que hereda de TextBoxBase se bloqueará en confianza parcial. Sin embargo, los comandos copiar y pegar iniciados por el usuario, como hacer clic en un botón cuya propiedad ButtonBase.Command está enlazada a uno de estos comandos, funcionarán. La operación estándar de copiar y cortar mediante los métodos abreviado de teclado y el menú contextual seguirá funcionando como antes en confianza parcial.

Enlace el comando ApplicationCommands.Cut o ApplicationCommands.Copy a una acción iniciada por el usuario, como hacer clic en un botón.

Volver al principio

Gráficos

Espacios de nombres: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input y System.Windows.Media.Effects; ensamblados: PresentationFramework (en PresentationFramework.dll), PresentationCore (en PresentationCore.dll) y WindowsBase (en WindowsBase.dll)

Característica

Diferencias respecto a 3.5 SP1

Cambios recomendados

Efectos de mapa de bits

Para mejorar el rendimiento, la clase BitmapEffect y aquellas que heredan de BitmapEffect están deshabilitadas, aunque siguen estando presentes. El efecto se presentará usando la canalización de representación acelerada por hardware si se cumplen las siguientes condiciones:

  • La aplicación usa un efecto DropShadowBitmapEffect o BlurBitmapEffect que tiene una propiedad de radio establecida en un valor menor que 100 DIU.

  • La tarjeta de vídeo del equipo que ejecuta la aplicación admite el sombreador de píxeles 2.0.

Si no se cumplen estas condiciones, el objeto BitmapEffect no tendrá ningún efecto.

Además, Visual Studio 2010 generará una advertencia del compilador cuando encuentre el objeto BitmapEffect o una subclase.

El método PushEffect se marca como obsoleto.

Deje de usar la clase BitmapEffect heredada y las clases derivadas, y emplee en su lugar las nuevas clases derivadas de Effect: BlurEffect, DropShadowEffect y ShaderEffect.

También puede crear sus propios efectos heredando de la clase ShaderEffect.

Marcos de mapa de bits

Los objetos BitmapFrame clonados reciben ahora los eventos DownloadProgress, DownloadFailed y DownloadCompleted. Esto permite que las imágenes que se descargan de la web y se aplican al control Image mediante Style funcionen correctamente.

Solo verá un cambio en el comportamiento si todas las afirmaciones siguientes son verdaderas:

Compruebe el remitente en el controlador de eventos y actúe solamente si el remitente es el objeto BitmapFrame original.

Descodificar imágenes

Para evitar que una excepción IOException no se controle cuando las imágenes no se pueden descodificar, la clase BitmapSource generará el evento DecodeFailed cuando no descodifique una imagen.

Quite el control de excepciones para IOException y utilice el evento DecodeFailed para comprobar el error de descodificación.

Volver al principio

Entrada

Espacios de nombres: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input; ensamblados: PresentationFramework (en PresentationFramework.dll), PresentationCore (en PresentationCore.dll), WindowsBase (en WindowsBase.dll)

Característica

Diferencias respecto a 3.5 SP1

Cambios recomendados

Enlazar instancias de comandos

Para proporcionar un mecanismo para enlazar instancias de comandos basadas en modelos de vista a los movimientos de entrada basados en vista, ahora la clase InputBinding hereda de Freezable en lugar de heredar de DependencyObject. Ahora, las propiedades siguientes son de dependencia:

Este cambio da lugar a lo siguiente:

  • Ahora, un objeto InputBinding se inmoviliza cuando se registra en lugar de seguir siendo mutable.

  • No se puede tener acceso a los objetos InputBinding de nivel de instancia de varios subprocesos, debido a las restricciones de la clase DependencyObject.

  • No se pueden mutar los enlaces de entrada de nivel de clase después de su registro, debido a las restricciones de la clase Freezable.

  • No se pueden especificar enlaces de entrada en las instancias de comandos que se crean en un modelo de vista.

Cree instancias independientes de una clase InputBinding en subprocesos distintos si los enlaces van a ser mutables. De lo contrario, inmovilícelos. No modifique un objeto InputBinding estático de nivel de clase una vez registrado.

Aplicaciones de explorador

Las aplicaciones de explorador de WPF (.XBAP) procesan ahora los eventos de tecla de la misma manera que las aplicaciones WPF independientes, por lo que los objetos reciben los eventos de tecla enrutados en el orden correcto.

Ninguno.

Combinaciones de teclas inactivas

WPF ofusca las teclas inactivas, lo que no produce ningún carácter visible, pero en su lugar indica que la clave se va a combinar con la tecla de letra siguiente para generar un carácter. Los eventos de entrada de tecla, como el evento KeyDown, notifica cuando una tecla es una tecla inactiva estableciendo la propiedad Key en el valor DeadCharProcessed. Suele ser el comportamiento esperado porque las aplicaciones normalmente no piensan responder a las acciones del teclado que crea un carácter combinado.

Las aplicaciones que esperan leer teclas que formaban parte de caracteres combinados pueden obtener ahora la tecla ofuscada usando la propiedad DeadCharProcessedKey.

Administrador del foco

Cuando se pasa al método FocusManager.GetFocusedElement un elemento que tiene la propiedad adjunta IsFocusScope establecida en true, el método devuelve un elemento que es el último elemento con foco del teclado dentro de ese ámbito del foco si y solo si el elemento devuelto pertenece al mismo objeto PresentationSource que el elemento que se pasa al método.

Ninguno.

Volver al principio

Automatización de la interfaz de usuario

Espacio de nombres: System.Windows, System.Windows.Automation.Peers, System.Windows.Automation.Provider, System.Windows.Controls, System.Windows.Data, System.Windows.Input; ensamblados: PresentationFramework (en PresentationFramework.dll), PresentationCore (en PresentationCore.dll), UIAutomationProvider (en UIAutomationProvider.dll), WindowsBase (en WindowsBase.dll)

Característica

Diferencias respecto a 3.5 SP1

Cambios recomendados

Jerarquía de clases de las vistas

Las clases TreeViewAutomationPeer y TreeViewItemAutomationPeer heredan de ItemsControlAutomationPeer en lugar de FrameworkElementAutomationPeer.

Si hereda de las clases TreeViewItemAutomationPeer y reemplaza el método GetChildrenCore, considere la posibilidad de devolver un objeto que herede de la nueva clase TreeViewDataItemAutomationPeer.

Contenedores fuera de la pantalla

Para corregir un valor devuelto incorrecto, ahora el método UIElementAutomationPeer.IsOffscreenCore devuelve false correctamente para los contenedores de elementos que al desplazarse quedan fuera de la vista. Además, el valor del método no se ve afectado porque el elemento esté oculto por otras ventanas o si el elemento es visible en un monitor concreto.

Ninguno.

Menús y objetos secundarios

Para habilitar la automatización de la interfaz de usuario de los menús que contienen elementos secundarios que no sean objetos MenuItem, ahora el método GetChildrenCore devuelve el objeto AutomationPeer de un objeto UIElement secundario, en lugar de un objeto MenuItemAutomationPeer.

Ninguno.

Nuevas interfaces y ensamblado

Para habilitar las nuevas características para la automatización de la interfaz de usuario, se han agregado las siguientes interfaces:

Cualquier proyecto que compile objetos de automatización de WPF del mismo nivel debe agregar una referencia explícita a UIAutomationProvider.dll.

Controles de posición

El método GetClassNameCore devuelve un valor, en lugar de null. Por tanto, los controles como GridSplitter que heredan de la clase Thumb notificarán un nombre a la automatización de la interfaz de usuario.

Ninguno.

Elementos virtualizados

Para mejorar el rendimiento, el método UIElementAutomationPeer.GetChildrenCore devuelve solamente los objetos secundarios que se encuentran realmente en el árbol visual y no todos ellos, con independencia de si están o no virtualizados.

Use ItemContainerPattern para recorrer en iteración todos los elementos de ItemsControlAutomationPeer.

Volver al principio

XAML

Espacios de nombres: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input y System.Windows.Markup; ensamblados: PresentationFramework (en PresentationFramework.dll), PresentationCore (en PresentationCore.dll) y WindowsBase (en WindowsBase.dll)

Característica

Diferencias respecto a 3.5 SP1

Cambios recomendados

Extensión de marcado

Ahora, WPF utiliza siempre correctamente el valor del método MarkupExtension.ProvideValue en lugar de devolver el objeto MarkupExtension en aquellos casos en que se utiliza una extensión de marcado para establecer una propiedad o crear un elemento en una colección. Se podría devolver una extensión de marcado en algunos casos.

Si su aplicación tiene acceso a un recurso que devolvía un objeto MarkupExtension en versiones anteriores, haga referencia al objeto que se devuelve de ProvideValue, en lugar de al objeto MarkupExtension.

Analizar atributos

Los atributos en XAML ahora solo pueden tener un punto. Por ejemplo, son válidos los siguientes:

<Button Background="Red"/> (ningún punto)

<Button Button.Background = "Red"/> (un punto)

Lo siguiente ya no es válido:

<Button Control.Button.Background = "Red"/> (más de un punto)

Atributos XAML correctos que tienen más de un período.

Volver al principio

En las filas de esta tabla se describen las mejoras realizadas en características que anteriormente presentaban limitaciones u otros problemas.

Esquema y transformaciones

Espacios de nombres: System.Xml.Linq; System.Xml.Schema, System.Xml.XPath; ensamblados: System.Xml (en System.Xml.dll), System.Xml.Linq (en System.Xml.Linq.dll)

Característica

Diferencias respecto a 3.5 SP1

Esquemas camaleón

Para evitar que se dañen los datos, los esquemas camaleón se clonan ahora correctamente cuando se los incluye con varios esquemas.

Los esquemas camaleón son aquellos que no tienen un espacio de nombres de destino y que, cuando se los incluye en otro XSD, asumen el espacio de nombres de destino del esquema de importación. Se utilizan a menudo para incluir tipos comunes en un esquema.

Funciones ID

La función id de XSLT devuelve ahora el valor correcto en lugar de null cuando se pasa un objeto XmlReader a XLST.

Si el usuario creaba un objeto XmlReader a partir de una clase de LINQ to XML mediante el método CreateReader, y este objeto XmlReader se pasaba a un XSLT, antes todas las instancias de la función id en el XSLT devolvían null. Este no es un valor devuelto permitido para la función id.

Atributo de espacio de nombres

Para evitar que se dañen los datos, un objeto XPathNavigator devuelve ahora correctamente el nombre local del atributo x:xmlns.

Declaraciones de espacios de nombres

Un objeto XmlReader de un subárbol ya no crea declaraciones de espacio de nombres duplicadas dentro de un elemento XML.

Validación de esquemas

Para evitar la validación de esquemas errónea, la clase XmlSchemaSet permite que los esquemas XSD se compilen de manera correcta y coherente. Estos esquemas pueden incluir otros esquemas; por ejemplo, A.xsd puede incluir B.xsd, que puede incluir C.xsd. Al compilar cualquiera de ellos, se atraviesa este gráfico de dependencias.

Funciones de script

La función de función disponible ya no devuelve incorrectamente false cuando la función está realmente disponible.

URI

El método XElement.Load ahora devuelve el valor de BaseURI correcto en las consultas LINQ.

Volver al principio

Validación

Espacios de nombres: System.Xml.Linq; System.Xml.Schema, System.Xml.XPath; ensamblados: System.Xml (en System.Xml.dll), System.Xml.Linq (en System.Xml.Linq.dll)

Característica

Diferencias respecto a 3.5 SP1

Resoluciones de espacios de nombres

El método XmlReader.ReadContentAs ya no omite la resolución IXmlNamespaceResolver que se le pasa.

En las versiones anteriores, la resolución de espacio de nombres especificada se omitía y, en su lugar, se utilizaba XmlReader.

Espacio en blanco

Para evitar la pérdida de datos al crear un lector, el método XmlReader.Create ya no descarta el espacio en blanco significativo.

La validación de XML reconoce el modo de contenido mixto, donde el texto se puede combinar con formato XML. En el modo mixto, todo el espacio en blanco es significativo y se debe notificar.

Volver al principio

Escritura

Espacios de nombres: System.Xml.Linq; System.Xml.Schema, System.Xml.XPath; ensamblados: System.Xml (en System.Xml.dll), System.Xml.Linq (en System.Xml.Linq.dll)

Característica

Diferencias respecto a 3.5 SP1

Referencias de entidad

Para evitar que se dañen los datos, las referencias a entidad ya no se convierten en entidades dos veces en los atributos XML.

Si el usuario intentaba escribir una entidad en un atributo xmlns o en un atributo xml:lang o xml:space mediante el método WriteEntityRef, la entidad se creaba dos veces en el resultado y los datos quedaban dañados.

Control de nueva línea

Para evitar que se dañen los datos, los objetos XmlWriter respetan la opción None.

Volver al principio

date

Historial

Motivo

Agosto de 2010

Se han agregado problemas sobre el hospedaje de controles en el explorador web, las clases de compiladores y CodeDOM, y el visor de la memoria caché global de ensamblados.

Mejora de la información.

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios

Adiciones de comunidad

AGREGAR
Mostrar:
© 2014 Microsoft