Compartir a través de


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

En este artículo se enumeran los problemas de compatibilidad de aplicaciones que se introdujeron en .NET Framework 4.7, 4.7.1 y 4.7.2.

.NET Framework 4.7

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

Límite de solicitudes simultáneas por sesión

Detalles

En .NET Framework 4.6.2 y en versiones anteriores, ASP.NET ejecuta las solicitudes con el mismo Sessionid de manera secuencial y siempre emite el Sessionid mediante cookies de forma predeterminada. Si una página tarda mucho tiempo en responder, reducirá considerablemente el rendimiento del servidor simplemente presionando F5 en el explorador. En la corrección, se ha agregado un contador para realizar el seguimiento de las solicitudes en cola y finalizar las solicitudes cuando superen un límite especificado. El valor predeterminado es 50. Si se alcanza el límite, se registrará una advertencia en el registro de eventos y se podrá grabar una respuesta HTTP 500 en el registro de IIS.

Sugerencia

Para restaurar el comportamiento anterior, puede agregar la siguiente configuración al archivo web.config para rechazar el nuevo comportamiento.

<appSettings>
    <add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
NOMBRE Valor
Ámbito Borde
Versión 4.7
Tipo Redestinación

Redes

El valor predeterminado de ServicePointManager.SecurityProtocol es SecurityProtocolType.System.Default

Detalles

A partir de las aplicaciones que tienen como destino .NET Framework 4.7, el valor predeterminado de la propiedad ServicePointManager.SecurityProtocol es SecurityProtocolType.SystemDefault. Este cambio permite que las API para redes de .NET Framework basadas en SslStream (como FTP, HTTPS y SMTP) hereden los protocolos de seguridad predeterminados del sistema operativo en lugar de usar valores codificados de forma rígida definidos por .NET Framework. El valor predeterminado varía según el sistema operativo y la configuración personalizada que realice el administrador del sistema. Para obtener información sobre el protocolo SChannel predeterminado en cada versión del sistema operativo Windows, vea Protocols in TLS/SSL (Schannel SSP) (Protocolos en TLS/SSL [Schannel SSP]).

Para las aplicaciones que tienen como destino una versión anterior de .NET Framework, el valor predeterminado de la propiedad ServicePointManager.SecurityProtocol depende de la versión de .NET Framework de destino. Vea la sección Redes del artículo Cambios de redestinación para la migración desde .NET Framework 4.5.2 a 4.6 para obtener más información.

Sugerencia

Este cambio solo afecta a las aplicaciones que tienen como destino .NET Framework 4.7 o versiones posteriores. Si prefiere usar un protocolo definido en lugar de basarse en el valor predeterminado del sistema, puede establecer de forma explícita el valor de la propiedad ServicePointManager.SecurityProtocol. 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.Net.DontEnableSystemDefaultTlsVersions:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
NOMBRE Valor
Ámbito Secundaria
Versión 4.7
Tipo Redestinación

API afectadas

SslStream es compatible con las alertas de TLS

Detalles

Después de un error en el protocolo de enlace TLS, la primera operación de lectura y escritura de E/S iniciará una excepción System.IO.IOException con una excepción System.ComponentModel.Win32Exception interna. El código System.ComponentModel.Win32Exception.NativeErrorCode de System.ComponentModel.Win32Exception puede asignarse a la alerta de TLS de la parte remota con los códigos de error de Schannel para las alertas de TLS y SSL.Para obtener más información, vea RFC 2246: alertas de error, sección 7.2.2.
El comportamiento de .NET Framework 4.6.2 y versiones anteriores es que el canal de transporte (normalmente la conexión TCP) agotará el tiempo de espera durante la operación de escritura o lectura después de un error en el protocolo de enlace en la otra parte e inmediatamente después de rechazar la conexión.

Sugerencia

Las aplicaciones que llaman a las API de E/S de red como Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) deben controlar IOException o System.TimeoutException.
La característica de alertas de TLS está habilitada de forma predeterminada a partir de .NET Framework 4.7. Las aplicaciones destinadas a versiones de .NET Framework de la 4.0 a la 4.6.2 que se ejecuten en un sistema con .NET Framework 4.7 o una versión posterior tendrán la función deshabilitada para mantener la compatibilidad.
La API de configuración siguiente está disponible para habilitar o deshabilitar la característica para las aplicaciones de .NET Framework 4.6 y versiones posteriores que se ejecuten en .NET Framework 4.7 o versiones posteriores.

  • Mediante programación: Debe ser lo primero que haga la aplicación dado que ServicePointManager solo se inicializará una vez:

    AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);
    
    // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
    AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
    
  • AppConfig:

    <runtime>
      <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
      <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
    </runtime>
    
  • Clave del Registro (global de equipo): Establezca el valor en false para habilitar la característica en .NET Framework 4.6 - 4.6.2.

    Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
    - Type: String
    - Value: "true"
    
Nombre Valor
Ámbito Borde
Versión 4.7
Tipo Redestinación

API afectadas

Seguridad

CspParameters.ParentWindowHandle espera ahora el valor HWND

Detalles

El valor ParentWindowHandle, introducido en .NET Framework 2.0, permite que una aplicación registre un valor de identificador de ventana principal, de modo que cualquier interfaz de usuario necesaria para tener acceso a la clave (por ejemplo, una solicitud del PIN o un cuadro de diálogo de consentimiento) se abra como elemento secundario modal de la ventana especificada. A partir de las aplicaciones destinadas a .NET Framework 4.7, una aplicación de Windows Forms puede establecer la propiedad ParentWindowHandle con código similar al siguiente:

cspParameters.ParentWindowHandle = form.Handle;

En versiones anteriores de .NET Framework, se esperaba que el valor fuera un System.IntPtr que representara una ubicación en memoria donde se encontraba el valor HWND. Establecer la propiedad en form.Handle no tenía ningún efecto en Windows 7 ni versiones anteriores, pero en Windows 8 y versiones posteriores, da como resultado "System.Security.Cryptography.CryptographicException: El parámetro es incorrecto".

Sugerencia

Para las aplicaciones destinadas a .NET Framework 4.7 o versiones posteriores que quieran registrar una relación de ventana principal, se recomienda usar la forma simplificada:

cspParameters.ParentWindowHandle = form.Handle;

Los usuarios que hayan identificado que el valor correcto para pasar era la dirección de una ubicación de memoria que contenía el valor form.Handle, pueden rechazar este cambio de comportamiento si establecen el modificador de AppContext Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle en true:

  • Configurando mediante programación los modificadores de compatibilidad en AppContext, como se explica aquí.
  • Agregando la siguiente línea a la sección <runtime> del archivo app.config:
<runtime>
 <AppContextSwitchOverrides value="Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle=true"/>
</runtime>

En cambio, los usuarios que quieran incluir el comportamiento nuevo en el entorno de ejecución de .NET Framework 4.7 cuando la aplicación se carga bajo versiones anteriores de .NET Framework, pueden establecer el modificador de AppContext en false.

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

API afectadas

SslStream es compatible con las alertas de TLS

Detalles

Después de un error en el protocolo de enlace TLS, la primera operación de lectura y escritura de E/S iniciará una excepción System.IO.IOException con una excepción System.ComponentModel.Win32Exception interna. El código System.ComponentModel.Win32Exception.NativeErrorCode de System.ComponentModel.Win32Exception puede asignarse a la alerta de TLS de la parte remota con los códigos de error de Schannel para las alertas de TLS y SSL.Para obtener más información, vea RFC 2246: alertas de error, sección 7.2.2.
El comportamiento de .NET Framework 4.6.2 y versiones anteriores es que el canal de transporte (normalmente la conexión TCP) agotará el tiempo de espera durante la operación de escritura o lectura después de un error en el protocolo de enlace en la otra parte e inmediatamente después de rechazar la conexión.

Sugerencia

Las aplicaciones que llaman a las API de E/S de red como Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) deben controlar IOException o System.TimeoutException.
La característica de alertas de TLS está habilitada de forma predeterminada a partir de .NET Framework 4.7. Las aplicaciones destinadas a versiones de .NET Framework de la 4.0 a la 4.6.2 que se ejecuten en un sistema con .NET Framework 4.7 o una versión posterior tendrán la función deshabilitada para mantener la compatibilidad.
La API de configuración siguiente está disponible para habilitar o deshabilitar la característica para las aplicaciones de .NET Framework 4.6 y versiones posteriores que se ejecuten en .NET Framework 4.7 o versiones posteriores.

  • Mediante programación: Debe ser lo primero que haga la aplicación dado que ServicePointManager solo se inicializará una vez:

    AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);
    
    // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
    AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
    
  • AppConfig:

    <runtime>
      <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
      <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
    </runtime>
    
  • Clave del Registro (global de equipo): Establezca el valor en false para habilitar la característica en .NET Framework 4.6 - 4.6.2.

    Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
    - Type: String
    - Value: "true"
    
Nombre Valor
Ámbito Borde
Versión 4.7
Tipo Redestinación

API afectadas

Windows Communication Foundation (WCF)

La serialización de los caracteres de control con DataContractJsonSerializer ahora es compatible con ECMAScript V6 y V8

Detalles

En .NET Framework 4.6.2 y versiones anteriores, System.Runtime.Serialization.Json.DataContractJsonSerializer no serializaba algunos caracteres de control especiales, como \b, \f y \t, de una forma que fuera compatible con los estándares ECMAScript V6 y V8. A partir de .NET Framework 4.7, la serialización de estos caracteres de control es compatible con ECMAScript V6 y V8.

Sugerencia

Esta característica está habilitada de forma predeterminada para las aplicaciones destinadas a .NET Framework 4.7. Si no desea este compartimiento, puede rechazar esta característica agregando la siguiente línea a la sección <runtime> del archivo app.config o web.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>
NOMBRE Valor
Ámbito Borde
Versión 4.7
Tipo Redestinación

API afectadas

La seguridad de los mensajes de WCF ahora puede usar TLS1.1 y TLS1.2

Detalles

A partir de .NET Framework 4.7, los clientes pueden configurar TLS1.1 o TLS1.2 en la seguridad de los mensajes de WCF además de SSL3.0 y TLS1.0 a través de ajustes de configuración de la aplicación.

Sugerencia

En .NET Framework 4.7, la compatibilidad con TLS1.1 y TLS1.2 en la seguridad de los mensajes de WCF está deshabilitada de forma predeterminada. Se puede habilitar si se agrega la línea siguiente a la sección <runtime> del archivo app.config o web.config:

<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
NOMBRE Valor
Ámbito Borde
Versión 4.7
Tipo Redestinación

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

Excepción NullReferenceException en el código de control de excepciones de ImageSourceConverter.ConvertFrom

Detalles

Un error en el código de control de excepciones ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) ha hecho que se produjese una excepción System.NullReferenceException incorrecta en lugar de la excepción prevista (System.IO.DirectoryNotFoundException o System.IO.FileNotFoundException). Este cambio corrige el error para que el método produzca la excepción correcta.

De forma predeterminada, todas las aplicaciones destinadas a .NET Framework 4.6.2 y versiones anteriores continuarán iniciando la excepción System.NullReferenceException por motivos de compatibilidad. Los desarrolladores que seleccionen como destino .NET Framework 4.7 y versiones posteriores debería ver las excepciones correctas.

Sugerencia

Los desarrolladores que quieran seguir obteniendo una excepción System.NullReferenceException cuando el destino sea .NET Framework 4.7 o versiones posteriores, pueden agregar o combinar lo siguiente en el archivo App.config de la aplicación:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>
NOMBRE Valor
Ámbito Borde
Versión 4.7
Tipo Redestinación

API afectadas

Asignación de espacio del elemento Grid de WPF a las columnas de asterisco

Detalles

A partir de .NET Framework 4.7, WPF reemplaza el algoritmo que Grid usa para asignar espacio a las *-columnas. Esto cambiará el ancho real que se asigna a las columnas * en una serie de casos:

  • Cuando una o más *-columnas también tienen un ancho mínimo o máximo que invalida la asignación proporcional para esa columna. (El ancho mínimo puede derivar de una declaración MinWidth explícita o de un mínimo implícito obtenido del contenido de la columna. El ancho máximo solo se puede definir explícitamente a partir de una declaración MaxWidth).
  • Cuando una o más columnas * declaran un peso de * extremadamente grande, superior a 10^298.
  • Cuando los pesos de * son suficientemente distintos como para detectar una inestabilidad de punto flotante (desbordamiento, subdesbordamiento y pérdida de precisión).
  • Cuando se habilita el redondeo del diseño, y el punto por pulgada de visualización efectivo es suficientemente alto. En los primeros dos casos, los anchos producidos por el nuevo algoritmo pueden ser significativamente distintos de los producidos por el algoritmo antiguo; en el último caso, la diferencia será como máximo de uno o dos píxeles.

El nuevo algoritmo corrige varios errores presentes en el algoritmo antiguo:

  • La asignación total a columnas puede superar el ancho de la cuadrícula. Esto puede ocurrir cuando se asigna espacio a una columna cuya parte proporcional es inferior a su tamaño mínimo. El algoritmo asigna el tamaño mínimo, lo que disminuye el espacio disponible para otras columnas. Si no hay ninguna columna * para asignar, la asignación total será demasiado grande.

  • La asignación total puede no alcanzar el ancho de la cuadrícula. Este es el doble problema que presenta el n.º 1, que surge cuando se asigna a una columna cuya parte proporcional es superior a su tamaño máximo, sin columnas * para ocupar el margen de demora.

  • Dos columnas * pueden recibir ubicaciones no proporcionales a sus pesos de *. Esta es una versión más ligera de n.º 1/n.º 2, que surge cuando se asigna a las columnas * A, B y C (en ese orden), donde la parte proporcional de B infringe la limitación mínima (o máxima). Como ocurría anteriormente, esto cambia el espacio disponible en la columna C, que obtiene menos (o más) asignación proporcional respecto a A.

  • Las columnas con pesos extremadamente grandes (> 10^298) se tratan como si tuvieran el peso 10^298. Las diferencias proporcionales entre ellas (y entre columnas con pesos ligeramente más reducidos) no se han respetado.

  • Las columnas con pesos infinitos no se han administrado correctamente. (De hecho, no puede establecer un peso en infinito, pero esta es una restricción artificial. El código de ubicación estaba intentando administrarlo, pero de forma incorrecta).

  • Algunos problemas leves al evitar el desbordamiento, el subdesbordamiento, la pérdida de precisión y problemas de punto flotante similares.

  • Los ajustes del redondeo del diseño son incorrectos en los puntos por pulgada suficientemente elevados. El nuevo algoritmo genera resultados que cumplen los siguientes criterios:

    • El ancho real asignado a una columna * nunca es inferior al ancho mínimo ni superior al ancho máximo.
    • A cada *-columna a la que no se le asigne su ancho mínimo o máximo se le asigna un ancho proporcional a su *-peso. Para ser precisos, si dos columnas se declaran con un ancho x* e y*, respectivamente, y si ninguna de ellas recibe su ancho mínimo o máximo, los anchos reales v y w asignados a las columnas tienen la misma proporción: v / w == x / y.
    • El ancho total asignado a las columnas *- "proporcionales" es igual al espacio disponible después de la asignación a las columnas restringidas (columnas fijas, automáticas y *- que se les asigna su ancho mínimo o máximo). Debe ser cero, por ejemplo si la suma de los anchos mínimos supera el ancho disponible de la cuadrícula.
    • Todas estas instrucciones tienen que interpretarse en relación con el diseño "ideal". Cuando se aplica el redondeo del diseño, los anchos reales pueden diferir de los ideales como máximo un píxel.

Nota:

Toda la información que se indica sobre las columnas y los anchos en este artículo se aplica también a las filas y las alturas.

Sugerencia

De forma predeterminada, las aplicaciones que tienen como destino versiones de .NET Framework a partir de .NET Framework 4.7 verán el algoritmo nuevo, mientras que las aplicaciones que tienen como destino .NET Framework 4.6.2 o versiones anteriores verán el algoritmo antiguo.

Para invalidar el valor predeterminado, utilice el siguiente ajuste de configuración:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

El valor true selecciona el algoritmo antiguo y el valor false el nuevo.

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

Pila táctil basada en punteros de WPF

Detalles

Este cambio agrega la posibilidad de habilitar una pila táctil o de lápiz de WPF opcional basada en WM_POINTER. Los desarrolladores que no lo habiliten explícitamente no deberían ver ningún cambio en el comportamiento del lápiz o la entrada táctil de WPF. Problemas conocidos actuales con la pila táctil o de lápiz opcional basada en WM_POINTER:

  • No se admiten las entradas manuscritas en tiempo real.
  • Aunque los complementos de lápiz y entrada manuscrita seguirán funcionando, se procesarán en el subproceso de la interfaz de usuario, lo que puede provocar un rendimiento deficiente.
  • El comportamiento cambia debido a las modificaciones en la promoción de los eventos de lápiz o de entrada táctil a los eventos de mouse.
  • Es posible que la manipulación se comporte de otra forma.
  • Arrastrar y colocar no mostrará la información adecuada para la entrada táctil.
  • Esto no afecta a la entrada de lápiz.
  • Arrastrar y colocar ya no se puede iniciar en los eventos de lápiz o entrada táctil.
  • Esto puede hacer que la aplicación deje de responder hasta que se detecte la entrada del mouse.
  • En su lugar, los desarrolladores deben iniciar Arrastrar y colocar en los eventos del mouse.

Sugerencia

Los desarrolladores que quieran habilitar esta pila pueden agregar o combinar lo siguiente en el archivo App.config de la aplicación:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.EnablePointerSupport=true"/>
</runtime>
</configuration>

Si se elimina esto o el valor se establece en false, esta pila opcional se desactivará. Tenga en cuenta que esta pila solo está disponible en Windows 10 Creators Update y versiones posteriores.

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

Windows Workflow Foundation (WF)

Las sumas de comprobación de flujo de trabajo han cambiado de MD5 a SHA1

Detalles

Para admitir la depuración con Visual Studio, el tiempo de ejecución de flujo de trabajo genera una suma de comprobación para una instancia de flujo de trabajo mediante un algoritmo de hash. En .NET Framework 4.6.2 y versiones anteriores, el hash de suma de comprobación de flujo de trabajo usaba el algoritmo MD5, que causaba problemas en sistemas compatibles con FIPS. A partir de .NET Framework 4.7, el algoritmo es SHA1. Si se han conservado estas sumas de comprobación en el código, serán incompatibles.

Sugerencia

Si el código no puede cargar las instancias de flujo de trabajo debido a un error de suma de comprobación, pruebe a establecer en true el modificador AppContext "Switch.System.Activities.UseMD5ForWFDebugger". En el código:

System.AppContext.SetSwitch("Switch.System.Activities.UseMD5ForWFDebugger", true);

O bien, en la configuración:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
  </runtime>
</configuration>
NOMBRE Valor
Ámbito Secundaria
Versión 4.7
Tipo Redestinación

.NET Framework 4.7.1

ASP.NET

Mejoras de accesibilidad de ASP.NET en .NET Framework 4.7.1

Detalles

A partir de .NET Framework 4.7.1, ASP.NET ha mejorado el funcionamiento de los controles web de ASP.NET con la tecnología de accesibilidad en Visual Studio para una mejor compatibilidad con los clientes de ASP.NET. Entre otros, se incluyen los cambios siguientes:

  • Cambios para implementar patrones de accesibilidad de interfaz de usuario que faltan en los controles, como el cuadro de diálogo Agregar campo en el Asistente para vistas de detalles o el cuadro de diálogo Configurar ListView del Asistente de ListView.
  • Cambios para mejorar la presentación en el modo Contraste alto, como el Editor de campos del elemento de paginación de datos.
  • Cambios para mejorar las experiencias de navegación del teclado para los controles, como el cuadro de diálogo Campos del Asistente para editar campos del elemento de paginación del control DataPager, el cuadro de diálogo Configurar ObjectContext o el cuadro de diálogo Configurar selección de datos del Asistente para configurar origen de datos.

Sugerencia

Cómo participar o no en estos cambios Para que el diseñador de Visual Studio se beneficie de estos cambios, se debe ejecutar en .NET Framework 4.7.1 o una versión posterior. La aplicación web se puede beneficiar de estos cambios de cualquiera de las maneras siguientes:

  • Instalar Visual Studio 2017 15.3 o una versión posterior, que es compatible con las nuevas características de accesibilidad con el modificador siguiente de AppContext de forma predeterminada.
  • No participar en los comportamientos de accesibilidad heredados agregando el modificador de AppContext Switch.UseLegacyAccessibilityFeatures a la sección <runtime> del archivo devenv.exe.config y estableciéndolo en false, como se muestra en el ejemplo siguiente.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
...
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false'  -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
...
</runtime>
</configuration>

En las aplicaciones destinadas a .NET Framework 4.7.1 o una versión posterior, y en las que se quiere conservar el comportamiento de accesibilidad heredado, se puede participar en el uso de las características de accesibilidad heredadas si se establece explícitamente este modificador de AppContext en true.

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

Core

Excepciones de subprocesos en segundo plano SerialPort

Detalles

Los subprocesos en segundo plano creados con secuencias SerialPort ya no finalizan el proceso cuando se inician excepciones del sistema operativo.
En las aplicaciones destinadas a .NET Framework 4.7 y versiones anteriores, un proceso se termina cuando se inicia una excepción del sistema operativo en un subproceso en segundo plano creado con una secuencia SerialPort.
En las aplicaciones destinadas a .NET Framework 4.7.1 o una versión posterior, los subprocesos en segundo plano esperan eventos del sistema operativo relacionados con el puerto serie activo y pueden dejar de funcionar en algunos casos, como la eliminación repentina del puerto serie.

Sugerencia

Para las aplicaciones que tienen como destino .NET Framework 4.7.1, se puede rechazar el control de excepciones si no es adecuado si se agrega lo siguiente a la sección <runtime> del archivo app.config:

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

Para las aplicaciones que tienen como destino versiones anteriores de .NET Framework, pero que se ejecutan en .NET Framework 4.7.1 o versiones posteriores, se puede incluir el control de excepciones si se agrega lo siguiente a la sección <runtime> del archivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false" />
</runtime>
NOMBRE Valor
Ámbito Secundaria
Versión 4.7.1
Tipo Redestinación

API afectadas

ServiceBase no propaga las excepciones OnStart

Detalles

En .NET Framework 4.7 y versiones anteriores, las excepciones que se producen al inicio del servicio no se propagan al autor de la llamada de ServiceBase.Run.

A partir de las aplicaciones que tienen como destino .NET Framework 4.7.1, el tiempo de ejecución propaga las excepciones a ServiceBase.Run para los servicios que no se pueden iniciar.

Sugerencia

Durante el inicio del servicio, si hay una excepción, se propaga. Esto debería ayudar a diagnosticar los casos en los que no se pueden iniciar los servicios.

Si no quiere este comportamiento, puede rechazarlo mediante la adición del elemento AppContextSwitchOverrides siguiente a la sección runtime del archivo de configuración de la aplicación:

<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=true" />

Si la aplicación está destinada a una versión anterior a 4.7.1 pero quiere tener este comportamiento, agregue el elemento AppContextSwitchOverrides siguiente a la sección runtime del archivo de configuración de la aplicación:

<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=false" />
Nombre Valor
Ámbito Secundaria
Versión 4.7.1
Tipo Redestinación

API afectadas

Seguridad

Los algoritmos SignedXML y SignedXMS predeterminados se han cambiado a SHA256

Detalles

En .NET Framework 4.7 y versiones anteriores, SignedXML y SignedCMS usaban SHA1 de forma predeterminada para algunas operaciones. A partir de .NET Framework 4.7.1, SHA256 está habilitado de forma predeterminada para estas operaciones. Este cambio es necesario porque SHA1 ya no se considera seguro.

Sugerencia

Hay dos valores de modificador de contexto nuevos para controlar si se usa SHA1 (no seguro) o SHA256 de forma predeterminada:

  • Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms
  • Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms. Para las aplicaciones destinadas a .NET Framework 4.7.1 y versiones posteriores, si no se quiere usar SHA256, se puede restaurar el valor predeterminado a SHA1 si se agrega el conmutador de configuración siguiente a la sección runtime del archivo de configuración de la aplicación:
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=true;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=true" />

Para las aplicaciones destinadas a .NET Framework 4.7 y versiones posteriores, se puede permitir este cambio si se agrega el conmutador de configuración siguiente a la sección runtime del archivo de configuración de la aplicación:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />
NOMBRE Valor
Ámbito Secundaria
Versión 4.7.1
Tipo Redestinación

API afectadas

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

Windows Communication Foundation (WCF)

Mejor accesibilidad para algunas herramientas del SDK de .NET

Detalles

En el SDK de .NET Framework 4.7.1, se han mejorado las herramientas SvcConfigEditor.exe y SvcTraceViewer.exe mediante la corrección de varios problemas de accesibilidad. La mayoría eran problemas menores como un nombre sin definir o determinados patrones de automatización de la interfaz de usuario que no se implementaban correctamente. Aunque muchos usuarios no eran conscientes de estos valores incorrectos, los clientes que usan tecnologías de asistencia como lectores de pantalla encontrarán estas herramientas del SDK más accesibles. De hecho, estas correcciones cambian algunos comportamientos anteriores, como el orden del foco del teclado. Para obtener todas las correcciones de accesibilidad en estas herramientas, puede agregar lo siguiente al archivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false"/>
</runtime>
NOMBRE Valor
Ámbito Borde
Versión 4.7.1
Tipo Redestinación

Windows Forms

Mejoras de accesibilidad en controles de Windows Forms

Detalles

Windows Forms mejora su funcionamiento con las tecnologías de accesibilidad para ofrecer una mejor compatibilidad con los clientes de Windows Forms. Entre estos se incluyen los cambios siguientes a partir de .NET Framework 4.7.1:

  • Cambios para mejorar la presentación durante el modo de contraste alto.
  • Cambios para mejorar la experiencia del Explorador de propiedades. Las mejoras en el Explorador de propiedades incluyen las siguientes:
  • Una mejor navegación mediante teclado gracias a las distintas ventanas de selección desplegables.
  • Se reducen las tabulaciones innecesarias.
  • Mejor notificación de tipos de control.
  • Comportamiento mejorado de Narrador.
  • Cambios para implementar los patrones de accesibilidad de interfaz de usuario que faltan en los controles.

Sugerencia

Cómo participar o no en estos cambios Para que la aplicación se beneficie de estos cambios, se debe ejecutar en .NET Framework 4.7.1 o una versión posterior. La aplicación se puede beneficiar de estos cambios de cualquiera de las maneras siguientes:

  • Se recompila para tener .NET Framework 4.7.1 como destino. Estos cambios de accesibilidad están habilitados de forma predeterminada para las aplicaciones de Windows Forms destinadas a .NET Framework 4.7.1 o una versión posterior.
  • No participa en los comportamientos de accesibilidad heredados mediante la adición del modificador de AppContext a la sección <runtime> del archivo app.config y estableciéndolo en false, como se muestra en el ejemplo siguiente.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
  </startup>
  <runtime>
    <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
  </runtime>
</configuration>

En las aplicaciones destinadas a .NET Framework 4.7.1 o una versión posterior, y en las que se quiere conservar el comportamiento de accesibilidad heredado, se puede participar en el uso de las características de accesibilidad heredadas si se establece explícitamente este modificador de AppContext en true.

Para obtener información general de la automatización de la interfaz de usuario, vea la información general sobre la Automatización de la interfaz de usuario.

Compatibilidad agregada para propiedades y patrones de Automatización de la interfaz de usuario

Los clientes de accesibilidad pueden aprovechar las ventajas de las nuevas funciones de accesibilidad de WinForms mediante modelos de invocación comunes, que se describen de manera pública. Estos patrones no son específicos de WinForms. Por ejemplo, los clientes de accesibilidad pueden llamar el método QueryInterface en la interfaz IAccessible (MAAS) para obtener una interfaz IServiceProvider. Si esta interfaz está disponible, los clientes pueden usar su método QueryService para solicitar una interfaz IAccessibleEx. Para obtener más información, vea Using IAccessibleEx from a Client (Uso de IAccessibleEx desde un cliente). A partir de .NET Framework 4.7.1, IServiceProvider e IAccessibleEx (cuando corresponda) están disponibles para los objetos de accesibilidad de WinForms.

.NET Framework 4.7.1 agrega compatibilidad para los siguientes patrones y propiedades de automatización de la interfaz de usuario:

Uso de colores definidos por el sistema operativo en los temas de contraste alto

  • En los controles Button y CheckBox con la propiedad FlatStyle establecida en FlatStyle.System, que es el estilo predeterminado, ahora se usan colores definidos por el sistema operativo en el tema de contraste alto cuando se seleccionan. Anteriormente, los colores de fondo y de texto no tenían contraste y eran difíciles de leer.
  • En los controles Button, CheckBox, RadioButton, Label, LinkLabel y GroupBox con la propiedad Enabled establecida en false, se usaba un color sombreado para representar el texto en los temas de contraste alto, lo que generaba un contraste bajo sobre el fondo. Ahora, estos controles usan el color "Texto deshabilitado" que define el sistema operativo. Esta revisión se aplica a los controles con la propiedad FlatStyle establecida en un valor distinto de FlatStyle.System. El sistema operativo representa los últimos controles.
  • DataGridView ahora representa un rectángulo visible alrededor del contenido de la celda que tiene el foco actual. Anteriormente, esto no era visible en determinados temas de contraste alto.
  • En los controles ToolStripMenuItem con la propiedad Enabled establecida en false ahora se usa el color "Texto deshabilitado" que define el sistema operativo.
  • Los controles ToolStripMenuItem con la propiedad Checked establecida en true ahora representan la marca de verificación asociada en un color del sistema en contraste. Anteriormente, el color de la marca de verificación no tenía el contraste suficiente y no era visible en los temas de contraste alto. NOTA: En Windows 10 se han cambiado los valores para algunos colores del sistema de contraste alto. El marco de trabajo de Windows Forms se basa en el marco de trabajo de Win32. Para obtener la mejor experiencia, trabaje en la versión más reciente de Windows y use los cambios más recientes del sistema operativo mediante la adición de un archivo app.manifest en una aplicación de prueba y la eliminación de los comentarios del código siguiente:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

Navegación mejorada mediante el teclado

  • Cuando un control ComboBox tiene la propiedad DropDownStyle establecida en ComboBoxStyle.DropDownList y es el primer control del orden de tabulación del formulario, ahora muestra un rectángulo de foco cuando el formulario principal se abre mediante el teclado. Antes de este cambio, el foco del teclado estaba en este control, pero no se representaba un indicador de foco.

Compatibilidad mejorada con Narrador

  • El control MonthCalendar ha agregado compatibilidad para que las tecnologías de asistencia tengan acceso al control, incluida la capacidad de Narrador de leer el valor del control cuando anteriormente no podía.

  • El control CheckedListBox ahora notifica a Narrador cuándo ha cambiado una propiedad CheckBox.CheckState. Anteriormente, Narrador no recibía notificaciones y, como resultado, no se informaba a los usuarios que la propiedad CheckState se había actualizado.

  • El control LinkLabel ha cambiado la forma de notificar a Narrador el texto del control. Anteriormente, Narrador anunciaba dos veces este texto y leía los símbolos "&" como texto real, aunque no eran visibles para los usuarios. El texto duplicado se quitó de los anuncios de Narrador, así como los símbolos "&" innecesarios.

  • Los tipos de control DataGridViewCell ahora notifican correctamente el estado de solo lectura a Narrador y otras tecnologías de asistencia.

  • Ahora Narrador puede leer el menú del sistema de las ventanas secundarias en las aplicaciones [Multiple-Document Interface]~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md).

  • Ahora, Narrador puede leer los controles ToolStripMenuItem con una propiedad ToolStripItem.Enabled establecida en false. Anteriormente Narrador no podía centrarse en los elementos de menú deshabilitados para leer el contenido.

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

API afectadas

Windows Presentation Foundation (WPF)

Mejoras de accesibilidad en WPF

Detalles

Mejoras de contraste alto

  • El foco para el control Expander ahora es visible. En versiones anteriores de .NET Framework no lo era.
  • Cuando se seleccionan los controles CheckBox y RadioButton, ahora el texto es más fácil ver que en versiones anteriores de .NET Framework.
  • El borde de un control ComboBox deshabilitado ahora tiene el mismo color que el texto deshabilitado. En versiones anteriores de .NET Framework no lo era.
  • Los botones deshabilitados y con el foco ahora usan el color de tema correcto. En versiones anteriores de .NET Framework no lo hacían.
  • El botón desplegable ahora es visible cuando el estilo de un control ComboBox se establece en ToolBar.ComboBoxStyleKey. En versiones anteriores de .NET Framework no lo era.
  • La flecha del indicador de ordenación en un control DataGrid ahora usa los colores del tema. En versiones anteriores de .NET Framework no lo hacía.
  • El estilo de hipervínculo predeterminado cambia ahora al color de tema correcto al pasar el mouse. En versiones anteriores de .NET Framework no lo hacía.
  • El foco del teclado en los botones de radio ahora es visible. En versiones anteriores de .NET Framework no lo era.
  • En la columna de casilla del control DataGrid ahora se usan los colores esperados para los comentarios de foco de teclado. En versiones anteriores de .NET Framework no lo hacía.
  • Los objetos visuales de foco de teclado son ahora visibles en los controles ComboBox y ListBox. En versiones anteriores de .NET Framework no lo era.

Mejoras en la interacción con el lector de pantalla

  • Ahora los lectores de pantalla anuncian los controles Expander correctamente como grupos (expandir o contraer).
  • Ahora los lectores de pantalla anuncian los controles DataGridCell correctamente como celdas de cuadrícula de datos (localizadas).
  • Ahora los lectores de pantalla anunciarán el nombre de un ComboBox editable.
  • Los lectores de pantalla ya no anuncian los controles PasswordBox como "no hay elemento a la vista".

Compatibilidad con LiveRegion

Los lectores de pantalla, como Narrador, ayudan a los usuarios a entender la interfaz de usuario (IU) de una aplicación, normalmente mediante la descripción del elemento de la interfaz de usuario que actualmente tiene el foco. Pero si un elemento de la interfaz de usuario cambia en alguna parte de la pantalla y no tiene el foco, puede que no se notifique al usuario y este pierda información importante. Las regiones activas están diseñadas para solucionar este problema. Un desarrollador puede usarlas para informar al lector de pantalla o a cualquier otro cliente de UI Automation de que se ha realizado un cambio importante en un elemento de la interfaz de usuario. Luego el lector de pantalla puede decidir cómo y cuándo informar al usuario de este cambio. La propiedad LiveSetting también permite al lector de pantalla saber la importancia de informar al usuario de los cambios realizados en la interfaz de usuario.

Sugerencia

Cómo participar o no en estos cambios

Para que la aplicación se beneficie de estos cambios, se debe ejecutar en .NET Framework 4.7.1 o una versión posterior. La aplicación se puede beneficiar de estos cambios de cualquiera de las maneras siguientes:

  • Si se establece .NET Framework 4.7.1 como destino. Éste es el enfoque recomendado. Estos cambios de accesibilidad están habilitados de forma predeterminada en las aplicaciones de WPF destinadas a .NET Framework 4.7.1 o una versión posterior.

  • No participa en los comportamientos de accesibilidad heredados mediante la adición del modificador de AppContext siguiente a la sección <runtime> del archivo de configuración de la aplicación y estableciéndolo en false, como se muestra en el ejemplo siguiente.

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
      </startup>
      <runtime>
        <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false'  -->
        <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
      </runtime>
    </configuration>
    

En las aplicaciones destinadas a .NET Framework 4.7.1 o una versión posterior, y en las que se quiere conservar el comportamiento de accesibilidad heredado, se puede participar en el uso de las características de accesibilidad heredadas si se establece explícitamente este modificador de AppContext en true. Para obtener información general de la automatización de la interfaz de usuario, vea Información general sobre la automatización de la interfaz de usuario.

Nombre Valor
Ámbito Major
Versión 4.7.1
Tipo Redestinación

API afectadas

Evento SelectionChanged y propiedad SelectedValue de Selector

Detalles

A partir de .NET Framework 4.7.1, un Selector siempre actualiza el valor de su propiedad SelectedValue antes de generar el evento SelectionChanged cuando cambia su selección. Esto hace que la propiedad SelectedValue sea coherente con las demás propiedades de selección (SelectedItem y SelectedIndex), que se actualizan antes de que se genere el evento.

En .NET Framework 4.7 y versiones anteriores, la actualización de SelectedValue se realizaba antes que el evento en la mayoría de los casos, pero se producía después del evento si el cambio de selección se debía al cambio de la propiedad SelectedValue.

Sugerencia

Las aplicaciones que tienen como destino .NET Framework 4.7.1 o una versión posterior pueden rechazar este cambio y usar el comportamiento heredado si se agrega lo siguiente a la sección <runtime> del archivo de configuración de la aplicación:

<runtime>
<AppContextSwitchOverrides
value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>

Las aplicaciones que tienen como destino .NET Framework 4.7 o versiones anteriores, pero que se ejecutan en .NET Framework 4.7.1 o versiones posteriores, pueden habilitar el comportamiento nuevo si se agrega la línea siguiente a la sección <runtime> del archivo .configuration de la aplicación:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
NOMBRE Valor
Ámbito Secundaria
Versión 4.7.1
Tipo Redestinación

API afectadas

Evento SelectionChanged y propiedad SelectedContent de TabControl

Detalles

A partir de .NET Framework 4.7.1, un control TabControl actualiza el valor de su propiedad SelectedContent antes de generar el evento SelectionChanged cuando su selección cambia. En .NET Framework 4.7 y versiones anteriores, la actualización de SelectedContent se producía después del evento.

Sugerencia

Las aplicaciones que tienen como destino .NET Framework 4.7.1 o una versión posterior pueden rechazar este cambio y usar el comportamiento heredado si se agrega lo siguiente a la sección <runtime> del archivo de configuración de la aplicación:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>

Las aplicaciones que tienen como destino .NET Framework 4.7 o versiones anteriores, pero que se ejecutan en .NET Framework 4.7.1 o versiones posteriores, pueden habilitar el comportamiento nuevo si se agrega la línea siguiente a la sección <runtime> del archivo .configuration de la aplicación:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
NOMBRE Valor
Ámbito Secundaria
Versión 4.7.1
Tipo Redestinación

API afectadas

El algoritmo hash predeterminado para PackageDigitalSignatureManager de WPF ahora es SHA256

Detalles

System.IO.Packaging.PackageDigitalSignatureManager proporciona funcionalidad para las firmas digitales en relación con los paquetes de WPF. En .NET Framework 4.7 y versiones anteriores, el algoritmo predeterminado (PackageDigitalSignatureManager.DefaultHashAlgorithm) que se usaba para firmar los elementos de un paquete era SHA1. Por motivos de seguridad recientes con SHA1, este valor predeterminado se ha cambiado a SHA256 a partir de .NET Framework 4.7.1. Este cambio afecta a todas las firmas de paquetes, incluidos los documentos XPS.

Sugerencia

Un desarrollador que quiera usar este cambio mientras selecciona como destino una versión de la plataforma inferior a .NET Framework 4.7.1 o un desarrollador que requiera la funcionalidad anterior mientras selecciona como destino .NET Framework 4.7.1 o una versión posterior pueden establecer de manera apropiada la marca de AppContext siguiente. Un valor de true dará como resultado el uso de SHA1 como el algoritmo predeterminado; false hará que se use SHA256.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>
NOMBRE Valor
Ámbito Borde
Versión 4.7.1
Tipo Redestinación

API afectadas

Windows Workflow Foundation (WF)

Mejoras de accesibilidad en el Diseñador de flujo de trabajo de Windows Workflow Foundation (WF)

Detalles

El Diseñador de flujo de trabajo de Windows Workflow Foundation (WF) mejora su funcionamiento con tecnologías de accesibilidad. Estas mejoras incluyen los cambios siguientes:

  • Se cambia el orden de tabulación de izquierda a derecha y de arriba a abajo en algunos controles:
  • La ventana Inicializar correlación para establecer los datos de correlación para la actividad InitializeCorrelation.
  • La ventana Definición de contenido para las actividades Receive, Send, SendReply y ReceiveReply.
  • Hay más funciones disponibles a través del teclado:
  • Al editar las propiedades de una actividad, los grupos de propiedades se pueden contraer mediante el teclado la primera vez que obtienen el foco.
  • Ahora los iconos de advertencia son accesibles mediante el teclado.
  • Ahora el botón Más propiedades de la ventana Propiedades es accesible mediante el teclado.
  • Los usuarios del teclado ahora pueden tener acceso a los elementos de encabezado en los paneles Argumentos y Variables del Diseñador de flujo de trabajo.
  • Visibilidad mejorada de los elementos con el foco, por ejemplo cuando:
  • Se agregan filas a las cuadrículas de datos usadas por los diseñadores de actividad y el Diseñador de flujo de trabajo.
  • Desplazamiento entre campos en las actividades ReceiveReply y SendReply.
  • Establecimiento de valores predeterminados para variables o argumentos.
  • Los lectores de pantalla ahora pueden reconocer correctamente:
  • Los puntos de interrupción establecidos en el Diseñador de flujo de trabajo.
  • Las actividades FlowSwitch<T>, FlowDecision y CorrelationScope.
  • El contenido de la actividad Receive.
  • El tipo de destino para la actividad InvokeMethod.
  • El cuadro combinado Excepción y la sección Finally de la actividad TryCatch.
  • El cuadro combinado Tipo de mensaje, el divisor de la ventana Agregar inicializadores de correlación, la ventana Definición de contenido y la ventana Definición de CorrelatesOn en las actividades de mensajería (Receive, Send, SendReply y ReceiveReply).
  • Transiciones a máquina de estados y destinos de transición.
  • Anotaciones y conectores en las actividades FlowDecision.
  • Los menús contextuales (clic con el botón derecho) para las actividades.
  • Los editores de valor de propiedad, el botón Borrar búsqueda, los botones de ordenación Por categoría y Alfabético, y el cuadro de diálogo Editor de expresiones en la cuadrícula de propiedades.
  • El porcentaje de zoom en el Diseñador de flujo de trabajo.
  • El separador en las actividades Parallel y Pick.
  • La actividad InvokeDelegate.
  • La ventana Seleccionar tipos para las actividades de diccionario (Microsoft.Activities.AddToDictionary<TKey,TValue>, Microsoft.Activities.RemoveFromDictionary<TKey,TValue>, etc.).
  • La ventana Examinar y seleccionar un tipo .NET.
  • Rutas de navegación en el Diseñador de flujo de trabajo.
  • Los usuarios que elijan temas de contraste alto verán muchas mejoras en la visibilidad del Diseñador de flujo de trabajo y sus controles, como relaciones de contraste mejoradas entre los elementos y cuadros de selección más evidentes para los elementos del foco.

Sugerencia

Si tiene una aplicación con un diseñador de flujo de trabajo rehospedado, se puede beneficiar de estos cambios si se realiza cualquiera de estas acciones:

  • Volver a compilar la aplicación para destinarla a .NET Framework 4.7.1. Estos cambios de accesibilidad están habilitados de forma predeterminada.
  • Si la aplicación tiene como destino .NET Framework 4.7 o una versión anterior, pero se ejecuta en .NET Framework 4.7.1, puede rechazar estos comportamientos de accesibilidad heredados si agrega el conmutador de AppContext siguiente a la sección <runtime> del archivo app.config de archivos y lo establece en false, como se muestra en el ejemplo siguiente.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
  </startup>
  <runtime>
    <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
  </runtime>
</configuration>

En las aplicaciones destinadas a .NET Framework 4.7.1 o una versión posterior, y en las que se quiere conservar el comportamiento de accesibilidad heredado, se puede participar en el uso de las características de accesibilidad heredadas si se establece explícitamente este modificador de AppContext en true.

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

.NET Framework 4.7.2

Principal

Permitir caracteres de control bidireccional de Unicode en los URI

Detalles

Unicode especifica varios caracteres de control especiales que se usan para especificar la orientación del texto. En versiones anteriores de .NET Framework, estos caracteres se quitaban incorrectamente de todos los URI, incluso si ya estaban presentes en su forma codificada por porcentaje. Para seguir RFC 3987 mejor, ahora se permiten estos caracteres en los URI. Cuando se encuentran sin codificar en un URI, se codifican por porcentaje. Cuando se encuentran codificados por porcentaje, se dejan como están.

Sugerencia

Para las aplicaciones destinadas a versiones de .NET Framework a partir de la 4.7.2, la compatibilidad con los caracteres bidireccionales de Unicode está habilitada de forma predeterminada. Si no quiere este cambio, puede deshabilitarlo mediante la adición del modificador AppContextSwitchOverrides siguiente a la sección <runtime> del archivo de configuración de la aplicación:

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

Para las aplicaciones destinadas a versiones anteriores de .NET Framework pero que se ejecutan en versiones a partir de .NET Framework 4.7.2, la compatibilidad con los caracteres bidireccionales de Unicode está deshabilitada de forma predeterminada. Puede habilitarla mediante la adición del modificador AppContextSwitchOverrides siguiente a la sección <runtime> del archivo de configuración de la aplicación:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=false" />
</runtime>
NOMBRE Valor
Ámbito Secundaria
Versión 4.7.2
Tipo Redestinación

API afectadas

DeflateStream usa las API nativas para la descompresión

Detalles

A partir de .NET Framework 4.7.2, la implementación de la descompresión en la clase T:System.IO.Compression.DeflateStream ha cambiado para usar las API nativas de Windows de forma predeterminada. Normalmente, esto da como resultado una mejora considerable del rendimiento. En todas las aplicaciones de .NET que tienen como destino la versión 4.7.2 de .NET Framework o una versión posterior se usa la implementación nativa. Es posible que este cambio provoque algunas diferencias de comportamiento, como las siguientes:

  • Los mensajes de excepción pueden ser diferentes. Pero el tipo de excepción que se inicia sigue siendo el mismo.
  • Algunas situaciones especiales, por ejemplo no tener memoria suficiente para completar una operación, se pueden administrar de otra manera.
  • Hay diferencias conocidas para el análisis del encabezado de gzip (Nota: Solo se ve afectado GZipStream establecido para la descompresión):
  • Se pueden iniciar excepciones al analizar encabezados no válidos en momentos diferentes.
  • La implementación nativa exige que los valores para algunas marcas reservadas dentro del encabezado de gzip (es decir, FLG) se establezcan según la especificación, lo que puede provocar que se inicie una excepción donde anteriormente se ignoraban los valores no válidos.

Sugerencia

Si la descompresión con las API nativas ha afectado negativamente el comportamiento de la aplicación, puede descartar esta característica si agrega el modificador Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression a la sección runtime del archivo app.config y lo establece en true:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true" />
  </runtime>
</configuration>
NOMBRE Valor
Ámbito Secundaria
Versión 4.7.2
Tipo Redestinación

API afectadas

Asegurarse de que System.Uri usa un juego de caracteres reservados coherente

Detalles

En System.Uri, algunos caracteres codificados por porcentaje que en ocasiones se descodificaban ahora se dejan sin codificar de manera constante. Esto se produce en las propiedades y métodos que tienen acceso a los componentes de ruta de acceso, consulta, fragmento o información de usuario del URI. El comportamiento solo cambiará cuando se cumplen las dos acciones siguientes:

  • El URI contiene el formato codificado de cualquiera de los caracteres reservados siguientes: :, ', (, ), ! o *.
  • El URI contiene un carácter no reservado codificado o Unicode. Si se cumplen las dos condiciones anteriores, los caracteres reservados codificados se dejan codificados. En versiones anteriores de .NET Framework se descodificaban.

Sugerencia

Para las aplicaciones destinadas a versiones de .NET Framework a partir de 4.7.2, el nuevo comportamiento de descodificación está habilitado de forma predeterminada. Si no quiere este cambio, puede deshabilitarlo mediante la adición del modificador AppContextSwitchOverrides siguiente a la sección <runtime> del archivo de configuración de la aplicación:

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

Para las aplicaciones destinadas a versiones anteriores de .NET Framework pero que se ejecutan en versiones a partir de .NET Framework 4.7.2, el comportamiento de descodificación nuevo está deshabilitado de forma predeterminada. Puede habilitarla mediante la adición del modificador AppContextSwitchOverrides siguiente a la sección <runtime> del archivo de configuración de la aplicación:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=false" />
</runtime>
NOMBRE Valor
Ámbito Secundaria
Versión 4.7.2
Tipo Redestinación

API afectadas

Resgen rechaza la carga de contenido desde la web.

Detalles

Los archivos .resx pueden contener entradas con formato binario. Si intenta usar resgen para cargar un archivo que se descargó desde una ubicación que no es de confianza, se producirá un error al cargar la entrada de forma predeterminada.

Sugerencia

Los usuarios de Resgen que necesiten cargar entradas con formato binario desde ubicaciones que no son de confianza pueden quitar la marca de la web del archivo de entrada o aplicar la opción de exclusión en toda la máquina. Agregue la siguiente configuración de registro para aplicar la opción de exclusión en toda la máquina: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\SDK] "AllowProcessOfUntrustedResourceFiles"="true"

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

Los seguimientos de la pila obtenidos al usar archivos PDB portátiles ahora incluyen información del archivo y la línea de origen si se solicita

Detalles

A partir de .NET Framework 4.7.2, los seguimientos de la pila obtenidos al usar archivos PDB portátiles incluyen información del archivo y la línea de origen cuando se solicita. En las versiones anteriores a .NET Framework 4.7.2, la información del archivo y la línea de origen no estaba disponible al usar archivos PDB portátiles incluso si se solicitaba de forma explícita.

Sugerencia

Para las aplicaciones que tienen como destino .NET Framework 4.7.2, se puede rechazar la información del archivo y la línea de origen cuando se usan archivos PDB portátiles si no es adecuada mediante la adición de lo siguiente a la sección <runtime> del archivo app.config:

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

Para las aplicaciones que tienen como destino versiones anteriores de .NET Framework, pero que se ejecutan en .NET Framework 4.7.2 o versiones posteriores, se puede incluir la información del archivo y la línea de origen cuando se usan archivos PDB portátiles si se agrega lo siguiente a la sección <runtime> del archivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=false" />
</runtime>
NOMBRE Valor
Ámbito Borde
Versión 4.7.2
Tipo Redestinación

API afectadas

Windows Forms

Mejoras de accesibilidad en controles de Windows Forms para .NET 4.7.2

Detalles

El marco de trabajo de Windows Forms mejora su funcionamiento con las tecnologías de accesibilidad para ofrecer una mejor compatibilidad con los clientes de Windows Forms. Entre otros, se incluyen los cambios siguientes:

  • Cambios para mejorar la presentación durante el modo de contraste alto.
  • Cambios para mejorar la navegación mediante el teclado en los controles DataGridView y MenuStrip.
  • Cambios en la interacción con Narrador.

Sugerencia

Cómo participar o no en estos cambios Para que la aplicación se beneficie de estos cambios, se debe ejecutar en .NET Framework 4.7.2 o una versión posterior. La aplicación se puede beneficiar de estos cambios de cualquiera de las maneras siguientes:

  • Se recompila para tener .NET Framework 4.7.2 como destino. Estos cambios de accesibilidad están habilitados de forma predeterminada para las aplicaciones de Windows Forms destinadas a .NET Framework 4.7.2 o una versión posterior.
  • Tiene como destino .NET Framework 4.7.1 o una versión anterior, y no participa en los comportamientos de accesibilidad heredados mediante la adición del modificador de AppContext siguiente a la sección <runtime> del archivo app.config y estableciéndolo en false, como se muestra en el ejemplo siguiente.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
  </startup>
  <runtime>
    <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
  </runtime>
</configuration>

Tenga en cuenta que para participar en las características de accesibilidad agregadas en .NET Framework 4.7.2, también se debe participar en las características de accesibilidad de .NET Framework 4.7.1. En las aplicaciones destinadas a .NET Framework 4.7.2 o una versión posterior, y en las que se quiere conservar el comportamiento de accesibilidad heredado, se puede participar en el uso de las características de accesibilidad heredadas si se establece explícitamente este modificador de AppContext en true.

Uso de colores definidos por el sistema operativo en los temas de contraste alto

  • En la flecha desplegable del control ToolStripDropDownButton ahora se usan colores definidos por el sistema operativo en el tema de contraste alto.
  • En los controles Button, RadioButton y CheckBox con FlatStyle establecido en FlatStyle.Flat o FlatStyle.Popup ahora se usan colores definidos por el sistema operativo en el tema de contraste alto cuando se seleccionan. Anteriormente, los colores de fondo y de texto no tenían contraste y eran difíciles de leer.
  • En los controles incluidos en un control GroupBox que tiene su propiedad Enabled establecida en false ahora se usarán colores definidos por el sistema operativo en el tema de contraste alto.
  • Los controles ToolStripButton, ToolStripComboBox y ToolStripDropDownButton tienen una relación de contraste de luminosidad mayor en el modo de contraste alto.
  • En DataGridViewLinkCell se usarán de forma predeterminada colores definidos por el sistema operativo en el modo de contraste alto para la propiedad DataGridViewLinkCell.LinkColor. NOTA: En Windows 10 se han cambiado los valores para algunos colores del sistema de contraste alto. El marco de trabajo de Windows Forms se basa en el marco de trabajo de Win32. Para obtener la mejor experiencia, trabaje en la versión más reciente de Windows y use los cambios más recientes del sistema operativo mediante la adición de un archivo app.manifest en una aplicación de prueba y la eliminación de los comentarios del código siguiente:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

Compatibilidad mejorada con Narrador

  • Ahora Narrador anuncia el valor de la propiedad ToolStripMenuItem.ShortcutKeys al anunciar el texto de un objeto ToolStripMenuItem.
  • Ahora Narrador indica cuándo un objeto ToolStripMenuItem tiene su propiedad Enabled establecida en false.
  • Ahora Narrador ofrece información sobre el estado de una casilla cuando la propiedad ListView.CheckBoxes está establecida en true.
  • El orden de foco del Modo de examen de Narrador ahora es coherente con el orden visual de los controles del cuadro de diálogo de descarga de ClickOnce.

Compatibilidad de accesibilidad de DataGridView mejorada

Indicaciones visuales mejoradas

  • Ahora en los controles RadioButton y CheckBox con una propiedad Text vacía se mostrará un indicador de foco cuando reciban el foco.

Compatibilidad con la cuadrícula de propiedades mejorada

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

La propiedad ContextMenuStrip.SourceControl contiene un control válido en el caso de controles ToolStripMenuItem anidados

Detalles

En .NET Framework 4.7.1 y versiones anteriores, la propiedad ContextMenuStrip.SourceControl devuelve NULL de forma incorrecta cuando el usuario abre el menú desde controles ToolStripMenuItem anidados. En .NET Framework 4.7.2 y versiones posteriores, la propiedad SourceControl siempre se establece en el control de origen real.

Sugerencia

Cómo participar o no en estos cambios Para que una aplicación se beneficie de estos cambios, se debe ejecutar en .NET Framework 4.7.2 o una versión posterior. La aplicación se puede beneficiar de estos cambios de cualquiera de las maneras siguientes:

  • Tiene como destino .NET Framework 4.7.2. Este cambio está habilitado de forma predeterminada para las aplicaciones de Windows Forms destinadas a .NET Framework 4.7.2 o una versión posterior.
  • Tiene como destino .NET Framework 4.7.1 o una versión anterior, y no participa en los comportamientos de accesibilidad heredados mediante la adición del modificador de AppContext siguiente a la sección <runtime> del archivo app.config y estableciéndolo en false, como se muestra en el ejemplo siguiente.
<runtime>
  <AppContextSwitchOverrides value="Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue=false"/>
</runtime>

En las aplicaciones destinadas a .NET Framework 4.7.2 o una versión posterior, y en las que se quiere conservar el comportamiento heredado, se puede participar en el uso del valor de control de origen heredado si se establece explícitamente este modificador de AppContext en true.

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

API afectadas

El método PrivateFontCollection.AddFontFile libera los recursos de fuente

Detalles

En .NET Framework 4.7.1 y versiones anteriores, la clase System.Drawing.Text.PrivateFontCollection no libera los recursos de fuentes GDI+ después de que se elimine PrivateFontCollection para los objetos Font que se agregaron a esta colección con el método AddFontFile(String). En .NET Framework 4.7.2 y versiones posteriores, Dispose libera las fuentes GDI+ que se agregaron a la colección como archivos.

Sugerencia

Cómo participar o no en estos cambios Para que una aplicación se beneficie de estos cambios, se debe ejecutar en .NET Framework 4.7.2 o una versión posterior. La aplicación se puede beneficiar de estos cambios de cualquiera de las maneras siguientes:

  • Se recompila para tener .NET Framework 4.7.2 como destino. Este cambio está habilitado de forma predeterminada para las aplicaciones de Windows Forms destinadas a .NET Framework 4.7.2 o una versión posterior.
  • Tiene como destino .NET Framework 4.7.1 o una versión anterior, y no participa en los comportamientos de accesibilidad heredados mediante la adición del modificador de AppContext siguiente a la sección <runtime> del archivo app.config y estableciéndolo en false, como se muestra en el ejemplo siguiente.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Drawing.Text.DoNotRemoveGdiFontsResourcesFromFontCollection=false"/>
</runtime>

En las aplicaciones destinadas a .NET Framework 4.7.2 o una versión posterior, y en las que se quiere conservar el comportamiento heredado, se puede participar en no liberar los recursos de fuente si se establece explícitamente este modificador de AppContext en true.

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

API afectadas

Las acciones upbutton y downbutton de Domain de WinForm ahora están sincronizadas

Detalles

En .NET Framework 4.7.1 y versiones anteriores, se omite la acción DomainUpDown.UpButton() del control DomainUpDown cuando el texto del control está presente y el desarrollador tiene que usar la acción DomainUpDown.DownButton() en el control antes de usar la acción DomainUpDown.UpButton(). A partir de .NET Framework 4.7.2, las acciones DomainUpDown.UpButton() y DomainUpDown.DownButton() funcionan de manera independiente en este escenario y permanecen sincronizadas.

Sugerencia

Para que una aplicación se beneficie de estos cambios, se debe ejecutar en .NET Framework 4.7.2 o una versión posterior. La aplicación se puede beneficiar de estos cambios de cualquiera de las maneras siguientes:

  • Se recompila para tener .NET Framework 4.7.2 como destino. Este cambio está habilitado de forma predeterminada para las aplicaciones de Windows Forms destinadas a .NET Framework 4.7.2 o una versión posterior.
  • No participa en el comportamiento de desplazamiento heredado mediante la adición del modificador de AppContext a la sección <runtime> del archivo app.config y estableciéndolo en false, como se muestra en el ejemplo siguiente.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling=false"/>
</runtime>
NOMBRE Valor
Ámbito Borde
Versión 4.7.2
Tipo Redestinación

API afectadas

Windows Presentation Foundation (WPF)

El foco del teclado se mueve ahora correctamente entre varios niveles de hospedaje de WinForms y WPF

Detalles

Suponga que una aplicación de WPF hospeda un control de WinForms que, a su vez, hospeda controles de WPF. Es posible que los usuarios no puedan presionar Tab para salir de la capa de WinForms si el primer control o el último de esa capa es System.Windows.Forms.Integration.ElementHost de WPF. Este cambio soluciona este problema y los usuarios ahora pueden presionar Tab para salir de la capa de WinForms. Las aplicaciones automatizadas que se basan en que el foco no escape nunca de la capa de WinForms ya no funcionarán según lo previsto.

Sugerencia

Un desarrollador que quiera usar este cambio mientras selecciona como destino una versión de la plataforma inferior a .NET Framework 4.7.2 puede establecer en false el conjunto siguiente de marcas de AppContext para habilitar el cambio.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false"/>
</runtime>
</configuration>

Las aplicaciones de WPF deben participar en todas las mejoras de accesibilidad anteriores para obtener las mejoras siguientes. En otras palabras, se deben establecer los modificadores Switch.UseLegacyAccessibilityFeatures y Switch.UseLegacyAccessibilityFeatures.2. Un desarrollador que requiera la funcionalidad anterior mientras selecciona como destino .NET Framework 4.7.2 o una versión posterior puede establecer en true la marca de AppContext siguiente para deshabilitar el cambio.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true"/>
</runtime>
</configuration>
NOMBRE Valor
Ámbito Borde
Versión 4.7.2
Tipo Redestinación

Ahora el algoritmo hash predeterminado para el compilador de marcado de WPF es SHA256

Detalles

MarkupCompiler de WPF proporciona servicios de compilación para los archivos de marcado XAML. En .NET Framework 4.7.1 y versiones anteriores, el algoritmo hash predeterminado que se usaba para las sumas de comprobación era SHA1. Por motivos de seguridad recientes con SHA1, este valor predeterminado se ha cambiado a SHA256 a partir de .NET Framework 4.7.2. Este cambio afecta a la generación de todas las sumas de comprobación para los archivos de marcado durante la compilación.

Sugerencia

Un desarrollador que tenga como destino .NET Framework 4.7.2 o una versión posterior y quiera revertir al comportamiento de los algoritmos hash SHA1 debe establecer la marca de AppContext siguiente.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=true"/>
</runtime>
</configuration>

Un desarrollador que quiera usar algoritmos hash SHA256, al tiempo que selecciona como destino una versión de .NET Framework inferior a la 4.7.2, debe establecer la marca de AppContext siguiente. Tenga en cuenta que la versión instalada de .NET Framework debe ser 4.7.2 o posterior.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=false"/>
</runtime>
</configuration>
NOMBRE Valor
Ámbito Transparente
Versión 4.7.2
Tipo Redestinación

Es posible que el control de apagados de AppDomain en WPF llame a Dispatcher.Invoke durante la limpieza de eventos débiles

Detalles

En .NET Framework 4.7.1 y versiones anteriores, WPF crea potencialmente un parámetro System.Windows.Threading.Dispatcher en el subproceso finalizador de .NET durante el apagado de AppDomain. Esto se ha solucionado en .NET Framework 4.7.2 y versiones posteriores configurando la limpieza de eventos débiles para que tenga en cuenta los subprocesos. Por ello, es posible que WPF llame a Dispatcher.Invoke para completar el proceso de limpieza. En algunas aplicaciones, este cambio en el horario del finalizador podría generar excepciones durante el apagado de AppDomain o de procesos. Esto suele detectarse en aplicaciones que no apagan correctamente los distribuidores que se ejecutan en los subprocesos de trabajo antes del apagado de AppDomain o de procesos. Estas aplicaciones deberían encargarse de administrar correctamente la vigencia de los distribuidores.

Sugerencia

En .NET Framework 4.7.2 y versiones posteriores, los desarrolladores pueden deshabilitar esta corrección para reducir (no eliminar) los problemas de horario que se pueden producir debido al cambio en la limpieza. Para deshabilitar dicho cambio, use la siguiente marca de AppContext.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotInvokeInWeakEventTableShutdownListener=true"/>
</runtime>
</configuration>
NOMBRE Valor
Ámbito Borde
Versión 4.7.2
Tipo Redestinación

WPF Cambio de una clave principal cuando se muestran datos ADO en un escenario principal-detalle

Detalles

En el supuesto de que tenga una colección ADO de elementos de tipo Order, con una relación llamada "OrderDetails" que se relaciona con una colección de elementos de tipo Detail a través de la clave principal "OrderID". En su aplicación WPF, puede enlazar un control de lista a los detalles de un pedido determinado:

<ListBox ItemsSource="{Binding Path=OrderDetails}" >

donde DataContext es Order. WPF obtiene el valor de la propiedad OrderDetails: una colección D de todos los elementos Detail cuya OrderID coincide con la OrderID del elemento maestro. El cambio de comportamiento se produce cuando se cambia la clave principal OrderID del elemento maestro. ADO cambia automáticamente el OrderID de cada uno de los registros afectados en la colección Detalles (es decir, los que se copiaron en la colección D). Pero, ¿qué ocurre con D?

  • Comportamiento anterior: la colección D se borra. El elemento principal no genera una notificación de cambio para la propiedad OrderDetails. Listbox continúa usando la colección D, que ahora está vacía.
  • Comportamiento nuevo: la colección D no cambia. Cada uno de sus elementos genera una notificación de cambio para la propiedad OrderID. ListBox continúa usando la colección D, y muestra los detalles con el nuevo OrderID. WPF implementa el comportamiento nuevo mediante la creación de la colección D de una manera diferente: llamar al método ADO DataRowView.CreateChildView(DataRelation, Boolean) con el argumento followParent establecido en true.

Sugerencia

Una aplicación obtiene el nuevo comportamiento mediante el siguiente modificador de AppContext.

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Windows.Data.DoNotUseFollowParentWhenBindingToADODataRelation=false"/>
  </runtime>
</configuration>

El conmutador tiene como valor predeterminado true (comportamiento anterior) para las aplicaciones que tienen como destino .NET 4.7.1 o inferior, y false (nuevo comportamiento) para las aplicaciones que tienen como destino .NET 4.7.2 o posterior.

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

Ahora FocusVisual de WPF para los controles RadioButton y CheckBox se muestra correctamente cuando los controles no tienen contenido

Detalles

En .NET Framework 4.7.1 y versiones anteriores, los controles System.Windows.Controls.CheckBox y System.Windows.Controls.RadioButton de WPF tenían objetos visuales de foco incoherentes y, en los temas Clásico y Contraste alto, eran incorrectos. Estos problemas se producen en casos en los que no se ha definido ningún contenido para los controles. Esto puede hacer que la transición entre los temas sea confusa y el objeto visual de foco difícil de ver. En .NET Framework 4.7.2, estos objetos visuales son ahora más coherentes entre los temas y se ven más fácilmente en los temas Clásico y Contraste alto.

Sugerencia

Un desarrollador que seleccione como destino .NET Framework 4.7.2 y que quiera revertir al comportamiento de .NET 4.7.1 tendrá que establecer la marca de AppContext siguiente.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true;"/>
</runtime>
</configuration>

Un desarrollador que quiera usar este cambio mientras selecciona como destino una versión de .NET Framework inferior a 4.7.2 debe establecer las marcas de AppContext siguientes. Tenga en cuenta que todas las marcas se deben establecer correctamente y que la versión instalada de .NET Framework debe ser 4.7.2 o posterior. Es necesario que las aplicaciones de WPF participen en todas las mejoras de accesibilidad anteriores para obtener las mejoras más recientes. Para ello, asegúrese de que los modificadores "Switch.UseLegacyAccessibilityFeatures" y "Switch.UseLegacyAccessibilityFeatures.2" de AppContext se establezcan en false.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;"/>
</runtime>
</configuration>
NOMBRE Valor
Ámbito Borde
Versión 4.7.2
Tipo Redestinación

La selección de texto de TextBox y PasswordBox de WPF no sigue los colores del sistema

Detalles

En .NET Framework 4.7.1 y versiones anteriores, System.Windows.Controls.TextBox y System.Windows.Controls.PasswordBox de WPF solo podían representar una selección de texto en la capa de adornos. En algunos temas del sistema, esto tapaba el texto, y resultaba difícil de leer. En .NET Framework 4.7.2 y versiones posteriores, los desarrolladores tienen una opción de habilitar un esquema de representación de la selección que no se basa en los adornos y que alivia este problema.

Sugerencia

Un desarrollador que quiera usar este cambio debe establecer correctamente la marca de AppContext siguiente. Para usar esta característica, la versión instalada de .NET Framework debe ser 4.7.2 o posterior. Para habilitar la selección no basada en los adornos, use la marca de AppContext siguiente.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Text.UseAdornerForTextboxSelectionRendering=false"/>
</runtime>
</configuration>
NOMBRE Valor
Ámbito Borde
Versión 4.7.2
Tipo Redestinación

Windows Workflow Foundation (WF)

Evitar la recursión sin fin para IWorkflowInstanceManagement.TransactedCancel e IWorkflowInstanceManagement.TransactedTerminate

Detalles

En algunas circunstancias, cuando se usan las API IWorkflowInstanceManagement.TransactedCancel o IWorkflowInstanceManagement.TransactedTerminate para cancelar o finalizar una instancia del servicio de flujo de trabajo, se puede producir un desbordamiento de pila en la instancia de flujo de trabajo debido a la recursión sin fin cuando el tiempo de ejecución de Workflow intenta conservar la instancia del servicio como parte del procesamiento de la solicitud. El problema se produce si la instancia del flujo de trabajo está en un estado en el que espera que finalice otra solicitud de WCF pendiente a otro servicio. Las operaciones TransactedCancel y TransactedTerminate crean elementos de trabajo que se ponen en cola para la instancia del servicio de flujo de trabajo. Estos elementos de trabajo no se ejecutan como parte del procesamiento de la solicitud de TransactedCancel/TransactedTerminate. Como la instancia del servicio de flujo de trabajo está ocupada en espera a que finalice la otra solicitud de WCF pendiente, el elemento de trabajo que se crea permanece en cola. La operación TransactedCancel/TransactedTerminate se completa y el control se devuelve al cliente. Cuando la transacción asociada con la operación TransactedCancel/TransactedTerminate intenta confirmar, debe conservar el estado de la instancia del servicio de flujo de trabajo. Pero como existe una solicitud de WCF pendiente para la instancia, el tiempo de ejecución del flujo de trabajo no puede conservar la instancia del servicio de flujo de trabajo y un bucle de recursión sin fin genera el desbordamiento de pila. Dado que TransactedCancel y TransactedTerminate solo crean un elemento de trabajo en memoria, el hecho de que exista una transacción no tiene ningún efecto. La reversión de la transacción no descarta el elemento de trabajo. Para solucionar este problema, a partir de .NET Framework 4.7.2, se ha introducido un AppSetting que se puede agregar a la sección web.config/app.config del servicio de flujo de trabajo que le indica que ignore las transacciones para TransactedCancel y TransactedTerminate. Esto permite que la transacción se confirme sin esperar a que se conserve la instancia del flujo de trabajo. La opción AppSetting para esta característica se denomina microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate. Un valor de true indica que la transacción se debe ignorar, lo que evita el desbordamiento de pila. El valor predeterminado de este AppSetting es false, por lo que las instancias del servicio de flujo de trabajo existentes no se ven afectadas.

Sugerencia

Si se usa AppFabric u otro cliente de IWorkflowInstanceManagement y se produce un desbordamiento de pila en la instancia del servicio de flujo de trabajo al intentar cancelar o finalizar una instancia del flujo de trabajo, se puede agregar lo siguiente a la sección <appSettings> del archivo web.config/app.config del servicio de flujo de trabajo:

<add key="microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate" value="true"/>

Si el problema no se produce, no es necesario hacer esto.

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