Cambios de redestinación para la migración a .NET Framework 4.6.x

En este artículo se enumeran los problemas de compatibilidad de aplicaciones que se introdujeron en .NET Framework 4.6, 4.6.1 y 4.6.2.

.NET Framework 4.6

ASP.NET

HtmlTextWriter no representa el elemento <br/> de forma correcta

Detalles

A partir de .NET Framework 4.6, al llamar a RenderBeginTag(String) y RenderEndTag() con un elemento <BR /> solo insertará correctamente un <BR /> (en lugar de dos).

Sugerencia

Si alguna aplicación dependía de la etiqueta <BR /> adicional, debería llamarse a RenderBeginTag(String) una segunda vez. Tenga en cuenta que este cambio de comportamiento solo afecta a las aplicaciones que tengan como destino .NET Framework 4.6 o una versión posterior, por lo que otra opción es seleccionar como destino una versión anterior de .NET Framework para conseguir el comportamiento anterior.

NOMBRE	Valor
Ámbito	Borde
Versión	4.6
Tipo	Redestinación

API afectadas

• HtmlTextWriter.RenderBeginTag(String)
• HtmlTextWriter.RenderBeginTag(HtmlTextWriterTag)

ClickOnce

Puede producirse un error en las aplicaciones publicadas con ClickOnce que usan un certificado de firma de código SHA-256 en Windows 2003

Detalles

El archivo ejecutable está firmado con SHA-256. Antes se firmaba con SHA1, independientemente de si el certificado de firma de código era SHA-1 o SHA-256. Esto se aplica a lo siguiente:

• Todas las aplicaciones compiladas con Visual Studio 2012 o versiones posteriores.
• Aplicaciones compiladas con Visual Studio 2010 o versiones anteriores en sistemas con .NET Framework 4.5. Además, si está presente .NET Framework 4.5 o versiones posteriores, el manifiesto de ClickOnce también está firmado con SHA-256 para certificados SHA-256, independientemente de la versión de .NET Framework con la que se compiló.

Sugerencia

El cambio en la firma del ejecutable ClickOnce solo afecta a los sistemas Windows Server 2003; necesitan que KB 938397 esté instalado. El cambio al firmar el manifiesto con SHA-256, incluso cuando una aplicación tiene como destino .NET Framework 4.0 o versiones anteriores, introduce una dependencia de tiempo de ejecución en .NET Framework 4.5 o versiones posteriores.

NOMBRE	Valor
Ámbito	Borde
Versión	4.5
Tipo	Redestinación

ClickOnce admite SHA-256 en aplicaciones destinadas a la versión 4.0

Detalles

Anteriormente, una aplicación ClickOnce con un certificado firmado con SHA-256 requería la presencia de .NET Framework 4.5 o una versión posterior, incluso si la aplicación se destinaba a la versión 4.0. Ahora, las aplicaciones ClickOnce destinadas a .NET Framework 4.0 se pueden ejecutar en .NET Framework 4.0, incluso si están firmadas con SHA-256.

Sugerencia

Este cambio elimina esa dependencia y permite usar certificados de SHA-256 para firmar las aplicaciones ClickOnce que tienen como destino .NET Framework 4 y versiones anteriores.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación

Core

CurrentCulture y CurrentUICulture fluyen entre tareas

Detalles

A partir de la versión 4.6 de .NET Framework, System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture se almacenan en el System.Threading.ExecutionContext del subproceso, que fluye entre las operaciones asincrónicas. Esto significa que los cambios en System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture se verán reflejados en las tareas que después se ejecutan de forma asincrónica. Esto difiere del comportamiento de las versiones anteriores de .NET Framework (en las que se restablecían System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture en todas las tareas asincrónicas).

Sugerencia

Las aplicaciones afectadas por este cambio pueden solucionar el problema si se establece explícitamente el valor System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture deseado como la primera operación de una tarea asincrónica. Como alternativa, el comportamiento anterior (de que System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture no fluyan) se puede incluir si se establece el modificador de compatibilidad siguiente:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

WPF ha solucionado este problema en .NET Framework 4.6.2. También se ha corregido en .NET Framework 4.6, 4.6.1 a través de KB 3139549. Las aplicaciones destinadas a .NET Framework 4.6 o una versión posterior obtendrán automáticamente el comportamiento correcto en las aplicaciones de WPF: System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) se conservará entre las operaciones del distribuidor.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación

API afectadas

• CultureInfo.CurrentCulture
• Thread.CurrentCulture
• CultureInfo.CurrentUICulture
• Thread.CurrentUICulture

Los nombres de eventos de ETW no pueden diferir solamente en un sufijo "Start" o "Stop".

Detalles

En .NET Framework 4.6 y 4.6.1, el entorno de ejecución inicia una excepción ArgumentException cuando dos nombres de evento de Seguimiento de eventos para Windows (ETW) solamente difieren en un sufijo "Start" o "Stop" (como cuando un evento se denomina LogUser y otro LogUserStart). En este caso, el entorno en tiempo de ejecución no puede crear el origen de eventos, que no puede emitir ningún registro.

Sugerencia

Para evitar la excepción, asegúrese de que no haya dos nombres de evento que solo difieran en un sufijo "Start" o "Stop". Este requisito se ha eliminado a partir de .NET Framework 4.6.2; el entorno de ejecución puede eliminar la ambigüedad de los nombres de evento que solo difieren en el sufijo "Start" y "Stop".

NOMBRE	Valor
Ámbito	Borde
Versión	4.6
Tipo	Redestinación

Entity Framework

Se puede producir un error MSB4062 al compilar un archivo edmx de Entity Framework con Visual Studio 2013 si se usan las tareas EntityDeploySplit o EntityClean

Detalles

Las herramientas de MSBuild 12.0 (incluidas en Visual Studio 2013) cambiaron las ubicaciones de los archivos de MSBuild, lo que invalida los archivos de destinos antiguos de Entity Framework. El resultado es un error de las tareas EntityDeploySplit y EntityClean debido a que no pueden buscar Microsoft.Data.Entity.Build.Tasks.dll. Tenga en cuenta que esta interrupción se produce como consecuencia del cambio en un conjunto de herramientas (MSBuild/VS), no en .NET Framework. Solo se producirá al actualizar las herramientas de desarrollo, no al actualizar únicamente .NET Framework.

Sugerencia

Los archivos de destinos de Entity Framework se corrigieron para funcionar con el nuevo diseño de MSBuild a partir de .NET Framework 4.6. Este problema se soluciona actualizando a esta versión de .NET Framework. También es posible usar esta solución alternativa para aplicar la revisión directamente a los archivos de destinos.

NOMBRE	Valor
Ámbito	Major
Versión	4.5.1
Tipo	Redestinación

JIT

No se permite ret de IL en una región try

Detalles

A diferencia del compilador Just-In-Time JIT64, RyuJIT (que se usa en .NET Framework 4.6) no admite una instrucción ret de nivel de integridad en una región try. Devolver desde una región try no permite la especificación de ECMA-335 y ningún compilador administrado conocido genera tal IL. Sin embargo, el compilador JIT64 ejecutará dicho IL si se genera mediante la emisión de reflexión.

Sugerencia

Si una aplicación genera un IL que incluye un código de operación de ret en una región try, la aplicación puede tener como destino .NET Framework 4.5 para usar el JIT antiguo y evitar esta interrupción. Como alternativa, se puede actualizar el IL generado para que devuelva después de la región try.

NOMBRE	Valor
Ámbito	Borde
Versión	4.6
Tipo	Redestinación

Nuevo compilador JIT de 64 bits en .NET Framework 4.6

Detalles

A partir de .NET Framework 4.6, se utiliza un nuevo compilador JIT de 64 bits para la compilación Just-In-Time. En algunos casos, se inicia una excepción inesperada o se observa otro comportamiento que si se ejecuta una aplicación con el compilador de 32 bits o el compilador JIT de 64 bits antiguo. Este cambio no afecta al compilador JIT de 32 bits. Las diferencias conocidas incluyen lo siguiente:

• En determinadas condiciones, una operación de conversión unboxing puede producir una NullReferenceException en versiones de lanzamiento con la optimización activada.
• En algunos casos, la ejecución del código de producción en un cuerpo del método de gran tamaño puede producir una StackOverflowException.
• En determinadas condiciones, las estructuras que se pasan a un método se tratan como tipos de referencia en lugar de tipos de valor en las compilaciones de versión. Una de las manifestaciones de este problema es que los elementos individuales de una colección aparecen en un orden inesperado.
• En determinadas condiciones, la comparación de los valores UInt16 con su conjunto de bits altos es incorrecta si se habilita la optimización.
• En determinadas condiciones, especialmente al indexar los valores de matriz, la inicialización de la memoria mediante la instrucción IL OpCodes.Initblk puede inicializar la memoria con un valor incorrecto. Esto puede producir una excepción no controlada o resultados incorrectos.
• En determinadas condiciones poco frecuentes, una prueba de bits condicional puede devolver el valor Boolean incorrecto o producir una excepción si se habilitan las optimizaciones del compilador.
• En determinadas condiciones, si se utiliza una instrucción if para comprobar una condición antes de entrar en un bloque try y en la salida del bloque try, y se evalúa la misma condición en el bloque catch o finally, el compilador JIT de 64 bits nuevo quita la condición if del bloque catch o finally cuando optimiza el código. Como resultado, el código dentro de la instrucción if en el bloque catch o finally se ejecuta de forma incondicional.

Sugerencia

Mitigación de problemas conocidos
Si encuentra los problemas mencionados anteriormente, puede solucionarlos realizando las siguientes operaciones:

• Actualizar a the .NET Framework 4.6.2. El nuevo compilador de 64 bits incluido con .NET Framework 4.6.2 soluciona estos problemas conocidos.

• Asegurarse de que su versión Windows está actualizada ejecutando Windows Update. Las actualizaciones de servicio de .NET Framework 4.6 y 4.6.1 solucionan los problemas excepto NullReferenceException en una operación de conversión unboxing.

• Compilación con el compilador JIT de 64 bits más antiguo. Vea la sección Mitigación de otros problemas sección para obtener más información sobre el procedimiento. Mitigación de otros problemas
  Si detecta cualquier otra diferencia en el comportamiento entre el código compilado con el compilador de 64 bits antiguo y el compilador de 64 bits nuevo, o entre las versiones de depuración y publicación de la aplicación que se compilan con el nuevo compilador JIT de 64 bits, puede realizar el siguiente procedimiento para compilar la aplicación con el compilador JIT de 64 bits anterior:

• Según la aplicación, se puede agregar el elemento < al archivo de configuración de la aplicación. Lo siguiente deshabilita la compilación con el nuevo compilador JIT de 64 bits y en su lugar usa el compilador JIT de 64 bits hereado.

  <?xml version ="1.0"?>
  <configuration>
    <runtime>
     <useLegacyJit enabled="1" />
    </runtime>
  </configuration>
  

• Según el usuario, puede agregar un valor REG_DWORD con el nombre useLegacyJit a la clave HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework del registro. El valor 1 permite al compilador JIT de 64 bits hereado; un valor de 0 lo deshabilita y habilita el nuevo compilador JIT de 64 bits.

• Según el equipo, puede agregar un valor REG_DWORD con el nombre useLegacyJit a la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework del registro. El valor de 1 habilita el compilador JIT de 64 bits heredado; un valor de 0 lo deshabilita y habilita el compilador JIT de 64 bits nuevo. También puede informar del problema indicándonos el error en Microsoft Connect.

NOMBRE	Valor
Ámbito	Borde
Versión	4.6
Tipo	Redestinación

Redes

Validación de OID de EKU de certificado

Detalles

A partir de .NET Framework 4.6, las clases SslStream o ServicePointManager realizan la validación de identificador de objetos (OID) de uso mejorado de clave (EKU). Una extensión de uso mejorado de clave (EKU) es una colección de identificadores de objetos (OID) que indica las aplicaciones que usan la clave. En la validación de OID de EKU se usan devoluciones de llamada de certificado remoto para asegurarse de que el certificado remoto tiene los OID correctos para el propósito previsto.

Sugerencia

Si no quiere este cambio, puede deshabilitar la validación de OID del EKU del certificado agregando el modificador siguiente a <AppContextSwitchOverrides> en ` del archivo de configuración de la aplicación:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

Importante

Este valor solamente se proporciona por motivos de compatibilidad con versiones anteriores. Pero no se recomienda su uso.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación

API afectadas

• System.Net.Security.SslStream
• System.Net.ServicePointManager
• System.Net.Http.HttpClient
• System.Net.Mail.SmtpClient
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest

En System.Net.ServicePointManager y System.Net.Security.SslStream solo se admiten los protocolos TLS 1.0, 1.1 y 1.2

Detalles

A partir de .NET Framework 4.6, las clases ServicePointManager y SslStream solo pueden usar uno de los tres protocolos siguientes: Tls1.0, Tls1.1 o Tls1.2. No se admite el protocolo SSL 3.0 ni el cifrado RC4.

Sugerencia

La mitigación recomendada consiste en actualizar la aplicación del lado servidor a Tls1.0, Tls1.1 o Tls1.2. Si esto no es posible o si las aplicaciones cliente se interrumpen, se puede usar la clase System.AppContext para descartar esta característica de cualquiera de estas dos maneras:

• Configurando mediante programación los modificadores de compatibilidad en la instancia System.AppContext, como se explica aquí.
• Agregando la siguiente línea a la sección <runtime> del archivo app.config:

<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación

API afectadas

• SecurityProtocolType.Ssl3
• SslProtocols.None
• SslProtocols.Ssl2
• SslProtocols.Ssl3

De forma predeterminada, TLS 1.x pasa la marca SCH_SEND_AUX_RECORD a la API SCHANNEL subyacente.

Detalles

Cuando se usa TLS 1.x, .NET Framework se basa en la API SCHANNEL de Windows subyacente. A partir de .NET Framework 4.6, de forma predeterminada se pasa la marca SCH_SEND_AUX_RECORD a SCHANNEL. Esto hace que SCHANNEL divida los datos para que se cifren en dos registros independientes, el primero de un solo byte y el segundo de n-1 bytes. En raras ocasiones, esto interrumpe la comunicación entre los clientes y los servidores existentes; con esto se supone que los datos residen en un único registro.

Sugerencia

Si este cambio interrumpe la comunicación con un servidor existente, puede deshabilitar el envío de la marca SCH_SEND_AUX_RECORD y restaurar el comportamiento anterior de no dividir los datos en registros independientes si agrega el modificador siguiente al elemento <AppContextSwitchOverrides> en la sección <runtime> del archivo de configuración de la aplicación:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

Importante

Este valor solamente se proporciona por motivos de compatibilidad con versiones anteriores. Pero no se recomienda su uso.

NOMBRE	Valor
Ámbito	Borde
Versión	4.6
Tipo	Redestinación

API afectadas

• System.Net.Security.SslStream
• System.Net.ServicePointManager
• System.Net.Http.HttpClient
• System.Net.Mail.SmtpClient
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest

Windows Communication Foundation (WCF)

La llamada a CreateDefaultAuthorizationContext con un argumento NULL ha cambiado

Detalles

La implementación del elemento System.IdentityModel.Policy.AuthorizationContext devuelto por una llamada a System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) con un argumento authorizationPolicies nulo ha cambiado su implementación en .NET Framework 4.6.

Sugerencia

En raras ocasiones, las aplicaciones WCF que usan la autenticación personalizada pueden sufrir diferencias de comportamiento. En estos casos, es posible restaurar el comportamiento anterior de dos maneras:

• Vuelva a compilar la aplicación para que se dirija a una versión anterior a .NET Framework 4.6. Para los servicios hospedados en IIS, use el elemento <httpRuntime targetFramework="x.x"> para que se dirija a una versión anterior de .NET Framework.

• Agregue la siguiente línea a la sección <appSettings> del archivo app.config:

  <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
  

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación

API afectadas

• AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>)

Windows Forms

Icon.ToBitmap convierte correctamente los iconos con marcos PNG en objetos de mapa de bits

Detalles

A partir de las aplicaciones destinadas a .NET Framework 4.6, el método Icon.ToBitmap convierte correctamente los iconos con marcos PNG en objetos Bitmap.

En las aplicaciones destinadas a .NET Framework 4.5.2 y versiones anteriores, el método Icon.ToBitmap genera una excepción ArgumentOutOfRangeException si el objeto Icon tiene marcos PNG.

Este cambio afecta a las aplicaciones que se vuelven a compilar para tener como destino .NET Framework 4.6 y que implementan un control especial para ArgumentOutOfRangeException que se genera cuando un objeto Icon tiene marcos PNG. Cuando se ejecuta en .NET Framework 4.6, la conversión es correcta, ya no se genera un ArgumentOutOfRangeException y, por tanto, ya no se invoca el controlador de excepciones.

Sugerencia

Si no quiere este comportamiento, puede conservar el comportamiento anterior agregando el elemento siguiente a la sección <runtime> del archivo app.config:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

Si el archivo app.config ya contiene el elemento AppContextSwitchOverrides, el valor nuevo se debe combinar con el atributo value de esta forma:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación

API afectadas

• Icon.ToBitmap()

Windows Presentation Foundation (WPF)

CurrentCulture no se conserva entre operaciones del distribuidor de WPF

Detalles

A partir de .NET Framework 4.6, los cambios efectuados en System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture dentro de un System.Windows.Threading.Dispatcher se perderán al final de la operación de ese distribuidor. De igual forma, es posible que los cambios en System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture realizados fuera de una operación de distribuidor no surtan efecto cuando que se ejecuta esa operación. En términos prácticos, esto significa que es posible que los cambios en System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture no fluyan entre las devoluciones de llamada de la interfaz de usuario de WPF y otro código de una aplicación de WPF. Esto se debe a un cambio en System.Threading.ExecutionContext que hace que System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture se almacenen en el contexto de ejecución a partir de las aplicaciones destinadas a .NET Framework 4.6. Las operaciones de distribuidor de WPF almacenan el contexto de ejecución usado para iniciar la operación y restaurar el contexto anterior cuando la operación se complete. Dado que System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture ahora forman parte de este contexto, los cambios efectuados en ellas como parte de una operación de distribuidor no persisten fuera de la operación.

Sugerencia

Las aplicaciones afectadas por este cambio pueden solucionarlo si se almacenan los elementos System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture deseados en un campo y se protegen todos los cuerpos de las operaciones de distribuidor (incluidos los controladores de devolución de llamadas de eventos de interfaz de usuario) en los que se establezcan los elementos System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture correctos. Además, como el cambio de ExecutionContext subyacente a este cambio de WPF solo afecta a las aplicaciones destinadas a .NET Framework 4.6 o una versión más reciente, es posible evitar esta interrupción estableciendo como destino .NET Framework 4.5.2. Las aplicaciones destinadas a .NET Framework 4.6 o una versión posterior también pueden solucionarlo si se establece el modificador de compatibilidad siguiente:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

WPF ha solucionado este problema en .NET Framework 4.6.2. También se ha corregido en .NET Framework 4.6, 4.6.1 a través de KB 3139549. Las aplicaciones destinadas a .NET Framework 4.6 o una versión posterior obtendrán automáticamente el comportamiento correcto en las aplicaciones de WPF: System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) se conservará entre las operaciones del distribuidor.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación

Ha cambiado el redondeo del diseño de márgenes en WPF

Detalles

Ha cambiado la manera en la que se redondean los márgenes, así como los bordes y el fondo de estos. Debido a este cambio:

• El ancho o alto de los elementos puede aumentar o disminuir un píxel como máximo.
• La posición de un objeto se puede mover un píxel como máximo.
• Los elementos centrados pueden estar descentrados como máximo en un píxel en vertical o en horizontal. De forma predeterminada, este nuevo diseño solo está habilitado para las aplicaciones que tienen como destino .NET Framework 4.6.

Sugerencia

Dado que esta modificación tiende a eliminar el recorte de la parte derecha o inferior de los controles WPF en PPP altos, las aplicaciones destinadas a versiones anteriores de .NET Framework que se ejecutan en .NET Framework 4.6 pueden optar por este nuevo comportamiento agregando la siguiente línea a la sección <runtime> del archivo app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

Las aplicaciones que tienen como destino .NET Framework 4.6 pero que quieren que los controles de WPF se representen con el algoritmo de diseño anterior pueden hacerlo mediante la adición de la línea siguiente a la sección <runtime> del archivo app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación

XML, XSLT

XmlWriter inicia una excepción en los pares suplentes no válidos

Detalles

Para las aplicaciones destinadas a .NET Framework 4.5.2 o versiones anteriores, el procedimiento de escribir un par suplente no válido usando el control de reserva de excepción no siempre produce una excepción. Para las aplicaciones destinadas a .NET Framework 4.6, si se intenta escribir un par suplente no válido se inicia una excepción System.ArgumentException.

Sugerencia

Si es necesario, esta interrupción se puede evitar seleccionando .NET Framework 4.5.2 o una versión anterior como destino. Como alternativa, se puede realizar el preprocesamiento de los pares suplentes no válidos en código XML válido antes de escribirlos.

NOMBRE	Valor
Ámbito	Borde
Versión	4.6
Tipo	Redestinación

API afectadas

• XmlWriter.WriteAttributeString(String, String)
• XmlWriter.WriteAttributeString(String, String, String)
• XmlWriter.WriteAttributeString(String, String, String, String)
• XmlWriter.WriteAttributeStringAsync(String, String, String, String)
• XmlWriter.WriteCData(String)
• XmlWriter.WriteCDataAsync(String)
• XmlWriter.WriteChars(Char[], Int32, Int32)
• XmlWriter.WriteCharsAsync(Char[], Int32, Int32)
• XmlWriter.WriteComment(String)
• XmlWriter.WriteCommentAsync(String)
• XmlWriter.WriteEntityRef(String)
• XmlWriter.WriteEntityRefAsync(String)
• XmlWriter.WriteRaw(Char[], Int32, Int32)
• XmlWriter.WriteProcessingInstruction(String, String)
• XmlWriter.WriteProcessingInstructionAsync(String, String)
• XmlWriter.WriteRaw(String)
• XmlWriter.WriteRawAsync(Char[], Int32, Int32)
• XmlWriter.WriteRawAsync(String)
• XmlWriter.WriteString(String)
• XmlWriter.WriteStringAsync(String)
• XmlWriter.WriteSurrogateCharEntity(Char, Char)
• XmlWriter.WriteSurrogateCharEntityAsync(Char, Char)
• XmlWriter.WriteValue(String)

La validación del esquema XSD ahora detecta correctamente las infracciones de restricciones únicas si se usan claves compuestas y una de las claves está vacía

Detalles

Las versiones de .NET Framework anteriores a la 4.6 presentaban un error que hacía que la validación de XSD no detectara restricciones únicas en claves compuestas si alguna de las claves estaba vacía. Este problema se corrigió en .NET Framework 4.6. De este modo, se conseguirá una mayor corrección en la validación, pero también podría hacer que cierto XML no valide lo que antes sí validaría.

Sugerencia

Si se necesita una validación de .NET Framework 4.0 menos estricta, se puede establecer la versión 4.5 (o anterior) de .NET Framework como destino de la aplicación de validación. Pero en la redestinación a .NET Framework 4.6, se debe realizar la revisión del código para asegurarse de que no se espere la validación de claves compuestas duplicadas (como se indica en la descripción de este problema).

NOMBRE	Valor
Ámbito	Borde
Versión	4.6
Tipo	Redestinación

.NET Framework 4.6.1

Principal

Cambio en el carácter separador de ruta de acceso de la propiedad FullName de los objetos ZipArchiveEntry

Detalles

Para las aplicaciones destinadas a .NET Framework 4.6.1 y versiones posteriores, el carácter separador de rutas de acceso ha cambiado de una barra diagonal inversa ("\") a una barra diagonal ("/") en la propiedad FullName de los objetos ZipArchiveEntry creados por sobrecargas del método CreateFromDirectory. El cambio trae la implementación de .NET en conformidad con la sección 4.4.17.1 de la Especificación de formato de archivo .ZIP y permite que los archivos ZIP se descompriman en sistemas distintos de Windows.
Al descomprimir un archivo ZIP creado por una aplicación que tiene como destino una versión anterior de .NET Framework en sistemas operativos que no son de Windows, como Macintosh, no se puede conservar la estructura de directorios. Por ejemplo, en Macintosh, crea un conjunto de archivos cuyo nombre de archivo concatena la ruta de acceso del directorio, junto con cualquier carácter de barra diagonal inversa ("\") y el nombre de archivo. Como resultado, no se conserva la estructura de directorios de archivos descomprimidos.

Sugerencia

El impacto de este cambio en los archivos .ZIP que se descomprimen en el sistema operativo Windows mediante las API del espacio de nombres System.IO de .NET Framework debe ser mínimo, ya que estas API pueden manejar sin problemas una barra diagonal ("/") o una barra diagonal inversa ("\") como carácter separador de la ruta de acceso.
Si no quiere este cambio, puede rechazarlo mediante la adición de un valor de configuración a la sección <runtime> del archivo de configuración de la aplicación. En el ejemplo siguiente se muestra la sección <runtime> y el conmutador de rechazo Switch.System.IO.Compression.ZipFile.UseBackslash:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

Además, las aplicaciones que tienen como destino versiones anteriores de .NET Framework pero que se ejecutan en .NET Framework 4.6.1 y versiones posteriores pueden participar en este comportamiento si se agrega una opción de configuración a la sección <runtime> del archivo de configuración de la aplicación. A continuación se muestra la sección <runtime> y el conmutador de inclusión Switch.System.IO.Compression.ZipFile.UseBackslash.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>

NOMBRE	Valor
Ámbito	Borde
Versión	4.6.1
Tipo	Redestinación

API afectadas

• ZipFile.CreateFromDirectory(String, String)
• ZipFile.CreateFromDirectory(String, String, CompressionLevel, Boolean)
• ZipFile.CreateFromDirectory(String, String, CompressionLevel, Boolean, Encoding)

Windows Communication Foundation (WCF)

Enlace de WCF con el modo de seguridad de TransportWithMessageCredential

Detalles

A partir de .NET Framework 4.6.1, el enlace WCF que usa el modo de seguridad de TransportWithMessageCredential se puede configurar para recibir mensajes con encabezados "para" sin firmar para las claves de seguridad asimétricas. En .NET Framework 4.6.1 se seguirán rechazando los encabezados "para" sin firmar de forma predeterminada. Solo se aceptarán si una aplicación incluye este modo de operación nuevo mediante el modificador de configuración Switch.System.ServiceModel.AllowUnsignedToHeader.

Sugerencia

Como es una característica opcional, no debería afectar al comportamiento de las aplicaciones existentes.
Para controlar si se usa el comportamiento nuevo o no, use la opción de configuración siguiente:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>

NOMBRE	Valor
Ámbito	Transparente
Versión	4.6.1
Tipo	Redestinación

API afectadas

• BasicHttpSecurityMode.TransportWithMessageCredential
• BasicHttpsSecurityMode.TransportWithMessageCredential
• SecurityMode.TransportWithMessageCredential
• WSFederationHttpSecurityMode.TransportWithMessageCredential

X509CertificateClaimSet.FindClaims considera todos los argumentos claimType

Detalles

En las aplicaciones destinadas a .NET Framework 4.6.1, si un conjunto de notificaciones X509 se inicializó desde un certificado con varias entradas DNS en su campo SAN, el método System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) trata de hacer coincidir el argumento claimType con todas las entradas DNS. En las aplicaciones destinadas a versiones anteriores de .NET Framework, el método System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) solo trata de hacer coincidir el argumento claimType con la última entrada DNS.

Sugerencia

Este cambio solo afecta a las aplicaciones que tengan como destino .NET Framework 4.6.1. Este cambio puede deshabilitarse, o habilitarse si se establece como destino una versión anterior a la 4.6.1, con el modificador de compatibilidad DisableMultipleDNSEntries.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6.1
Tipo	Redestinación

API afectadas

• X509CertificateClaimSet.FindClaims(String, String)

Windows Forms

Ya no se inicia Application.FilterMessage para las implementaciones reentrantes de IMessageFilter.PreFilterMessage

Detalles

Antes de .NET Framework 4.6.1, la llamada a FilterMessage(Message) con un PreFilterMessage(Message) que llamaba a System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) o System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (mientras también se llamaba a DoEvents()) iniciaría una excepción System.IndexOutOfRangeException.

A partir de las aplicaciones que tengan como destino .NET Framework 4.6.1, esta excepción ya no se inicia y es posible usar los filtros reentrantes como se indica anteriormente.

Sugerencia

Tenga en cuenta que FilterMessage(Message) ya no se iniciará para el comportamiento de PreFilterMessage(Message) reentrantes descrito anteriormente. Esto solo afecta a las aplicaciones destinadas a .NET Framework 4.6.1. Es posible desactivar este cambio en las aplicaciones destinadas a .NET Framework 4.6.1 (o activarlo en las que tengan como destino versiones anteriores de .NET Framework) mediante el modificador de compatibilidad DontSupportReentrantFilterMessage.

NOMBRE	Valor
Ámbito	Borde
Versión	4.6.1
Tipo	Redestinación

API afectadas

• Application.FilterMessage(Message)

Windows Presentation Foundation (WPF)

Las llamadas a System.Windows.Input.PenContext.Disable en sistemas táctiles pueden iniciar una excepción ArgumentException

Detalles

En algunas circunstancias, las llamadas al método interno System.Windows.Intput.PenContext.Disable en sistemas táctiles pueden iniciar una excepción T:System.ArgumentException no controlada debido a la reentrada.

Sugerencia

Este problema se ha corregido en .NET Framework 4.7. Para evitar la excepción, actualice a una versión de .NET Framework a partir de .NET Framework 4.7.

NOMBRE	Valor
Ámbito	Borde
Versión	4.6.1
Tipo	Redestinación

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath inicia una excepción NullReferenceException

Detalles

En .NET Framework 4.6.2, el entorno de ejecución inicia una excepción T:System.NullReferenceException al recuperar un valor P:System.Web.HttpRuntime.AppDomainAppPath que incluye caracteres NULL. En .NET Framework 4.6.1 y versiones anteriores, el entorno de ejecución inicia una excepción T:System.ArgumentNullException.

Sugerencia

Puede hacer lo siguiente para responder a este cambio:

• Controle T:System.NullReferenceException si la aplicación se ejecuta en .NET Framework 4.6.2.
• Actualice a .NET Framework 4.7, que restaura el comportamiento anterior e inicia una excepción T:System.ArgumentNullException.

NOMBRE	Valor
Ámbito	Borde
Versión	4.6.2
Tipo	Redestinación

API afectadas

• HttpRuntime.AppDomainAppPath

Core

El descifrador AesCryptoServiceProvider proporciona una transformación reutilizable

Detalles

A partir de las aplicaciones que tienen como destino .NET Framework 4.6.2, el descifrador AesCryptoServiceProvider ofrece una transformación reutilizable. Después de llamar a System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32), la transformación se reinicializa y se puede reutilizar. Para las aplicaciones que tienen como destino versiones anteriores de .NET Framework, intentar volver a usar el descifrador mediante una llamada a System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) después de llamar a System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) inicia una excepción CryptographicException o genera datos dañados.

Sugerencia

El impacto de este cambio debería ser mínimo, dado que es el comportamiento esperado. Las aplicaciones que dependen del comportamiento anterior pueden rechazar su uso si se agrega el ajuste de configuración siguiente a la sección <runtime> del archivo de configuración de la aplicación:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

Además, las aplicaciones que tienen como destino una versión anterior de .NET Framework pero que se ejecutan en una versión de .NET Framework a partir de la 4.6.2 pueden incluirse en este comportamiento si se agrega el ajuste de configuración siguiente a la sección <runtime> del archivo de configuración de la aplicación:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6.2
Tipo	Redestinación

API afectadas

• AesCryptoServiceProvider.CreateDecryptor()

Llamadas a los constructores de ClaimsIdentity

Detalles

A partir de .NET Framework 4.6.2, hay un cambio en el modo en que los constructores ClaimsIdentity con un parámetro System.Security.Principal.IIdentity establecen la propiedad System.Security.Claims.ClaimsIdentity.Actor. Si el argumento System.Security.Principal.IIdentity es un objeto ClaimsIdentity y la propiedad System.Security.Claims.ClaimsIdentity.Actor de ese objeto ClaimsIdentity no es null, la propiedad System.Security.Claims.ClaimsIdentity.Actor se conecta mediante el método Clone(). En .NET Framework 4.6.1 y versiones anteriores, la propiedad System.Security.Claims.ClaimsIdentity.Actor se adjuntaba como una referencia existente. Debido a este cambio, a partir de .NET Framework 4.6.2, la propiedad System.Security.Claims.ClaimsIdentity.Actor del nuevo objeto ClaimsIdentity no es igual que la propiedad System.Security.Claims.ClaimsIdentity.Actor del argumento System.Security.Principal.IIdentity del constructor. En .NET Framework 4.6.1 y versiones anteriores, es igual.

Sugerencia

Si no desea este comportamiento, puede restaurar el comportamiento anterior si establece el modificador Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity en el archivo de configuración de la aplicación en true. Para ello, es necesario agregar lo siguiente a la sección <runtime> del archivo web.config:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>

NOMBRE	Valor
Ámbito	Borde
Versión	4.6.2
Tipo	Redestinación

API afectadas

• ClaimsIdentity(IIdentity)
• ClaimsIdentity(IIdentity, IEnumerable<Claim>)
• ClaimsIdentity(IIdentity, IEnumerable<Claim>, String, String, String)

Cambios en la normalización de la ruta de acceso

Detalles

A partir de las aplicaciones que tienen como destino .NET Framework 4.6.2, ha cambiado la forma en que el entorno de ejecución normaliza las rutas de acceso. La normalización de una ruta de acceso implica la modificación de la cadena que identifica una ruta de acceso o un archivo para que se ajuste a una ruta de acceso válida en el sistema operativo de destino. La normalización implica normalmente:

• La canonicalización del componente y los separadores de directorios.
• La aplicación del directorio actual en una ruta de acceso relativa.
• La evaluación del directorio relativo (.) o el directorio principal (..) en una ruta de acceso.
• El recorte de caracteres especificados. A partir de las aplicaciones que tienen como destino .NET Framework 4.6.2, los cambios siguientes en la normalización de la ruta de acceso están habilitados de forma predeterminada:
  • El tiempo de ejecución se aplaza para la función GetFullPathName del sistema operativo con el objetivo de normalizar las rutas de acceso.
• La normalización ya no implica el recorte del final de los segmentos de directorio (como el espacio al final de un nombre de directorio).
• Compatibilidad de la sintaxis de la ruta de acceso del dispositivo con plena confianza ( incluido \\.\) y, para las API de E/S del archivo en mscorlib.dll, \\?\.
• El tiempo de ejecución o valida las rutas de acceso de la sintaxis del dispositivo.
• Es compatible el uso de la sintaxis del dispositivo para obtener acceso a los flujos de datos alternativos. Estos cambios mejoran el rendimiento a la vez que permiten a los métodos obtener acceso a las rutas de acceso a las que no se podía obtener acceso anteriormente. Las aplicaciones que tienen como destino .NET Framework 4.6.1 y versiones anteriores, pero que se ejecutan en .NET Framework 4.6.2 o posterior, no se ven afectadas por este cambio.

Sugerencia

Las aplicaciones que tienen como destino .NET Framework 4.6.2 o una versión posterior pueden rechazar este cambio y usar la normalización heredada si agregan lo siguiente a la sección <runtime> del archivo de configuración de la aplicación:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

Las aplicaciones que tienen como destino .NET Framework 4.6.1 o versiones anteriores, pero que se ejecutan en .NET Framework 4.6.2 o versiones posteriores, pueden habilitar los cambios en la normalización de rutas de acceso si se agrega la línea siguiente a la sección <runtime> del archivo .configuration de la aplicación:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6.2
Tipo	Redestinación

CurrentCulture y CurrentUICulture fluyen entre tareas

Detalles

A partir de la versión 4.6 de .NET Framework, System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture se almacenan en el System.Threading.ExecutionContext del subproceso, que fluye entre las operaciones asincrónicas. Esto significa que los cambios en System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture se verán reflejados en las tareas que después se ejecutan de forma asincrónica. Esto difiere del comportamiento de las versiones anteriores de .NET Framework (en las que se restablecían System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture en todas las tareas asincrónicas).

Sugerencia

Las aplicaciones afectadas por este cambio pueden solucionar el problema si se establece explícitamente el valor System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture deseado como la primera operación de una tarea asincrónica. Como alternativa, el comportamiento anterior (de que System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture no fluyan) se puede incluir si se establece el modificador de compatibilidad siguiente:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

WPF ha solucionado este problema en .NET Framework 4.6.2. También se ha corregido en .NET Framework 4.6, 4.6.1 a través de KB 3139549. Las aplicaciones destinadas a .NET Framework 4.6 o una versión posterior obtendrán automáticamente el comportamiento correcto en las aplicaciones de WPF: System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) se conservará entre las operaciones del distribuidor.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación

API afectadas

• CultureInfo.CurrentCulture
• Thread.CurrentCulture
• CultureInfo.CurrentUICulture
• Thread.CurrentUICulture

Los nombres de eventos de ETW no pueden diferir solamente en un sufijo "Start" o "Stop".

Detalles

En .NET Framework 4.6 y 4.6.1, el entorno de ejecución inicia una excepción ArgumentException cuando dos nombres de evento de Seguimiento de eventos para Windows (ETW) solamente difieren en un sufijo "Start" o "Stop" (como cuando un evento se denomina LogUser y otro LogUserStart). En este caso, el entorno en tiempo de ejecución no puede crear el origen de eventos, que no puede emitir ningún registro.

Sugerencia

Para evitar la excepción, asegúrese de que no haya dos nombres de evento que solo difieran en un sufijo "Start" o "Stop". Este requisito se ha eliminado a partir de .NET Framework 4.6.2; el entorno de ejecución puede eliminar la ambigüedad de los nombres de evento que solo difieren en el sufijo "Start" y "Stop".

NOMBRE	Valor
Ámbito	Borde
Versión	4.6
Tipo	Redestinación

Compatibilidad con rutas de acceso con formato largo

Detalles

A partir de las aplicaciones destinadas a .NET Framework 4.6.2, se admiten las rutas de acceso largas (de hasta 32 000 caracteres) y se ha quitado la limitación de 260 caracteres (o MAX_PATH) para las longitudes de ruta de acceso. Para las aplicaciones que se vuelven a compilar para .NET Framework 4.6.2, las rutas de acceso de código que antes iniciaban una excepción System.IO.PathTooLongException porque una ruta de acceso superaba los 260 caracteres ahora iniciarán una excepción System.IO.PathTooLongException solo en las condiciones siguientes:

• La longitud de la ruta de acceso es mayor que MaxValue (32 767) caracteres.
• El sistema operativo devuelve COR_E_PATHTOOLONG o su equivalente. Para las aplicaciones que tienen como destino .NET Framework 4.6.1 y versiones anteriores, el entorno de ejecución inicia automáticamente una excepción System.IO.PathTooLongException cada vez que una ruta de acceso supera los 260 caracteres.

Sugerencia

Para las aplicaciones que tienen como destino .NET Framework 4.6.2, se puede rechazar la compatibilidad con rutas de acceso largas si no es adecuada si se agrega lo siguiente a la sección <runtime> del archivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

Para las aplicaciones que tienen como destino versiones anteriores de .NET Framework, pero que se ejecutan en .NET Framework 4.6.2 o versiones posteriores, se puede incluir la compatibilidad con rutas de acceso largas si se agrega lo siguiente a la sección <runtime> del archivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6.2
Tipo	Redestinación

Las comprobaciones de dos puntos de ruta de acceso son más estrictas

Detalles

En .NET Framework 4.6.2, se realizaron varios cambios para admitir las rutas de acceso que anteriormente no eran compatibles (tanto en longitud como en formato). Se ha aumentado la corrección de las comprobaciones de sintaxis adecuada del separador de unidad (dos puntos), que tenía el efecto secundario de bloquear algunas rutas de acceso de URI en algunas API de ruta concretas en las que antes se toleraban.

Sugerencia

Si se pasa un URI a las API afectadas, modifique la cadena para que primero sea una ruta de acceso válida.

• Quite manualmente el esquema de las direcciones URL (por ejemplo, quite file:// de las URL).

• Pase el URI a la clase Uri y use LocalPath.

Como alternativa, puede rechazar la nueva normalización de rutas de acceso si establece el conmutador Switch.System.IO.UseLegacyPathHandling de AppContext en true.

Nombre	Valor
Ámbito	Borde
Versión	4.6.2
Tipo	Redestinación

API afectadas

• Path.GetDirectoryName(String)
• Path.GetPathRoot(String)

Seguridad

RSACng ahora carga correctamente las claves RSA de tamaño de clave no estándar

Detalles

En las versiones de .NET Framework anteriores a la 4.6.2, los clientes con tamaños de clave no estándar para los certificados RSA no podrán tener acceso a esas claves a través de los métodos de extensión System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) y System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2). Se genera una System.Security.Cryptography.CryptographicException con el mensaje "The requested key size is not supported" ("No se admite el tamaño de clave solicitado"). Este problema se ha solucionado en .NET Framework 4.6.2. De forma similar, ImportParameters(RSAParameters) y ImportParameters(RSAParameters) ahora funcionan con tamaños de clave no estándar sin iniciar una excepción System.Security.Cryptography.CryptographicException.

Sugerencia

Si no hay ninguna lógica de control de excepciones que se base en el comportamiento anterior en el que se inicia una excepción System.Security.Cryptography.CryptographicException cuando se usan tamaños de clave no estándar, considere la posibilidad de quitar la lógica.

NOMBRE	Valor
Ámbito	Borde
Versión	4.6.2
Tipo	Redestinación

API afectadas

• RSA.ImportParameters(RSAParameters)
• RSACng.ImportParameters(RSAParameters)
• RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2)
• RSACertificateExtensions.GetRSAPublicKey(X509Certificate2)

SignedXml.GetPublicKey devuelve RSACng en net462 (o Lightup) sin cambios de redestinación

Detalles

A partir de .NET Framework 4.6.2, se ha cambiado (sin peculiaridades) el tipo concreto del objeto devuelto por el método SignedXml.GetPublicKey de una implementación de CryptoServiceProvider a una implementación de Cng. Esto se debe a que la implementación ha pasado de usar certificate.PublicKey.Key a usar la certificate.GetAnyPublicKey interna que reenvía a RSACertificateExtensions.GetRSAPublicKey.

Sugerencia

A partir de las aplicaciones que se ejecutan en .NET Framework 4.7.1, se puede usar la implementación de CryptoServiceProvider que se usa de forma predeterminada en .NET Framework 4.6.1 y versiones anteriores mediante la adición del conmutador siguiente a la sección runtime del archivo de configuración de la aplicación:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />

NOMBRE	Valor
Ámbito	Borde
Versión	4.6.2
Tipo	Redestinación

API afectadas

• SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm)

Windows Communication Foundation (WCF)

El uso de servicios reentrantes puede producir un interbloqueo

Detalles

Se puede producir un interbloqueo en un servicio reentrante, lo que restringe las instancias del servicio a un subproceso de ejecución a la vez. Los servicios propensos a sufrir este problema tendrán el atributo ServiceBehaviorAttribute siguiente en su código:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Sugerencia

Para solucionar este problema, puede seguir estos pasos:

• Establezca el modo de simultaneidad del servicio en ConcurrencyMode.Single o ConcurrencyMode.Multiple. Por ejemplo:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

• Instale la actualización más reciente de .NET Framework 4.6.2 o actualice a una versión posterior de .NET Framework. Esto deshabilita el flujo de ExecutionContext en OperationContext.Current. Este comportamiento se puede configurar; equivale a agregar la configuración de aplicación siguiente al archivo de configuración:

<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

El valor de Switch.System.ServiceModel.DisableOperationContextAsyncFlow nunca se debe establecer en false para los servicios reentrantes.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6.2
Tipo	Redestinación

API afectadas

• System.ServiceModel.ServiceBehaviorAttribute
• ConcurrencyMode.Reentrant

Es posible que OperationContext.Current devuelva NULL cuando se llama en una cláusula using.

Detalles

Es posible que OperationContext.Current devuelva null y que se inicie una excepción NullReferenceException si todas las condiciones siguientes son verdaderas:

• Se recupera el valor de la propiedad OperationContext.Current en un método que devuelve una Task o Task<TResult>.
• Se crea una instancia del objeto OperationContextScope en una cláusula using.
• Se recupera el valor de la propiedad OperationContext.Current dentro de using statement. Por ejemplo:

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

Sugerencia

Para solucionar este problema, puede seguir estos pasos:

• Modifique el código como se indica aquí para crear una instancia de un nuevo objeto Current que no sea null:

  OperationContext ocx = OperationContext.Current;
  using (new OperationContextScope(OperationContext.Current))
  {
      OperationContext.Current = new OperationContext(ocx.Channel);
  
      // ...
  }
  

• Instale la actualización más reciente de .NET Framework 4.6.2 o actualice a una versión posterior de .NET Framework. Esto deshabilita el flujo del ExecutionContext en OperationContext.Current y restaura el comportamiento de las aplicaciones de WCF de .NET Framework 4.6.1 y versiones anteriores. Este comportamiento se puede configurar; equivale a agregar la configuración de aplicación siguiente al archivo de configuración:

  <appSettings>
    <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
  </appSettings>
  

  Si no quiere este cambio y la aplicación depende del flujo del contexto de ejecución entre los contextos de operación, puede habilitar su flujo de esta manera:

  <appSettings>
    <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
  </appSettings>
  

NOMBRE	Valor
Ámbito	Borde
Versión	4.6.2
Tipo	Redestinación

API afectadas

• OperationContext.Current

La seguridad de transporte de WCF admite los certificados almacenados con CNG

Detalles

A partir de las aplicaciones destinadas a .NET Framework 4.6.2, la seguridad de transporte de WCF es compatible con los certificados almacenados mediante la biblioteca de criptografía (CNG) de Windows. Esta compatibilidad está limitada a los certificados con una clave pública que tengan un exponente con una longitud no superior a 32 bits. Cuando una aplicación está destinada a .NET Framework 4.6.2, esta característica está activada de manera predeterminada. En versiones anteriores de .NET Framework, el intento de usar certificados X509 con un proveedor de almacenamiento de claves CSG inicia una excepción.

Sugerencia

Las aplicaciones que tienen como destino .NET Framework 4.6.1 y versiones anteriores, pero que se ejecutan en .NET Framework 4.6.2, pueden habilitar la compatibilidad para los certificados de CNG si agregan la línea siguiente a la sección <runtime> del archivo app.config o web.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

Esto también puede realizarse mediante programación con el siguiente código:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Tenga en cuenta que, debido a este cambio, cualquier código erróneo de control de excepciones que dependa del intento de iniciar una comunicación segura con un certificado CNG dejará de ejecutarse.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6.2
Tipo	Redestinación

Windows Forms

Implementación incorrecta de MemberDescriptor.Equals

Detalles

En la implementación original del método MemberDescriptor.Equals se comparan dos propiedades de cadena diferentes de los objetos comparados: el nombre de la categoría y la cadena de descripción. La solución consiste en comparar la propiedad Category del primer objeto con la propiedad Category del segundo y la propiedad Description del primero con la propiedad Description del segundo.

Sugerencia

Si la aplicación depende de que MemberDescriptor.Equals a veces devuelva false cuando los descriptores son equivalentes, y el destino es la versión 4.6.2 de .NET Framework o una versión posterior, tiene varias opciones:

• Realizar cambios de código para comparar los campos Category y Description de forma manual además de llamar al método MemberDescriptor.Equals.
• Excluir este cambio mediante la adición del valor siguiente al archivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Si la aplicación está destinada a .NET Framework 4.6.1 o una versión anterior y se ejecuta en .NET Framework 4.6.2 o una versión anterior, y quiere deshabilitar este cambio, puede establecer el modificador de compatibilidad en false mediante la adición del valor siguiente al archivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>

NOMBRE	Valor
Ámbito	Borde
Versión	4.6.2
Tipo	Redestinación

API afectadas

• MemberDescriptor.Equals(Object)

Windows Presentation Foundation (WPF)

CurrentCulture no se conserva entre operaciones del distribuidor de WPF

Detalles

A partir de .NET Framework 4.6, los cambios efectuados en System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture dentro de un System.Windows.Threading.Dispatcher se perderán al final de la operación de ese distribuidor. De igual forma, es posible que los cambios en System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture realizados fuera de una operación de distribuidor no surtan efecto cuando que se ejecuta esa operación. En términos prácticos, esto significa que es posible que los cambios en System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture no fluyan entre las devoluciones de llamada de la interfaz de usuario de WPF y otro código de una aplicación de WPF. Esto se debe a un cambio en System.Threading.ExecutionContext que hace que System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture se almacenen en el contexto de ejecución a partir de las aplicaciones destinadas a .NET Framework 4.6. Las operaciones de distribuidor de WPF almacenan el contexto de ejecución usado para iniciar la operación y restaurar el contexto anterior cuando la operación se complete. Dado que System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture ahora forman parte de este contexto, los cambios efectuados en ellas como parte de una operación de distribuidor no persisten fuera de la operación.

Sugerencia

Las aplicaciones afectadas por este cambio pueden solucionarlo si se almacenan los elementos System.Globalization.CultureInfo.CurrentCulture o System.Globalization.CultureInfo.CurrentUICulture deseados en un campo y se protegen todos los cuerpos de las operaciones de distribuidor (incluidos los controladores de devolución de llamadas de eventos de interfaz de usuario) en los que se establezcan los elementos System.Globalization.CultureInfo.CurrentCulture y System.Globalization.CultureInfo.CurrentUICulture correctos. Además, como el cambio de ExecutionContext subyacente a este cambio de WPF solo afecta a las aplicaciones destinadas a .NET Framework 4.6 o una versión más reciente, es posible evitar esta interrupción estableciendo como destino .NET Framework 4.5.2. Las aplicaciones destinadas a .NET Framework 4.6 o una versión posterior también pueden solucionarlo si se establece el modificador de compatibilidad siguiente:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

WPF ha solucionado este problema en .NET Framework 4.6.2. También se ha corregido en .NET Framework 4.6, 4.6.1 a través de KB 3139549. Las aplicaciones destinadas a .NET Framework 4.6 o una versión posterior obtendrán automáticamente el comportamiento correcto en las aplicaciones de WPF: System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) se conservará entre las operaciones del distribuidor.

NOMBRE	Valor
Ámbito	Secundaria
Versión	4.6
Tipo	Redestinación