Cambios de runtime para la migración a .NET Framework 4.5.x

En este artículo se enumeran los problemas de compatibilidad de aplicaciones que se introdujeron en .NET Framework 4.5, 4.5.1 y 4.5.2.

.NET Framework 4.5

ASP.NET

GridView con AllowCustomPaging establecido en true puede desencadenar el evento PageIndexChanging al salir de la última página de la vista

Detalles

Un error en .NET Framework 4.5 hace que en ocasiones no se desencadene System.Web.UI.WebControls.GridView.PageIndexChanging para los elementos System.Web.UI.WebControls.GridView en los que se ha habilitado System.Web.UI.WebControls.GridView.AllowCustomPaging.

Sugerencia

Este problema se ha corregido en .NET Framework 4.6 y se puede solucionar mediante la actualización a esa versión de .NET Framework. Como una solución alternativa, la aplicación puede realizar una BindGrid explícita en cualquier método Page_Load que cumpla estas condiciones (la System.Web.UI.WebControls.GridView está en la última página y LastSystem.Web.UI.WebControls.GridView.PageSize es diferente de System.Web.UI.WebControls.GridView.PageSize). Como alternativa, la aplicación se puede modificar para permitir la paginación (en lugar de la paginación personalizada), dado que ese escenario no ilustra el problema.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• GridView.AllowCustomPaging

La propiedad HttpRequest.ContentEncoding prohíbe la codificación UTF7

Detalles

A partir de .NET Framework 4.5, la codificación UTF-7 está prohibida en los cuerpos de elementos System.Web.HttpRequest. Los datos de las aplicaciones que dependen de los datos de entrada UTF-7 no se descodificarán correctamente en algunos casos.

Sugerencia

Lo ideal sería actualizar las aplicaciones para que no usen la codificación UTF-7 en los elementos System.Web.HttpRequest. También es posible restaurar el comportamiento heredado usando el atributo aspnet:AllowUtf7RequestContentEncoding del elemento appSettings.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• HttpRequest.ContentEncoding

HttpUtility.JavaScriptStringEncode aplica un carácter de escape a la Y comercial

Detalles

A partir de .NET Framework 4.5, System.Web.HttpUtility.JavaScriptStringEncode(String) incluye un carácter de escape antes del carácter de Y comercial (&).

Sugerencia

Si la aplicación depende del comportamiento anterior de este método, puede agregar un ajuste aspnet:JavaScriptDoNotEncodeAmpersand al elemento appSettings de ASP.NET en el archivo de configuración.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• HttpUtility.JavaScriptStringEncode(String)
• HttpUtility.JavaScriptStringEncode(String, Boolean)

No se debe usar IPad en el archivo de funciones personalizado porque ahora es una funcionalidad del explorador

Detalles

A partir de .NET Framework 4.5, iPad es un identificador en el archivo de funciones de explorador de ASP.NET predeterminado, por lo que no se debe usar en un archivo de funciones personalizado.

Sugerencia

Si se requieren funcionalidades específicas de iPad, es necesario modificar el comportamiento de iPad. Para ello, establezca las funcionalidades en el refID "IPad" de puerta de enlace predefinido en lugar de generar un nuevo id. "IPad" mediante la búsqueda de coincidencias de agente de usuario.

Nombre	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

El evento Page.LoadComplete ya no hace que el control System.Web.UI.WebControls.EntityDataSource invoque un enlace de datos

Detalles

El evento LoadComplete ya no hace que el control System.Web.UI.WebControls.EntityDataSource llame al enlace de datos cuando se producen cambios al crear, actualizar o eliminar parámetros. Este cambio elimina un viaje superfluo a la base de datos, impide que se restablezcan los valores de los controles y produce un comportamiento coherente con otros controles de datos, como System.Web.UI.WebControls.SqlDataSource y System.Web.UI.WebControls.ObjectDataSource. Este cambio produce un comportamiento diferente en el caso improbable de que las aplicaciones invoquen el enlace de datos en el evento LoadComplete.

Sugerencia

Si se necesita un enlace de datos, invóquelo manualmente en un evento anterior en la devolución.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Posible error irrecuperable en el motor de ejecución por parte de las aplicaciones de MVC4 de generación de perfiles de ASP.NET

Detalles

Los generadores de perfiles que usan ensamblados /Profile de NGEN pueden bloquear las aplicaciones de MVC4 con perfiles de ASP.NET durante el inicio con una "Excepción irrecuperable de motor de ejecución".

Sugerencia

Este problema se ha corregido en .NET Framework 4.5.2. Como alternativa, el generador de perfiles puede evitar este problema mediante la especificación de COR_PRF_DISABLE_ALL_NGEN_IMAGES en su máscara de eventos.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Compartir el estado de sesión con StateServer de ASP.NET requiere que todos los servidores de la granja de servidores web usen la misma versión de .NET Framework

Detalles

Al habilitar el estado de sesión System.Web.SessionState.SessionStateMode.StateServer, todos los servidores de la granja de servidores web indicada deben usar la misma versión de .NET Framework para que el estado se comparta correctamente.

Sugerencia

Asegúrese de actualizar las versiones de .NET Framework en los servidores web que compartan el estado al mismo tiempo.

	Value
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• SessionStateMode.StateServer

WebUtility.HtmlDecode ya no descodifica secuencias de entrada no válidas

Detalles

De forma predeterminada, los métodos de descodificación ya no descodifican secuencias de entrada no válidas en una cadena UTF-16 no válida. En su lugar, devuelven la entrada original.

Sugerencia

El cambio en la salida del descodificador solo es importante si se almacenan datos binarios en lugar de datos UTF-16 en cadenas. Para controlar este comportamiento de manera explícita, establezca el atributo aspnet:AllowRelaxedUnicodeDecoding del elemento appSettings en true para habilitar el comportamiento heredado o en false para habilitar el actual.

	Value
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• WebUtility.HtmlDecode(String)
• WebUtility.HtmlDecode(String, TextWriter)
• WebUtility.UrlDecode(String)

Core

Los ensamblados compilados con Regex.CompileToAssembly se interrumpen entre las versiones 4.0 y 4.5

Detalles

Si un ensamblado de expresiones regulares compiladas se crea con .NET Framework 4.5 pero tiene como destino .NET Framework 4, se inicia una excepción al intentar usar una de las expresiones regulares de ese ensamblado en un sistema con .NET Framework 4 instalado.

Sugerencia

Para evitar este problema, realice una de las acciones siguientes:

• Compile el ensamblado que contiene las expresiones regulares con .NET Framework 4.
• Use una expresión regular interpretada.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName)
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[])
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[], String)

BlockingCollection<T>.TryTakeFromAny ya no inicia excepciones

Detalles

Si alguna de las colecciones de entrada está marcada como completada, TryTakeFromAny(BlockingCollection<T>[], T) no devuelve -1 y TakeFromAny(BlockingCollection<T>[], T) deja de iniciar una excepción. Este cambio permite trabajar con colecciones cuando una de las colecciones está vacía o completa y la otra colección todavía tiene elementos que se pueden recuperar.

Sugerencia

Si se han usado un método TryTakeFromAny que devuelva -1 o un método TakeFromAny de inicio para el control de flujo en casos en los que se complete una recolección de bloqueo, es necesario cambiar dicho código para que use .Any(b => b.IsCompleted) para detectar dicha condición.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T, CancellationToken)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, Int32)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)

Cambio de comportamiento para los métodos Task.WaitAll con argumentos de tiempo de espera

Detalles

El comportamiento de Task.WaitAll se ha hecho más coherente en .NET Framework 4.5. En .NET Framework 4, estos métodos se comportaban de forma incoherente. Cuando se agotaba el tiempo de espera, si una o varias tareas se completaban o cancelaban antes de la llamada al método, el método producía una excepción System.AggregateException. Cuando se agotaba el tiempo de espera, si no se completaba ni cancelaba ninguna tarea antes de la llamada al método, pero una o varias tareas entraban en estos estados después de la llamada al método, el método pasaba a ser false.

En .NET Framework 4.5, estas sobrecargas de método ahora devuelven false si las tareas siguen en ejecución cuando se agota el intervalo de tiempo de espera e inician una excepción System.AggregateException solo si se ha cancelado una tarea de entrada (con independencia de si se canceló antes o después de la llamada al método) y no hay otras tareas en ejecución.

Sugerencia

Si se detecta un System.AggregateException como medio para detectar una tarea que se canceló antes de invocar la llamada a WaitAll, ese código debe realizar la misma detección a través de la propiedad IsCanceled (por ejemplo, .Any(t => t.IsCanceled)) ya que .NET Framework 4.6 solo iniciará en ese caso si todas las tareas esperadas se completan antes del tiempo de espera.

	Value
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• Task.WaitAll(Task[], Int32)
• Task.WaitAll(Task[], Int32, CancellationToken)
• Task.WaitAll(Task[], TimeSpan)

Compatibilidad del compilador con el reenvío de tipos al usar la compatibilidad con múltiples versiones de mscorlib

Detalles

Una nueva característica de CodeDOM permite a un compilador realizar la compilación en la versión de destino de mscorlib.dll en lugar de en la versión de .NET Framework 4.5 de mscorlib.dll.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

ConcurrentQueue<T>.TryPeek puede devolver un valor NULL erróneo mediante su parámetro out

Detalles

En algunos escenarios con múltiples subprocesos, System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) puede devolver true, pero rellenar el parámetro out con un valor nulo (en lugar del valor correcto observado).

Sugerencia

Este problema se corrigió en .NET Framework 4.5.1. Actualizar a esta versión de .NET Framework solucionará el problema.

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• ConcurrentQueue<T>.TryPeek(T)

Los elementos EventListener de ETW no capturan eventos de proveedores con palabras clave explícitas (como el proveedor de la TPL)

Detalles

Los elementos EventListener de ETW con una máscara de palabra clave en blanco no capturarán correctamente los eventos de proveedores con palabras clave explícitas. En .NET Framework 4.5, el proveedor de la TPL comenzó a suministrar palabras clave explícitas y dio pie a este problema. En .NET Framework 4.6, se actualizaron los elementos EventListener para evitar este problema.

Sugerencia

A modo de solución alternativa para este problema, reemplaza las llamadas a EnableEvents(EventSource, EventLevel) por llamadas a la sobrecarga EnableEvents que especifica de forma explícita que la máscara «any keywords» debe usar EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).

Este problema se resolvió en .NET Framework 4.6, por lo que otra posible solución es actualizar a esta versión de .NET Framework.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• EventListener.EnableEvents(EventSource, EventLevel)

Las excepciones durante el procesamiento inadvertido en System.Threading.Tasks.Task ya no se propagan por el subproceso de finalizador

Detalles

Dado que la clase System.Threading.Tasks.Task representa una operación asincrónica, detecta todas las excepciones no graves que se producen durante el procesamiento asincrónico. En .NET Framework 4.5, si no se detecta una excepción y el código nunca espera a que se complete la tarea, la excepción ya no se propagará por el subproceso de finalizador y bloqueará el proceso durante la recolección de elementos no utilizados. Este cambio mejora la confiabilidad de las aplicaciones que usan la clase Task para realizar un procesamiento asincrónico inadvertido.

Sugerencia

Si una aplicación depende de la propagación de excepciones asincrónicas inadvertidas al subproceso de finalizador, se puede restaurar el comportamiento anterior si se proporciona un controlador adecuado para el evento UnobservedTaskException, o bien se establece un elemento de configuración del entorno de ejecución.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• Task.Run(Action)
• Task.Run(Action, CancellationToken)
• Task.Run(Func<Task>)
• Task.Run(Func<Task>, CancellationToken)
• Task.Run<TResult>(Func<TResult>)
• Task.Run<TResult>(Func<TResult>, CancellationToken)
• Task.Run<TResult>(Func<Task<TResult>>)
• Task.Run<TResult>(Func<Task<TResult>>, CancellationToken)
• Task.Start()
• Task.Start(TaskScheduler)

El algoritmo List.Sort ha cambiado

Detalles

A partir de .NET Framework 4.5, se ha cambiado el algoritmo de ordenación de System.Collections.Generic.List<T> (para que sea una ordenación introspectiva en lugar de una ordenación rápida). La ordenación de System.Collections.Generic.List<T> nunca ha sido estable, pero este cambio puede provocar que otros escenarios se ordenen de maneras inestables. Esto simplemente significa que los elementos equivalentes se pueden ordenar de otra forma en las llamadas posteriores de la API.

Sugerencia

Como el algoritmo de ordenación anterior también era inestable (aunque de forma ligeramente distinta), no debería haber código que dependa de que los elementos equivalentes se ordenen siempre en un orden concreto. Si hay instancias de código que dependan de eso y de tener suerte con el comportamiento anterior, ese código se debe actualizar para que use un comparador que ordene de forma determinista los elementos en el orden deseado.

NOMBRE	Valor
Ámbito	Transparente
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• List<T>.Sort()
• List<T>.Sort(IComparer<T>)
• List<T>.Sort(Comparison<T>)
• List<T>.Sort(Int32, Int32, IComparer<T>)

La ausencia de moniker de la plataforma de destino da lugar a un comportamiento de la versión 4.0

Detalles

Las aplicaciones sin un elemento System.Runtime.Versioning.TargetFrameworkAttribute aplicado en el nivel de ensamblado se ejecutarán automáticamente con la semántica (las peculiaridades) de .NET Framework 4.0. Para garantizar una buena calidad, se recomienda que todos los archivos binarios incluyan un atributo System.Runtime.Versioning.TargetFrameworkAttribute explícito en el que se indique la versión de .NET Framework con la que se compilaron. Tenga en cuenta que usar un moniker de la plataforma de destino en un archivo de proyecto hará que MSBuild aplique automáticamente un atributo System.Runtime.Versioning.TargetFrameworkAttribute.

Sugerencia

Se debe proporcionar un atributo System.Runtime.Versioning.TargetFrameworkAttribute, agregándolo directamente al ensamblado o especificando una plataforma de destino en el archivo de proyecto, o bien a través de la GUI de propiedades del proyecto de Visual Studio.

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Algunas API de .NET generan primeras excepciones EntryPointNotFoundExceptions (controladas)

Detalles

En .NET Framework 4.5, un pequeño número de métodos de .NET comenzaron a iniciar primeras excepciones System.EntryPointNotFoundException. Estas primeras excepciones se controlaban dentro de .NET Framework, pero podían interrumpir la automatización de las pruebas que no las esperasen. Estas mismas API interrumpen algunos escenarios de ApiVerifier con el elemento HighVersionLie habilitado.

Sugerencia

Este error puede evitarse actualizando a .NET Framework 4.5.1. Como alternativa, la automatización de pruebas se puede actualizar para no interrumpir las excepciones de primera oportunidad System.EntryPointNotFoundException.

	Value
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

System.Threading.Tasks.Task ya no inicia una excepción ObjectDisposedException después de desechar un objeto

Detalles

A excepción de IAsyncResult.AsyncWaitHandle, los métodos System.Threading.Tasks.Task ya no inician una excepción System.ObjectDisposedException después de desechar el objeto. Este cambio admite el uso de tareas en caché. Por ejemplo, un método puede devolver una tarea almacenada en caché para representar una operación completada en lugar de asignar una nueva tarea. Esto no era posible en versiones anteriores de .NET Framework, ya que cualquier consumidor de la tarea podía desecharla, lo que hacía que se volviera inutilizable.

Sugerencia

Tenga en cuenta que es posible que los métodos Task ya no inicien excepciones System.ObjectDisposedException cuando el objeto se desecha. Si una aplicación dependía de esta excepción para conocer que se desechó una tarea, se debería actualizar para comprobar de forma explícita el estado de la tarea mediante Status.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

La aplicación de secuencias de escape de System.Uri ahora es compatible con RFC 3986

Detalles

La aplicación de secuencias de escape a los URI se ha modificado en .NET Framework 4.5 para que sea compatible con RFC 3986. Cambios concretos:

• El método System.Uri.EscapeDataString(String) incluye los caracteres reservados entre caracteres de escape de con arreglo a RFC 3986.
• El método System.Uri.EscapeUriString(String) no incluye entre caracteres de escape los caracteres reservados.
• El método System.Uri.UnescapeDataString(String) no inicia una excepción si encuentra una secuencia de escape no válida.
• Los caracteres de escape no reservados no se incluyen en una secuencia de escape.

Sugerencia

• Actualice las aplicaciones para que no se basen en el inicio de System.Uri.UnescapeDataString(String) en caso de tratarse de secuencias de escape no válidas. Ahora, este tipo de secuencias deben detectarse directamente.
• De igual modo, cabe esperar que los URI y las cadenas de datos con secuencias de escape y sin ellas varíen entre .NET Framework 4.0 y .NET Framework 4.5, y no se deben comparar directamente entre versiones de .NET. En lugar de ello, deben analizarse y normalizarse en una única versión de .NET antes de efectuar cualquier comparación.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• Uri.EscapeDataString(String)
• Uri.EscapeUriString(String)
• Uri.UnescapeDataString(String)

data

Los datos de sql_variant usan la intercalación de sql_variant en lugar de la intercalación de base de datos

Detalles

Los datos de sql_variant utilizan la intercalación de sql_variant en lugar de la intercalación de base de datos.

Sugerencia

Este cambio soluciona posibles daños en los datos si la intercalación de la base de datos difiere de la intercalación de sql_variant. Las aplicaciones que se basan en datos dañados pueden experimentar errores.

NOMBRE	Valor
Ámbito	Transparente
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

SqlBulkCopy usa la codificación de columna de destino para las cadenas

Detalles

Al insertar datos en una columna, System.Data.SqlClient.SqlBulkCopy utiliza la codificación de la columna de destino en lugar de la codificación predeterminada para los tipos VARCHAR y CHAR. Este cambio elimina la posibilidad de que se produzcan daños en los datos al usar la codificación predeterminada cuando la columna de destino no utiliza la codificación predeterminada. En raras ocasiones, una aplicación existente podría iniciar una excepción SqlException si el cambio de codificación genera datos que son demasiado grandes como para caber en la columna de destino.

Sugerencia

Espere que System.Data.SqlClient.SqlBulkCopy ya no dañe los datos debido a diferencias de codificación. Si se copian cadenas cerca del límite de tamaño de la columna de destino, puede que sea necesario codificar previamente los datos (que se van a copiar para comprobar que caben en la columna de destino) o capturar las excepciones System.Data.SqlClient.SqlException.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Data.SqlClient.SqlBulkCopy
• SqlBulkCopy(SqlConnection)

SqlConnection ya no se puede conectar a SQL Server 1997 o a bases de datos mediante el adaptador VIA

Detalles

Ya no se admiten las conexiones a las bases de datos de SQL Server mediante el protocolo Adaptador de interfaz virtual (VIA). El protocolo que se usa para conectarse a una base de datos de SQL Server es visible en la cadena de conexión. Una conexión de VIA contendrá via:<nombre_de_servidor>. Si esta aplicación se conecta a SQL a través de un protocolo distinto de VIA (tcp: o np: por ejemplo), no se encontrará ningún cambio importante. Además, ya no se admiten las conexiones a SQL Server 7 (1997).

Sugerencia

El protocolo VIA está en desuso, por lo que se debe usar un protocolo alternativo para conectarse a las bases de datos SQL. El protocolo que más se usa es TCP/IP. Para más información sobre cómo conectarse a través de TCP/IP, consulte el artículo sobre cómo habilitar el protocolo TCP/IP para una instancia de base de datos. Si solo se tiene acceso a la base de datos desde dentro de una intranet, el protocolo de canalizaciones compartidas puede proporcionar un mejor rendimiento si la red es lenta.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• SqlConnection(String)
• SqlConnection(String, SqlCredential)

Se produce un error de SqlConnection.Open en Windows 7 con presencia de un BSP o LSP de Winsock distinto de IFS

Detalles

Se produce un error de Open() y OpenAsync(CancellationToken) en .NET Framework 4.5 si se ejecutan en un equipo Windows 7 con un Winsock BSP o LSP que no sea IFS en el equipo. Para determinar si está instalado un LSP o BSP distinto de IFS, use el comando netsh WinSock Show Catalog y examine todos los elementos Winsock Catalog Provider Entry que se devuelven. Si el valor Service Flags tiene establecido el bit 0x20000, el proveedor usa controladores IFS y funcionará correctamente. Si el bit 0x20000 está claro (no establecido), se trata de un BSP o LSP distinto de IFS.

Sugerencia

Este error se corrigió en .NET Framework 4.5.2, por lo que se puede evitar actualizando a una versión posterior de .NET Framework. También puede evitarse eliminando cualquier LSP de Winsock distinto de IFS que haya instalado.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

instantáneas

Los valores NULL de fusionador no son visibles en el depurador hasta un paso posterior

Detalles

Un error en .NET Framework 4.5 hace que los valores establecidos mediante una operación de fusión NULL no sean visibles en el depurador inmediatamente después de ejecutar la operación de asignación cuando se ejecuta en la versión de 64 bits de la plataforma.

Sugerencia

Una ejecución paso a paso adicional en el depurador hará que el valor local o del campo se actualice correctamente. Ademas, este problema se ha corregido en .NET Framework 4.6; la actualización a esa versión debería solucionar el problema.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Entity Framework

Cambio de comportamiento en las API de lenguaje de definición de datos (DDL)

Detalles

El comportamiento de las API de DDL cuando se especifica AttachDBFilename ha cambiado tal y como se describe a continuación:

• Las cadenas de conexión no necesitan especificar un valor Initial Catalog. Anteriormente, se necesitaban los valores AttachDBFilename e Initial Catalog.
• Si se especifican los valores Initial Catalog y AttachDBFilename, y existe el archivo MDF indicado, el método DatabaseExists devuelve true. Anteriormente devolvía false.
• Si se especifican los valores Initial Catalog y AttachDBFilename, y existe el archivo MDF indicado, la llamada al método DeleteDatabase elimina los archivos.
• Si se llama a DeleteDatabase cuando la cadena de conexión especifica un valor AttachDBFilename con un archivo MDF y un valor Initial Catalog que no existen, el método inicia una excepción InvalidOperationException. Anteriormente iniciaba una excepción SqlException.

Sugerencia

Estos cambios facilitan la creación de herramientas y aplicaciones que utilizan las API de DDL. Estos cambios pueden afectar a la compatibilidad de las aplicaciones en los escenarios siguientes:

• El usuario escribe código que ejecuta directamente un comando DROP DATABASE en lugar de llamar al método DeleteDatabase si el método DatabaseExists devuelve true. Esto interrumpe el código existente si la base de datos no está asociada pero el archivo MDF existe.
• El usuario escribe código en el que espera que el método DeleteDatabase inicie una excepción SqlException en lugar de una excepción InvalidOperationException si no existen Initial Catalog ni el archivo MDF.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Control de excepciones diferente para los métodos ObjectContext.CreateDatabase y DbProviderServices.CreateDatabase

Detalles

A partir de .NET Framework 4.5, si se produce un error en la creación de la base de datos, los métodos CreateDatabase intentarán eliminar la base de datos vacía. Si esa operación se realiza correctamente, se propagará la excepción System.Data.SqlClient.SqlException original (en lugar de la excepción System.InvalidOperationException, que siempre se iniciaba en .NET Framework 4.0).

Sugerencia

Cuando se detecta una excepción System.InvalidOperationException al ejecutar CreateDatabase() o CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection), ahora también se deben detectar las excepciones SQLExceptions.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• ObjectContext.CreateDatabase()
• DbProviderServices.CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection)

EntityFramework 6.0 se carga muy lentamente en las aplicaciones iniciadas desde Visual Studio

Detalles

Iniciar una aplicación desde Visual Studio 2013 que usa EntityFramework 6.0 puede resultar muy lento.

Sugerencia

Este problema se corrigió en EntityFramework 6.0.2. Actualice EntityFramework para evitar el problema de rendimiento.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

El nombre de archivo de registro creado por el método ObjectContext.CreateDatabase ha cambiado para coincidir con las especificaciones de SQL Server

Detalles

Cuando se llama al método System.Data.Objects.ObjectContext.CreateDatabase() directamente o mediante Code First con el proveedor SqlClient y un valor AttachDBFilename en la cadena de conexión, se crea un archivo de registro denominado nombreDeArchivo_log.ldf en lugar de nombreDeArchivo.ldf (donde nombreDeArchivo es el nombre del archivo especificado mediante el valor AttachDBFilename). Este cambio mejora la depuración al proporcionar un archivo de registro cuyo nombre se ajusta a las especificaciones de SQL Server.

Sugerencia

Si el nombre de archivo de registro es importante para una aplicación, la aplicación debería actualizarse para que espere el formato de nombre de archivo estándar _log.ldf.

	Value
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• ObjectContext.CreateDatabase()

Los métodos ObjectContext.Translate y ObjectContext.ExecuteStoreQuery ahora admiten el tipo enum

Detalles

En .NET Framework 4.0, el parámetro genérico T de los métodos ObjectContext.Translate y ObjectContext.ExecuteStoreQuery no podía ser una enumeración. Ahora se admite este escenario.

Sugerencia

Si se llamaba a Translate o ExecuteStoreQuery en un tipo de enumeración en .NET Framework 4.0, se devolvía "0". Si este era el comportamiento deseado, las llamadas deberían reemplazarse por una constante 0 (o su tipo enum equivalente).

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• ObjectContext.Translate<TElement>(DbDataReader)
• ObjectContext.Translate<TEntity>(DbDataReader, String, MergeOption)
• ObjectContext.ExecuteStoreQuery<TElement>(String, Object[])
• ObjectContext.ExecuteStoreQuery<TEntity>(String, String, MergeOption, Object[])

LINQ

Enumerable.Empty<TResult> siempre devuelve una instancia almacenada en caché

Detalles

A partir de .NET Framework 4.5, Empty<TResult>() siempre devuelve una instancia interna de IEnumerable<T> en caché. Anteriormente, Empty<TResult>() almacenaba en caché un IEnumerable<T> vacío en el momento de llamar a la API, lo que significa que, en algunas condiciones en las que se llamaba a Empty<TResult>() de forma rápida y simultánea, se podían devolver otras instancias del tipo para otras llamadas a la API.

Sugerencia

Puesto que el comportamiento anterior no era determinista, es poco probable que el código dependa de él. No obstante, en el improbable caso de que se comparen enumerables vacíos y que se espere que a veces sean distintos, deberían crearse matrices vacías explícitas (new T[0]) en lugar de usar Empty<TResult>().

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• Enumerable.Empty<TResult>()

Managed Extensibility Framework (MEF)

Los catálogos de MEF implementan IEnumerable y, por tanto, ya no se pueden usar para crear un serializador

Detalles

A partir de .NET Framework 4.5, los catálogos de MEF implementan IEnumerable y, por tanto, ya no se pueden usar para crear un serializador (un objeto System.Xml.Serialization.XmlSerializer). Al intentar serializar un catálogo de MEF se inicia una excepción.

Sugerencia

Ya no se puede usar MEF para crear un serializador.

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Redes

Se puede producir un error en las deserialización de los objetos MailMessage serializados en .NET Framework 4.5

Detalles

A partir de .NET Framework 4.5, los objetos MailMessage pueden incluir caracteres que no sean ASCII. En .NET Framework 4, solo se admiten caracteres ASCII. Los objetos MailMessage que contienen caracteres que no son ASCII y que están serializados en .NET Framework 4.5 o una versión posterior no se pueden deserializar en .NET Framework 4.

Sugerencia

Asegúrese de que el código proporciona control de excepciones al deserializar un objeto MailMessage.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Web.Mail.MailMessage

System.Net.PeerToPeer.Collaboration no está disponible en Windows 8

Detalles

El espacio de nombres System.Net.PeerToPeer.Collaboration no está disponible en Windows 8 o posterior.

Sugerencia

Es necesario actualizar las aplicaciones compatibles con Windows 8 o posterior para no depender de este espacio de nombres ni sus miembros.

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Net.PeerToPeer.Collaboration

Impresión

Los datos escritos en PrintSystemJobInfo.JobStream deben estar en formato XPS

Detalles

La propiedad JobStream expone la secuencia de un trabajo de impresión. El usuario puede enviar datos sin formato a los componentes de impresión del sistema operativo subyacente si escribe en esta secuencia. A partir de .NET Framework 4.5 en Windows 8 y versiones posteriores del sistema operativo Windows, los datos que se escriben en esta secuencia deben estar en formato XPS como una secuencia de paquete.

Sugerencia

Para mostrar contenido de impresión, puede realizar una de las acciones siguientes:

• Utilice la clase XpsDocumentWriter para mostrar contenido de impresión. Esta es la alternativa recomendada.
• Asegúrese de que los datos enviados a la secuencia que devuelve la propiedad JobStream están en formato XPS como una secuencia de paquete.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• PrintSystemJobInfo.JobStream

Serialización

BinaryFormatter no puede encontrar el tipo en el contexto LoadFrom

Detalles

A partir de .NET Framework 4.5, un número de cambios en System.Xml.Serialization.XmlSerializer pueden provocar diferencias en la deserialización al usar System.Runtime.Serialization.Formatters.Binary.BinaryFormatter para deserializar los tipos que se han cargado en el contexto LoadFrom. Estos cambios se deben a las nuevas formas en las que System.Xml.Serialization.XmlSerializer carga ahora un tipo que provoca otro comportamiento cuando un System.Runtime.Serialization.Formatters.Binary.BinaryFormatter intenta deserializar en ese tipo más adelante. El enlazador de serialización predeterminado no busca automáticamente en el contexto LoadFrom, aunque es posible que haya funcionado en algunas circunstancias según el comportamiento anterior de XmlSerializer. Debido a los cambios, cuando se carga un tipo desde un ensamblado cargado en un otro contexto, se puede iniciar una excepción System.IO.FileNotFoundException.

Advertencia

La serialización binaria con BinaryFormatter puede ser peligrosa. Para más información, consulte Guía de seguridad de BinaryFormatter.

Sugerencia

Si esta excepción aparece, la propiedad Binder del System.Runtime.Serialization.Formatters.Binary.BinaryFormatter se puede establecer en un enlazador predeterminado que encontrará el tipo correcto.

var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }

Y, después, el enlazador predeterminado:

public class TypeFinderBinder : SerializationBinder
{
    private static readonly string s_assemblyName = Assembly.GetExecutingAssembly().FullName;

    public override Type BindToType(string assemblyName, string typeName)
    {
        return Type.GetType(String.Format(CultureInfo.InvariantCulture, "{0}, {1}", typeName, s_assemblyName));
    }
}

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
• BinaryFormatter.Deserialize(Stream)
• BinaryFormatter.Deserialize(Stream, HeaderHandler)

SoapFormatter no puede deserializar elementos Hashtable ni otros objetos de colecciones ordenados similares

Detalles

System.Runtime.Serialization.Formatters.Soap.SoapFormatter no garantiza que los objetos serializados en una versión de .NET Framework se deserialicen correctamente en otra versión. En concreto, en algunas colecciones ordenadas (como System.Collections.Hashtable) se agregaron miembros entre las versiones 4.0 y 4.5, de modo que los objetos de estos tipos no se pueden deserializar con .NET Framework 4.0 si se serializaron con .NET Framework 4.5. Si los datos se serializaron y deserializaron con la misma versión de .NET Framework, no ocurrirá ningún problema.

Sugerencia

La serialización de System.Runtime.Serialization.Formatters.Soap.SoapFormatter se debe reemplazar por la de System.Runtime.Serialization.Formatters.Binary.BinaryFormatter o System.Runtime.Serialization.NetDataContractSerializer para que sea resistente a los cambios de .NET Framework.

Advertencia

La serialización binaria con BinaryFormatter puede ser peligrosa. Para más información, consulte Guía de seguridad de BinaryFormatter.

Nombre	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• SoapFormatter.Serialize(Stream, Object)
• SoapFormatter.Serialize(Stream, Object, Header[])
• SoapFormatter.Deserialize(Stream)
• SoapFormatter.Deserialize(Stream, HeaderHandler)

Se produce un error en XmlSerializer al serializar un tipo que oculta un miembro accesible con otro inaccesible

Detalles

Al serializar un tipo derivado, se puede producir un error en System.Xml.Serialization.XmlSerializer si el tipo contiene un campo o una propiedad inaccesible que oculta (a través de la palabra clave "new") un campo o una propiedad del mismo nombre que previamente era accesible (public, por ejemplo) en el tipo base.

Sugerencia

Este problema se puede resolver haciendo que el nuevo miembro oculto sea accesible para System.Xml.Serialization.XmlSerializer (por ejemplo, marcándolo como público). Como alternativa, la siguiente configuración se revertirá al comportamiento 4.0 System.Xml.Serialization.XmlSerializer, que corregirá el problema:

<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• XmlSerializer.Serialize(Stream, Object)
• XmlSerializer.Serialize(TextWriter, Object)
• XmlSerializer.Serialize(Object, XmlSerializationWriter)
• XmlSerializer.Serialize(XmlWriter, Object)
• XmlSerializer.Serialize(Stream, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(TextWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String, String)

Aplicaciones web

Los controles de hospedaje de explorador administrado de .NET Framework 1.1 y 2.0 están bloqueados

Detalles

El hospedaje de estos controles está bloqueado en Internet Explorer.

Sugerencia

Internet Explorer no podrá iniciar una aplicación que use controles de hospedaje de explorador administrados. El comportamiento anterior se puede restaurar si se establece el valor EnableIEHosting de la subclave del Registro HKLM/SOFTWARE/MICROSOFT/.NETFramework en 1 para los sistemas x86 y para los procesos de 32 bits en sistemas x64, y el valor EnableIEHosting de la subclave del Registro HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework en 1 para los procesos de 64 bits en sistemas x64.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Windows Communication Foundation (WCF)

Los códigos de error para maxRequestLength o maxReceivedMessageSize son diferentes

Detalles

Los mensajes de servicios web de WCF hospedados en Internet Information Services (IIS) o Servidor de desarrollo de ASP.NET que superan maxRequestLength (en ASP.NET) o maxReceivedMessageSize (en WCF) tienen otro código de error. El código de estado HTTP ha cambiado de 400 (Solicitud incorrecta) a 413 (Entidad de solicitud demasiado grande), y los mensajes que superan el valor maxRequestLength o maxReceivedMessageSize inician una excepción System.ServiceModel.ProtocolException. Esto incluye los casos en los que el modo de transferencia es Streamed.

Sugerencia

Este cambio facilita la depuración en casos donde la longitud del mensaje supera los límites permitidos por ASP.NET o WCF. Debe modificar cualquier código que realice el procesamiento en función de un código de estado HTTP 400.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

El objeto System.ServiceModel.Web.WebServiceHost ya no agrega un punto de conexión predeterminado

Detalles

El objeto WebServiceHost ya no agrega un punto de conexión predeterminado si el código de la aplicación ha agregado un punto de conexión explícito.

Sugerencia

Si los usuarios esperan poder conectarse a un punto de conexión predeterminado y ya se han agregados otros puntos de conexión explícitos a System.ServiceModel.Web.WebServiceHost, los puntos de conexión predeterminados también se deben agregar de forma explícita (mediante System.ServiceModel.ServiceHostBase.AddDefaultEndpoints()).

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• ServiceHost.AddServiceEndpoint(Type, Binding, String)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, String, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHostBase.AddServiceEndpoint(ServiceEndpoint)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri, Uri)

El método Replace de las direcciones URL de OData está deshabilitado de forma predeterminada

Detalles

A partir de .NET Framework 4.5, el método Replace de direcciones URL de OData está deshabilitado de forma predeterminada. Cuando el método Replace de OData esté deshabilitado (ahora, de forma predeterminada), cualquier solicitud de usuario, incluidas las funciones Replace (que son poco frecuentes), generará un error.

Sugerencia

Si el método Replace es necesario (lo que es poco frecuente), se puede volver a habilitar mediante una opción de configuración (System.Data.Services.Configuration.DataServicesFeaturesSection.ReplaceFunction). No obstante, si el método Replace está activado, puede crear vulnerabilidades de seguridad y solo debería usarse tras una revisión exhaustiva.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Data.Services.DataService<T>

Windows Forms

Se llama repetidas veces a PreviewLostKeyboardFocus si su controlador muestra un cuadro de mensaje de Windows Forms

Detalles

A partir de .NET Framework 4.5, si se llama a MessageBox.Show desde un controlador de PreviewLostKeyboardFocus, se volverá a activar el controlador al cerrar el cuadro de mensaje, lo que podría generar un bucle infinito de cuadros de mensaje.

Sugerencia

Hay dos opciones para solucionar este problema:

• Se puede evitar llamando a MessageBox.Show en lugar de a MessageBox.Show.
• Se puede evitar mostrando el cuadro de mensaje desde un controlador de eventos LostKeyboardFocus (en contraposición a un controlador de eventos System.Windows.UIElement.PreviewLostKeyboardFocus).

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

La propiedad CheckForOverflowUnderflow de WinForm ahora es true para System.Drawing

Detalles

La propiedad CheckForOverflowUnderflow para el ensamblado System.Drawing.dll se establece en true.

Sugerencia

Anteriormente, cuando se producían desbordamientos, el resultado se truncaba de manera silenciosa. Ahora se inicia una excepción System.OverflowException.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Windows Presentation Foundation (WPF)

El acceso a los elementos seleccionados de un control DataGrid de WPF desde un controlador del evento UnloadingRow del control DataGrid puede producir una excepción NullReferenceException

Detalles

Debido a un error de .NET Framework 4.5, los controladores de eventos para los eventos DataGrid en los que se elimina una fila pueden provocar que se inicie una excepción System.NullReferenceException si tienen acceso a las propiedades System.Windows.Controls.Primitives.Selector.SelectedItem o System.Windows.Controls.Primitives.MultiSelector.SelectedItems de DataGrid.

Sugerencia

Este problema se ha corregido en .NET Framework 4.6 y se puede solucionar mediante la actualización a esa versión de .NET Framework.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• DataGrid.UnloadingRow
• DataGrid.UnloadingRowDetails

Las llamadas a DataGrid.CommitEdit desde un controlador CellEditEnding eliminan el foco

Detalles

Las llamadas a CommitEdit() desde uno de los controladores de eventos System.Windows.Controls.DataGrid.CellEditEnding de System.Windows.Controls.DataGrid provoca que System.Windows.Controls.DataGrid pierda el foco.

Sugerencia

Este error se corrigió en .NET Framework 4.5.2, por lo que se puede evitar actualizando a una versión posterior de .NET Framework. Como alternativa, se puede evitar si se selecciona System.Windows.Controls.DataGrid de forma explícita después de llamar a System.Windows.Controls.DataGrid.CommitEdit().

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

Llamar a Items.Refresh en un elemento ListBox o ListView, o una cuadrícula de datos de WPF con elementos seleccionados puede hacer que aparezcan elementos duplicados en el elemento

Detalles

En .NET Framework 4.5, llamar a ListBox.Items.Refresh desde el código con elementos seleccionados en un elemento System.Windows.Controls.ListBox puede hacer que los elementos seleccionados se dupliquen en la lista. Se produce un problema similar con System.Windows.Controls.ListView y System.Windows.Controls.DataGrid. Este problema se corrigió en .NET Framework 4.6.

Sugerencia

Una solución alternativa para este problema consiste en, mediante programación, anular la selección de los elementos antes de llamar a System.Windows.Data.CollectionView.Refresh() y volver a seleccionarlos después de que la llamada se complete. Este problema se resolvió en .NET Framework 4.6, por lo que otra posible solución es actualizar a esta versión de .NET Framework.

	Value
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• CollectionView.Refresh()

FlowDocument puede mostrar una línea de texto adicional

Detalles

En algunos casos, un elemento FlowDocument mostrará una línea de texto adicional cuando se ejecuta en .NET Framework 4.5 en comparación a cómo se mostraba cuando se ejecutaba en .NET Framework 4.0. No hay casos conocidos de que el cambio provoque que un texto se muestre de forma incorrecta o ilegible, pero podría dar la impresión de que el texto se omitió anteriormente de la vista de un FlowDocument.

Sugerencia

En algunos casos, reducir la propiedad PageHeight del elemento de visualización en uno puede restaurar el número anterior de líneas mostradas.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• FlowDocument()
• FlowDocument(Block)
• FlowDocumentReader()
• FlowDocumentPageViewer()
• DocumentPageView()

GlyphRun.ComputeInkBoundingBox() y FormattedText.Extent devuelven otros valores a partir de .NET Framework 4.5

Detalles

Se efectuaron mejoras en los elementos ComputeInkBoundingBox() y Extent en .NET Framework 4.5 para solucionar problemas por los que los rectángulos eran demasiado pequeños para los glifos incluidos en algunos casos en .NET Framework 4.0. Como resultado de ello, algunos rectángulos de selección son más grandes a partir de .NET Framework 4.5, por lo que hay ligeras diferencias en el diseño de la IU.

Sugerencia

Tenga en cuenta que los rectángulos de selección de algunos glifos ahora son de mayor tamaño. Por lo general, estos cambios mejorarán la presentación y las pruebas de acierto de los rectángulos, pero si se quiere revertir al comportamiento anterior (previo a la versión 4.5 de .NET Framework), puede añadirse la siguiente entrada al archivo app.config:

<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• GlyphRun.ComputeInkBoundingBox()
• FormattedText.Extent

Incapacidad intermitente para desplazarse hasta el último elemento de instancias ItemsControl (como ListBox y DataGrid) al usar elementos DataTemplate personalizados

Detalles

En algunos casos, un error de .NET Framework 4.5 impide que las instancias de ItemsControl (como System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox, System.Windows.Controls.DataGrid, etc.) se desplacen hasta su último elemento cuando se usan elementos DataTemplate personalizados. Si se trata de efectuar el desplazamiento una segunda vez (después de haber vuelto arriba), sí funciona.

Sugerencia

Este problema se resolvió en .NET Framework 4.5.2, por lo que otra posible solución es actualizar a esta versión (u otra posterior) de .NET Framework. Los usuarios también pueden arrastrar las barras de desplazamiento hasta los últimos elementos de estas colecciones, pero puede ser posible que tengan que hacerlo dos veces para conseguirlo.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Items.Clear no quita los duplicados de SelectedItems

Detalles

Supongamos que un Selector (con la selección múltiple habilitada) tiene duplicados en su colección System.Windows.Controls.Primitives.MultiSelector.SelectedItems: el mismo elemento aparece más de una vez. Si esos elementos se quitan del origen de datos (por ejemplo, mediante una llamada a Items.Clear), no se quitan de System.Windows.Controls.Primitives.MultiSelector.SelectedItems; solo se quita la primera instancia. Además, el uso posterior de System.Windows.Controls.Primitives.MultiSelector.SelectedItems (como SelectedItems.Clear()) puede tener problemas, como una excepción System.ArgumentException, porque System.Windows.Controls.Primitives.MultiSelector.SelectedItems contiene elementos que ya no están en el origen de datos.

Sugerencia

Si es posible, actualice a .NET Framework 4.6.2.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• MultiSelector.SelectedItems

Problema de enlace de IsSelected de ListBoxItem con ObservableCollection<T>.Move

Detalles

Las llamadas a Move(Int32, Int32) o MoveItem(Int32, Int32) en una colección enlazada a un control System.Windows.Controls.ListBox con elementos seleccionados puede provocar un comportamiento incorrecto en la selección o anulación de selecciones futuras de elementos System.Windows.Controls.ListBox.

Sugerencia

Las llamadas a System.Collections.ObjectModel.Collection<T>.Remove(T) y System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) en lugar de a Move(Int32, Int32) serán la solución alternativa a este problema. Este problema se resolvió en .NET Framework 4.6, por lo que otra posible solución es actualizar a esta versión de .NET Framework.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• ObservableCollection<T>.Move(Int32, Int32)
• ObservableCollection<T>.MoveItem(Int32, Int32)

Nuevos valores de enumeración en PageRangeSelection de WPF

Detalles

Se han agregado dos miembros nuevos (System.Windows.Controls.PageRangeSelection.CurrentPage y System.Windows.Controls.PageRangeSelection.SelectedPages) a la enumeración System.Windows.Controls.PageRangeSelection.

Sugerencia

En la mayoría de los casos, estos cambios no afectan al código del usuario. Pero se debe modificar el código que depende de un número concreto de elementos existentes en las llamadas a GetNames(Type) o GetValues(Type) del tipo System.Windows.Controls.PageRangeSelection.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Windows.Controls.PageRangeSelection

Se llama repetidas veces a PreviewLostKeyboardFocus si su controlador muestra un cuadro de mensaje de Windows Forms

Detalles

A partir de .NET Framework 4.5, si se llama a MessageBox.Show desde un controlador de PreviewLostKeyboardFocus, se volverá a activar el controlador al cerrar el cuadro de mensaje, lo que podría generar un bucle infinito de cuadros de mensaje.

Sugerencia

Hay dos opciones para solucionar este problema:

• Se puede evitar llamando a MessageBox.Show en lugar de a MessageBox.Show.
• Se puede evitar mostrando el cuadro de mensaje desde un controlador de eventos LostKeyboardFocus (en contraposición a un controlador de eventos System.Windows.UIElement.PreviewLostKeyboardFocus).

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

Al hacer clic con el botón derecho en un encabezado de fila de DataGrid de WPF se cambia la selección del control DataGrid

Detalles

Como resultado de hacer clic con el botón derecho en una encabezado de fila de System.Windows.Controls.DataGrid seleccionado con varias filas seleccionadas, solo cambia la selección de System.Windows.Controls.DataGrid en esa fila.

Sugerencia

Este problema se ha corregido en .NET Framework 4.6 y se puede solucionar mediante la actualización a esa versión de .NET Framework.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• DataGrid()

El desplazamiento de una instancia de TreeView o ListBox agrupada de WPF en un elemento VirtualizingStackPanel puede provocar que la aplicación deje de responder.

Detalles

En .NET Framework 4.5, desplazar un elemento System.Windows.Controls.TreeView de WPF en un panel StackPanel virtualizado puede provocar que el programa deje de responder si hay márgenes en la ventanilla (entre los elementos de System.Windows.Controls.TreeView, por ejemplo, o en algún elemento ItemsPresenter). Además, en algunos casos, los elementos de diferentes tamaños de la vista pueden originar inestabilidad aun cuando no haya márgenes.

Sugerencia

Este error puede evitarse actualizando a .NET Framework 4.5.1. Como alternativa, se pueden eliminar los márgenes de las colecciones de vista (como las instancias de System.Windows.Controls.TreeView) dentro de los paneles StackPanel virtualizados si todos los elementos contenidos son del mismo tamaño.

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

Los elementos DataTemplate de WPF ahora son visibles en la UIA

Detalles

Anteriormente, los elementos System.Windows.DataTemplate no eran visibles para la automatización de la interfaz de usuario. A partir de la versión 4.5, la automatización de la IU detectará estos elementos. Esto resulta útil en muchos casos, pero puede interrumpir las pruebas que dependan de árboles de la UIA que no contengan elementos System.Windows.DataTemplate.

Sugerencia

Puede ser necesario actualizar las pruebas de automatización de la interfaz de usuario para esta aplicación con el fin de procesar el árbol de la UIA que ahora incluye elementos System.Windows.DataTemplate que antes no eran visibles. Por ejemplo, en aquellas pruebas en las que se espere que haya ciertos elementos contiguos entre sí, ahora puede ser necesario esperar ciertos elementos intermedios de la UIA que antes no eran visibles. También puede ser necesario actualizar con nuevos valores pruebas que dependan de ciertos recuentos o índices para elementos de la UIA.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• DataTemplate()
• DataTemplate(Object)

El elemento DispatcherSynchronizationContext.CreateCopy de WPF ahora devuelve una copia nueva en lugar de la instancia actual

Detalles

En .NET Framework 4, CreateCopy() devolvía una referencia a la instancia actual, principalmente como optimización del rendimiento. En .NET Framework 4.5, devuelve una nueva instancia que permite concluir por primera vez que las mismas referencias indican que el subproceso de ejecución se encuentra en el contexto de sincronización correcto. Es poco probable que el código que comprueba la identidad de estas referencias se vea afectado, pero debido al cambio, el código que llama a CreateCopy() se debería probar como parte de la migración a .NET Framework 4.5 o una versión posterior.

Sugerencia

Tenga en cuenta que CreateCopy() ahora devolverá un objeto System.Threading.SynchronizationContext nuevo. Anteriormente, el código que usaba la equivalencia de referencias generadas de esta forma no comprobaba en realidad si se encontraba en el contexto correcto, pero sí lo hace si se compila en .NET Framework 4.5 o una versión posterior. Aunque es poco probable que cause problemas, debería bastar con ejecutar las rutas de acceso del código afectado para comprobar si lo hace.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• DispatcherSynchronizationContext.CreateCopy()

Los cuadros de texto de WPF tienen como valor predeterminado un límite de 100 para la fase de reversión

Detalles

En .NET Framework 4.5, el límite para la fase de reversión de un cuadro de texto de WPF es de 100 (a diferencia de .NET Framework 4.0, donde no existía ningún límite).

Sugerencia

Si el límite de 100 para la fase de reversión es demasiado bajo, se puede establecer de forma explícita con UndoLimit.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Windows.Controls.TextBox

El texto seleccionado de un cuadro de texto de WPF aparece en otro color cuando el cuadro de texto está inactivo

Detalles

En .NET Framework 4.5, cuando un control de cuadro de texto de WPF está inactivo (sin el foco), el texto seleccionado dentro del cuadro aparecerá en un color diferente al que lo haría con el control activo.

Sugerencia

El comportamiento anterior (.NET Framework 4.0) se puede restaurar si se establece la propiedad AreInactiveSelectionHighlightBrushKeysSupported en false.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Windows.Controls.TextBox

El elemento TreeViewItem de WPF se debe usar dentro de una instancia de TreeView

Detalles

En la versión 4.5 se introdujo un cambio que restringe el uso de elementos System.Windows.Controls.TreeViewItem fuera de una instancia de System.Windows.Controls.TreeView. Se manifiesta en las siguientes condiciones:

• Cuando el elemento primario del objeto visual de System.Windows.Controls.TreeViewItem no es un panel. (Un elemento System.Windows.Controls.TreeViewItem generado para una instancia de System.Windows.Controls.TreeView tendrá un panel como su elemento primario).
• Cuando el elemento System.Windows.Controls.TreeViewItem es un descendiente de una instancia de System.Windows.Controls.VirtualizingStackPanel que actúa como "host de elementos" para un control de lista (ListBox, DataGrid, ListView, etc.). No es necesario que la virtualización esté activada.
• El panel System.Windows.Controls.VirtualizingStackPanel se desplaza por elementos (ScrollUnit="Item").
• Alguien llama a VirtualizingStackPanel.MakeVisible(v) para desplazar un elemento v a la vista. Puede hacerse de forma explícita, o bien implícita de diferentes formas; tal vez la más habitual sea simplemente hacer clic en v para asignarle el foco del teclado.
• La cadena del elemento primario del objeto visual desde v a System.Windows.Controls.VirtualizingStackPanel pasa a través del elemento System.Windows.Controls.TreeViewItem.

En otras palabras, esto se observa cuando se usa un elemento System.Windows.Controls.TreeViewItem fuera de una instancia de System.Windows.Controls.TreeView y el usuario hace clic en un descendiente del elemento System.Windows.Controls.TreeViewItem para mostrarlo en la vista. Si el elemento System.Windows.Controls.TreeViewItem no tiene ningún descendiente activable, nunca observará este problema. Un ejemplo de situación en la que se produce este problema es cuando el elemento System.Windows.Controls.TreeViewItem es la raíz de una instancia de DataTemplate. Cuando se produce este problema, se genera una instancia InvalidCastException dentro del marco de WPF.

Sugerencia

Se lanzará una revisión para esta solucionar esta situación.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Windows Workflow Foundation (WF)

System.Activities ahora es APTCA

Detalles

El ensamblado está marcado con el atributo System.Security.AllowPartiallyTrustedCallersAttribute.

Sugerencia

Las clases derivadas no se pueden marcar con el atributo System.Security.SecurityCriticalAttribute. Anteriormente, los tipos derivados tenían que marcarse con el atributo System.Security.SecurityCriticalAttribute. Sin embargo, este cambio no debería tener ningún impacto.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

WF ahora serializa el valor Expressions.Literal<T> DateTimes de forma diferente (interrumpe los analizadores de XAML personalizados)

Detalles

El objeto ValueSerializer asociado convertirá un objeto System.DateTime o System.DateTimeOffset cuyos componentes Second y System.DateTime.Millisecond sean distintos de cero y (para un valor System.DateTime) cuya propiedad Kind no sea Unspecified en la sintaxis del elemento de propiedad en lugar de en una cadena. Este cambio permite realizar un recorrido de ida y vuelta por los valores System.DateTime y System.DateTimeOffset. Los analizadores XAML personalizados que presuponen que la entrada XAML está en la sintaxis del atributo no funcionarán correctamente.

Sugerencia

Este cambio permite realizar un recorrido de ida y vuelta por los valores System.DateTime y System.DateTimeOffset. Los analizadores XAML personalizados que presuponen que la entrada XAML está en la sintaxis del atributo no funcionarán correctamente.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

XML, XSLT

XmlSchemaException ahora establece correctamente las posiciones de las líneas

Detalles

Si el valor de SetLineInfo se pasa al método Load y se produce un error de validación, las propiedades LineNumber y LinePosition contendrán ahora la información de línea.

Sugerencia

Se debe actualizar el código de control de excepciones que suponga que LineNumber y LinePosition no se van a establecer, ya que ahora estas propiedades se establecerán correctamente al usar SetLineInfo durante la carga de XML.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• LoadOptions.SetLineInfo

La expansión de entidades DTD de XmlTextReader está limitada a 10 000 000 caracteres

Detalles

La expansión de entidades DTD ahora está limitada a 10 000 000 caracteres. La carga de archivos XML sin expansión de entidades DTD o con expansión de entidades DTD limitada no se verá afectada. Los archivos con entidades de DTD que se expanden a más de 10.000.000 caracteres no se podrán cargar y ahora iniciarán una excepción.

Sugerencia

Si el límite de expansión de entidades DTD de 10 000 000 es demasiado bajo, el valor se puede anular con la propiedad MaxCharactersFromEntities. Se puede pasar un System.Xml.XmlReaderSettings con el valor System.Xml.XmlReaderSettings.MaxCharactersFromEntities adecuado a XmlReader.Create que toma System.Xml.XmlReaderSettings (por ejemplo, Create(String, XmlReaderSettings))

Nombre	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Xml.XmlTextReader
• XmlTextReader()
• XmlTextReader(Stream)
• XmlTextReader(Stream, XmlNameTable)
• XmlTextReader(Stream, XmlNodeType, XmlParserContext)
• XmlTextReader(TextReader)
• XmlTextReader(TextReader, XmlNameTable)
• XmlTextReader(String)
• XmlTextReader(String, Stream)
• XmlTextReader(String, Stream, XmlNameTable)
• XmlTextReader(String, TextReader)
• XmlTextReader(String, TextReader, XmlNameTable)
• XmlTextReader(String, XmlNameTable)
• XmlTextReader(String, XmlNodeType, XmlParserContext)
• XmlTextReader(XmlNameTable)

Ya funciona la compatibilidad con versiones posteriores de XSLT

Detalles

En .NET Framework 4, la compatibilidad con versiones posteriores de XSLT 1.0 presentaba los problemas siguientes:

• La carga de una hoja de estilos no se realizaba correctamente si su versión estaba establecida en 2.0 y el analizador encontraba una construcción de XSLT 1.0 desconocida.
• La construcción xsl:sort no podía ordenar los datos si la versión de la hoja de estilos estaba establecida en 1.1. En .NET Framework 4.5, se han corregido estos problemas y el modo de compatibilidad con versiones posteriores de XSLT 1.0 funciona correctamente.

Sugerencia

La mayoría de las aplicaciones no deberían verse afectadas, pero en algunos casos los datos se ordenarán de otra forma ahora que se respeta xsl:sort. Si se usa xsl:sort en hojas de estilo de la versión 1.1, confirme que las aplicaciones no dependían del orden de los datos sin ordenar. Si las aplicaciones se basan en el comportamiento de ordenación de la versión 4.0, quite xsl:sort de la hoja de estilos.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• System.Xml.Xsl.XslCompiledTransform

Cambio del mensaje de excepción de la hoja de estilos XSLT

Detalles

En .NET Framework 4.5, el texto del mensaje de error cuando un archivo XSLT es demasiado complejo es "The style sheet is too complex" (La hoja de estilos es demasiado compleja). En versiones anteriores, el mensaje de error era "XSLT compile error" (Error de compilación de XSLT). El código de aplicación que se base en el texto del mensaje de error ya no funcionará. Sin embargo, los tipos de excepción siguen siendo iguales, por lo que este cambio no debería tener ningún impacto real.

Sugerencia

Actualice cualquier código de aplicación en función del mensaje de la excepción de esta condición de error para que espere el mensaje nuevo, o bien (e incluso mejor), actualice el código para que solo dependa del tipo de excepción (System.Xml.Xsl.XsltException), que no ha cambiado.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• XslCompiledTransform.Load(String)
• XslCompiledTransform.Load(Type)
• XslCompiledTransform.Load(XmlReader)
• XslCompiledTransform.Load(IXPathNavigable)
• XslCompiledTransform.Load(MethodInfo, Byte[], Type[])
• XslCompiledTransform.Load(String, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(XmlReader, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(IXPathNavigable, XsltSettings, XmlResolver)

.NET Framework 4.5.1

ADO.NET

ADO.NET ahora intenta volver a conectar automáticamente las conexiones SQL interrumpidas

Detalles

A partir de la versión 4.5.1, .NET Framework intentará volver a conectar automáticamente las conexiones SQL interrumpidas. Aunque por lo general esto hará que las aplicaciones sean más confiables, hay casos extremos en los que la aplicación tiene que saber que se perdió la conexión para poder realizar alguna acción al volverse a conectar.

Sugerencia

Si por motivos de compatibilidad no quiere esta característica, se puede deshabilitar estableciendo la propiedad System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount de una cadena de conexión (o System.Data.SqlClient.SqlConnectionStringBuilder) en 0.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

Core

Un elemento ConcurrentDictionary serializado en .NET Framework 4.5 con NetDataContractSerializer no se puede deserializar en .NET Framework 4.5.1 ni 4.5.2

Detalles

Debido a los cambios internos en el tipo, los objetos ConcurrentDictionary<TKey,TValue> que se serializaron con .NET Framework 4.5 mediante System.Runtime.Serialization.NetDataContractSerializer no se pueden deserializar en .NET Framework 4.5.1 o 4.5.2. Tenga en cuenta que a la inversa sí funciona (la serialización con .NET Framework 4.5.x y la deserialización con .NET Framework 4.5). Del mismo modo, la serialización entre todas las versiones 4.x funciona con .NET Framework 4.6. La serialización y deserialización con una única versión de .NET Framework no se ve afectada.

Sugerencia

Si es necesario serializar y deserializar un objeto System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> entre .NET Framework 4.5 y .NET Framework 4.5.1/4.5.2, se debe usar un serializador diferente, como System.Runtime.Serialization.DataContractSerializer, en vez de System.Runtime.Serialization.NetDataContractSerializer. Este problema se resolvió en .NET Framework 4.6, por lo que otra posible solución es actualizar a esta versión de .NET Framework.

Nombre	Valor
Ámbito	Secundaria
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

ConcurrentQueue<T>.TryPeek puede devolver un valor NULL erróneo mediante su parámetro out

Detalles

En algunos escenarios con múltiples subprocesos, System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) puede devolver true, pero rellenar el parámetro out con un valor nulo (en lugar del valor correcto observado).

Sugerencia

Este problema se corrigió en .NET Framework 4.5.1. Actualizar a esta versión de .NET Framework solucionará el problema.

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• ConcurrentQueue<T>.TryPeek(T)

Los generadores de perfiles no enumeran COR_PRF_GC_ROOT_HANDLE

Detalles

En .NET Framework v4.5.1, el método RootReferences2() de la API de generación de perfiles de manera incorrecta nunca devuelve COR_PRF_GC_ROOT_HANDLE (en su lugar se devuelven como COR_PRF_GC_ROOT_OTHER). Este problema se corrigió a partir de .NET Framework 4.6.

Sugerencia

Este problema se ha corregido en .NET Framework 4.6 y se puede solucionar mediante la actualización a esa versión de .NET Framework.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Se puede producir un error en la deserialización de objetos entre dominios de aplicación

Detalles

En algunos casos, cuando una aplicación usa dos o más dominios de aplicación con distintas bases de aplicación, un intento de deserializar objetos en el contexto de llamada lógico entre dominios de aplicación produce una excepción.

Sugerencia

Consulte Mitigación: deserialización de objetos en distintos dominios de aplicación

NOMBRE	Valor
Ámbito	Borde
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

EventListener trunca las cadenas con valores NULL insertados

Detalles

System.Diagnostics.Tracing.EventListener trunca las cadenas con valores NULL incrustados. Los caracteres NULL no son compatibles con la clase System.Diagnostics.Tracing.EventSource. El cambio solo afecta a las aplicaciones que usan System.Diagnostics.Tracing.EventListener para leer datos System.Diagnostics.Tracing.EventSource en proceso y que utilizan caracteres NULL como delimitadores.

Sugerencia

Se deben actualizar los datos de System.Diagnostics.Tracing.EventSource, si es posible, para que no usen valores NULL insertados.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

• EventListener()
• EventListener.EnableEvents(EventSource, EventLevel)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords, IDictionary<String,String>)

Las implementaciones EventSource.WriteEvent deben pasar a WriteEvent los mismos parámetros que recibió (además del identificador)

Detalles

El runtime ahora aplica el contrato que especifica lo siguiente: una clase derivada de System.Diagnostics.Tracing.EventSource que define un método de evento ETW debe llamar al método EventSource.WriteEvent de la clase base con el identificador de evento, seguido de los mismos argumentos que se pasaron al método de evento ETW.

Sugerencia

Se produce una excepción System.IndexOutOfRangeException si un objeto System.Diagnostics.Tracing.EventListener lee datos System.Diagnostics.Tracing.EventSource en proceso para un origen de eventos que infringe este contrato.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Las sobrecargas de Marshal.SizeOf y Marshal.PtrToStructure interrumpen el código dinámico

Detalles

A partir de .NET Framework 4.5.1, el enlace dinámico a los métodos SizeOf<T>(), SizeOf<T>(T), PtrToStructure(IntPtr, Object), PtrToStructure(IntPtr, Type), PtrToStructure<T>(IntPtr) o PtrToStructure<T>(IntPtr, T) (por ejemplo, a través de Windows PowerShell, IronPython o la palabra clave dynamic de C#) puede dar lugar a excepciones MethodInvocationExceptions, ya que se han agregado nuevas sobrecargas de estos métodos que pueden resultar ambiguas para los motores de scripting.

Sugerencia

Actualice los scripts para que indiquen claramente qué sobrecarga se debe usar. Normalmente, puede hacerse convirtiendo de forma explícita los parámetros de tipo del método como Type. Visite este vínculo para consultar información más detallada y ejemplos de soluciones alternativas para este problema.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Algunas API de .NET generan primeras excepciones EntryPointNotFoundExceptions (controladas)

Detalles

En .NET Framework 4.5, un pequeño número de métodos de .NET comenzaron a iniciar primeras excepciones System.EntryPointNotFoundException. Estas primeras excepciones se controlaban dentro de .NET Framework, pero podían interrumpir la automatización de las pruebas que no las esperasen. Estas mismas API interrumpen algunos escenarios de ApiVerifier con el elemento HighVersionLie habilitado.

Sugerencia

Este error puede evitarse actualizando a .NET Framework 4.5.1. Como alternativa, la automatización de pruebas se puede actualizar para no interrumpir las excepciones de primera oportunidad System.EntryPointNotFoundException.

	Value
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

Los adaptadores de flujo de WinRT no llaman a FlushAsync de manera automática al cerrarse

Detalles

En las aplicaciones de Microsoft Store, los adaptadores de secuencia de Windows Runtime ya no llaman al método FlushAsync desde el método Dispose.

Sugerencia

Este cambio debe ser transparente. Los desarrolladores pueden restaurar el comportamiento anterior escribiendo código similar al siguiente:

using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}

NOMBRE	Valor
Ámbito	Transparente
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

data

ADO.NET ahora intenta volver a conectar automáticamente las conexiones SQL interrumpidas

Detalles

A partir de la versión 4.5.1, .NET Framework intentará volver a conectar automáticamente las conexiones SQL interrumpidas. Aunque por lo general esto hará que las aplicaciones sean más confiables, hay casos extremos en los que la aplicación tiene que saber que se perdió la conexión para poder realizar alguna acción al volverse a conectar.

Sugerencia

Si por motivos de compatibilidad no quiere esta característica, se puede deshabilitar estableciendo la propiedad System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount de una cadena de conexión (o System.Data.SqlClient.SqlConnectionStringBuilder) en 0.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

Serialización

NetDataContractSerializer no puede deserializar un elemento ConcurrentDictionary serializado con otra versión de .NET

Detalles

Por diseño, solo se puede usar System.Runtime.Serialization.NetDataContractSerializer si los extremos de serialización y de deserialización comparten los mismos tipos CLR. Por tanto, no se garantiza que un objeto serializado con una versión de .NET Framework se pueda deserializar con otra versión. System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> es un tipo conocido por no deserializarse correctamente si se ha serializado con .NET Framework 4.5 o versiones anteriores y se ha deserializado con .NET Framework 4.5.1 o versiones posteriores.

Sugerencia

Hay una serie de soluciones posibles para este problema:

• Actualice el equipo que realiza la serialización para usar .NET Framework 4.5.1 también.
• Use System.Runtime.Serialization.DataContractSerializer en lugar de System.Runtime.Serialization.NetDataContractSerializer dado que no espera los mismos tipos CLR exactos en los extremos de serialización y deserialización.
• Use System.Collections.Generic.Dictionary<TKey,TValue> en lugar de System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> dado que no muestra esta interrupción determinada de 4.5->4.5.1.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

• NetDataContractSerializer.Deserialize(Stream)

Windows Communication Foundation (WCF)

Ahora se respeta MinFreeMemoryPercentageToActiveService

Detalles

Este ajuste establece la memoria mínima que debe estar disponible en el servidor para que se pueda activar un servicio WCF. Está diseñado para evitar las excepciones System.OutOfMemoryException. En .NET Framework 4.5, este ajuste no tenía ningún efecto. En .NET Framework 4.5.1, este ajuste se respeta.

Sugerencia

Se produce una excepción si la memoria libre disponible en el servidor web es menor que el porcentaje definido por la opción de configuración. Algunos servicios WCF que se iniciaban y ejecutaban correctamente en un entorno de memoria restringida ahora pueden producir errores.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.1
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Windows Presentation Foundation (WPF)

El desplazamiento de una instancia de TreeView o ListBox agrupada de WPF en un elemento VirtualizingStackPanel puede provocar que la aplicación deje de responder.

Detalles

En .NET Framework 4.5, desplazar un elemento System.Windows.Controls.TreeView de WPF en un panel StackPanel virtualizado puede provocar que el programa deje de responder si hay márgenes en la ventanilla (entre los elementos de System.Windows.Controls.TreeView, por ejemplo, o en algún elemento ItemsPresenter). Además, en algunos casos, los elementos de diferentes tamaños de la vista pueden originar inestabilidad aun cuando no haya márgenes.

Sugerencia

Este error puede evitarse actualizando a .NET Framework 4.5.1. Como alternativa, se pueden eliminar los márgenes de las colecciones de vista (como las instancias de System.Windows.Controls.TreeView) dentro de los paneles StackPanel virtualizados si todos los elementos contenidos son del mismo tamaño.

NOMBRE	Valor
Ámbito	Major
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

.NET Framework 4.5.2

ASP.NET

ASP.NET MVC ahora aplica caracteres de escape a los espacios de las cadenas que se pasan a través de parámetros de ruta

Detalles

Para cumplir con RFC 2396, ahora se aplican caracteres de escape a los espacios de las rutas de acceso al rellenar parámetros de acción desde una ruta. Por tanto, mientras que /controller/action/some data antes coincidía con la ruta /controller/action/{data} y proporcionaba some data como parámetro de datos, ahora proporciona some%20data.

Sugerencia

Debería actualizarse el código para no eliminar las secuencias de escape de los parámetros de las cadenas desde una ruta. Si se necesita el identificador URI original, se puede tener acceso a él con la API RequestUri.OriginalString.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.2
Tipo	Tiempo de ejecución

API afectadas

• RouteAttribute(String)

Ya no se puede establecer EnableViewStateMac en false

Detalles

ASP.NET ya no permite a los desarrolladores especificar <pages enableViewStateMac=&quot;false&quot;/> o <@Page EnableViewStateMac=&quot;false&quot; %>. El código de autenticación de mensajes (MAC) de estado de vista ahora es obligatorio para todas las solicitudes con estado de vista integrado. Solo afecta a las aplicaciones en las que la propiedad EnableViewStateMac esté establecida específicamente en false.

Sugerencia

Se debe suponer que EnableViewStateMac se establece en true y se debe resolver cualquier error de MAC resultante (como se explica en esta guía, que contiene varias resoluciones en función de la causa específica de los errores de MAC).

NOMBRE	Valor
Ámbito	Major
Versión	4.5.2
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Posible error irrecuperable en el motor de ejecución por parte de las aplicaciones de MVC4 de generación de perfiles de ASP.NET

Detalles

Los generadores de perfiles que usan ensamblados /Profile de NGEN pueden bloquear las aplicaciones de MVC4 con perfiles de ASP.NET durante el inicio con una "Excepción irrecuperable de motor de ejecución".

Sugerencia

Este problema se ha corregido en .NET Framework 4.5.2. Como alternativa, el generador de perfiles puede evitar este problema mediante la especificación de COR_PRF_DISABLE_ALL_NGEN_IMAGES en su máscara de eventos.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

data

Se produce un error de SqlConnection.Open en Windows 7 con presencia de un BSP o LSP de Winsock distinto de IFS

Detalles

Se produce un error de Open() y OpenAsync(CancellationToken) en .NET Framework 4.5 si se ejecutan en un equipo Windows 7 con un Winsock BSP o LSP que no sea IFS en el equipo. Para determinar si está instalado un LSP o BSP distinto de IFS, use el comando netsh WinSock Show Catalog y examine todos los elementos Winsock Catalog Provider Entry que se devuelven. Si el valor Service Flags tiene establecido el bit 0x20000, el proveedor usa controladores IFS y funcionará correctamente. Si el bit 0x20000 está claro (no establecido), se trata de un BSP o LSP distinto de IFS.

Sugerencia

Este error se corrigió en .NET Framework 4.5.2, por lo que se puede evitar actualizando a una versión posterior de .NET Framework. También puede evitarse eliminando cualquier LSP de Winsock distinto de IFS que haya instalado.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

Entity Framework

EF ya no inicia excepciones para elementos QueryView con características específicas

Detalles

Entity Framework ya no inicia una excepción System.StackOverflowException cuando una aplicación ejecuta una consulta que usa QueryView con una propiedad de navegación 0..1 que intenta incluir las entidades relacionadas como parte de la consulta. Por ejemplo, mediante una llamada a .Include(e => e.RelatedNavProp).

Sugerencia

Este cambio solo afecta al código que usa QueryViews con relaciones 1-0..1 cuando se ejecutan consultas que realizan llamadas a .Include. Mejora la fiabilidad y debe ser transparente para casi todas las aplicaciones. Pero puede deshabilitarlo si causa un comportamiento inesperado; para ello, agregue la entrada siguiente a la sección <appSettings> del archivo de configuración de la aplicación:

<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />

NOMBRE	Valor
Ámbito	Borde
Versión	4.5.2
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Permitir interrupción para revertir desde otra generación de SQL de la versión 4.5 a la generación de SQL más sencilla de la versión 4.0

Detalles

Las consultas que generan instrucciones JOIN y contienen una llamada a una operación de limitación sin usar primero OrderBy, ahora generan código SQL más sencillo. Después de actualizar a .NET Framework 4.5, estas consultas generaban código SQL más complicado que en versiones anteriores.

Sugerencia

Esta característica está deshabilitada de manera predeterminada. Si Entity Framework genera instrucciones JOIN adicionales que causan la degradación del rendimiento, puede habilitar esta característica mediante la adición de la entrada siguiente a la sección <appSettings> del archivo de configuración de la aplicación (app.config):

<add key="EntityFramework_SimplifyLimitOperations" value="true" />

NOMBRE	Valor
Ámbito	Transparente
Versión	4.5.2
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

Windows Presentation Foundation (WPF)

Las llamadas a DataGrid.CommitEdit desde un controlador CellEditEnding eliminan el foco

Detalles

Las llamadas a CommitEdit() desde uno de los controladores de eventos System.Windows.Controls.DataGrid.CellEditEnding de System.Windows.Controls.DataGrid provoca que System.Windows.Controls.DataGrid pierda el foco.

Sugerencia

Este error se corrigió en .NET Framework 4.5.2, por lo que se puede evitar actualizando a una versión posterior de .NET Framework. Como alternativa, se puede evitar si se selecciona System.Windows.Controls.DataGrid de forma explícita después de llamar a System.Windows.Controls.DataGrid.CommitEdit().

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

Incapacidad intermitente para desplazarse hasta el último elemento de instancias ItemsControl (como ListBox y DataGrid) al usar elementos DataTemplate personalizados

Detalles

En algunos casos, un error de .NET Framework 4.5 impide que las instancias de ItemsControl (como System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox, System.Windows.Controls.DataGrid, etc.) se desplacen hasta su último elemento cuando se usan elementos DataTemplate personalizados. Si se trata de efectuar el desplazamiento una segunda vez (después de haber vuelto arriba), sí funciona.

Sugerencia

Este problema se resolvió en .NET Framework 4.5.2, por lo que otra posible solución es actualizar a esta versión (u otra posterior) de .NET Framework. Los usuarios también pueden arrastrar las barras de desplazamiento hasta los últimos elementos de estas colecciones, pero puede ser posible que tengan que hacerlo dos veces para conseguirlo.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

WPF genera un proceso de wisptis.exe que puede inmovilizar el mouse

Detalles

En la versión 4.5.2 apareció un problema que hace que se genere wisptis.exe y que puede inmovilizar la entrada del mouse.

Sugerencia

Una corrección para este problema está disponible en una versión de servicio de .NET Framework 4.5.2 (paquete acumulativo de revisiones 3026376), o bien mediante la actualización a .NET Framework 4.6.

NOMBRE	Valor
Ámbito	Major
Versión	4.5.2
Tipo	Tiempo de ejecución

API afectadas

No detectable a través del análisis de la API.

XML

Cambios de análisis en XML

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.5.2
Tipo	Tiempo de ejecución

Detalles

Por motivos de seguridad, se han efectuado los cambios siguientes en las API de análisis en XML:

• XmlReaderSettings.MaxCharactersFromEntities se ha establecido en 10 millones al inicializar XmlReaderSettings.
• De forma predeterminada, la propiedad XmlReaderSettings.XmlResolver se establece en null.

Nota

Todos los analizadores en XML usan XmlReaderSettings, por lo que, aunque este cambio ayuda al caso XmlReader, también afecta a otros escenarios.

Sugerencia

Para revertir el comportamiento a uno anterior, puede establecer un valor en el registro. Agregue un valor DWORD denominado EnableLegacyXmlSettings a la clave del registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML y establezca su valor en 1. También puede agregar el valor del registro en el subárbol HKEY_CURRENT_USER.

API afectadas

• System.Xml.XmlReaderSettings.MaxCharactersFromEntities
• System.Xml.XmlReaderSettings.XmlResolver

Además, afectará a cualquier API XML que dependa de XmlResolver, ya sea directa o indirectamente.