Cambios de reorientació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.1y 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 un T:System.NullReferenceException
al recuperar un valor de 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 T:System.ArgumentNullException
.
Sugerencia
Puede hacer cualquiera de los siguientes pasos para responder a este cambio:
- Controle el
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 y produce una
T:System.ArgumentNullException
.
Nombre | Valor |
---|---|
Alcance | perimetral |
Versión | 4.6.2 |
Tipo | Redestinación |
Las API afectadas
Límite de solicitudes simultáneas por sesión
Detalles
En .NET Framework 4.6.2 y versiones anteriores, ASP.NET ejecuta solicitudes con el mismo Sessionid secuencialmente y ASP.NET siempre emite Sessionid a través de cookies de forma predeterminada. Si una página tarda mucho tiempo en responder, reducirá significativamente el rendimiento del servidor simplemente presionando F5 en el explorador. En la corrección, hemos agregado un contador para realizar un seguimiento de las solicitudes en cola y finalizar las solicitudes cuando superan 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 puede registrar 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 no participar en el nuevo comportamiento.
<appSettings>
<add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
Nombre | Valor |
---|---|
Alcance | perimetral |
Versión | 4.7 |
Tipo | Redestinación |
Gestión de 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 de red 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 cualquier configuración personalizada realizada por el administrador del sistema. Para obtener información sobre el protocolo SChannel predeterminado en cada versión del sistema operativo Windows, consulte Protocolos en TLS/SSL (Schannel SSP).
En el caso de 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 afecta a las aplicaciones que tienen como destino .NET Framework 4.7 o versiones posteriores. Si prefiere usar un protocolo definido en lugar de confiar en el valor predeterminado del sistema, puede establecer explícitamente el valor de la propiedad ServicePointManager.SecurityProtocol. Si este cambio no es deseable, puede rechazarlo agregando una 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 interruptor de exclusión de Switch.System.Net.DontEnableSystemDefaultTlsVersions
:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7 |
Tipo | Redestinación |
Las API afectadas
SslStream admite alertas 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 Alertas TLS está habilitada por defecto a partir de .NET Framework 4.7. Las aplicaciones destinadas a versiones de .NET Framework de 4.0 a 4.6.2 que se ejecutan en un sistema .NET Framework 4.7 o superior tendrán deshabilitada la característica para conservar la compatibilidad.
La SIGUIENTE API de configuración está disponible para habilitar o deshabilitar la característica para .NET Framework 4.6 y aplicaciones posteriores que se ejecutan en .NET Framework 4.7 o posterior.
Mediante programación: debe ser lo primero que hace la aplicación, ya que ServicePointManager se inicializará solo 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 (máquina global): 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 |
---|---|
Alcance | perimetral |
Versión | 4.7 |
Tipo | Redestinación |
APIs afectadas
- System.Net.Security.SslStream
- System.Net.WebRequest
- System.Net.HttpWebRequest
- System.Net.FtpWebRequest
- System.Net.Mail.SmtpClient
- System.Net.Http
Seguridad
CspParameters.ParentWindowHandle espera ahora el valor HWND
Detalles
El valor de ParentWindowHandle, introducido en .NET Framework 2.0, permite a una aplicación registrar un valor de identificador de ventana principal, de modo que cualquier interfaz de usuario necesaria para acceder a la clave (como un cuadro de diálogo de consentimiento o solicitud de PIN) se abre como un elemento secundario modal en la ventana especificada. A partir de 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 representa una ubicación en la memoria donde residía el HWND valor. Establecer la propiedad a form.Handle en Windows 7 y versiones anteriores no tuvo ningún efecto, pero en Windows 8 y versiones posteriores, da como resultado un "System.Security.Cryptography.CryptographicException: el parámetro es incorrecto".
Sugerencia
Se recomienda que las aplicaciones destinadas a .NET Framework 4.7 o superior que deseen registrar una relación de ventana principal usen el formato simplificado:
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>
Por el contrario, los usuarios que desean participar en el nuevo comportamiento en el entorno de ejecución de .NET Framework 4.7 cuando la aplicación se carga en versiones anteriores de .NET Framework puede establecer el modificador AppContext en false
.
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7 |
Tipo | Redestinación |
API afectadas
SslStream admite alertas 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 función de alertas TLS está habilitada de forma predeterminada desde .NET Framework 4.7. Las aplicaciones destinadas a versiones de .NET Framework de 4.0 a 4.6.2 que se ejecutan en un sistema .NET Framework 4.7 o superior tendrán deshabilitada la característica para conservar la compatibilidad.
La SIGUIENTE API de configuración está disponible para habilitar o deshabilitar la característica para .NET Framework 4.6 y aplicaciones posteriores que se ejecutan en .NET Framework 4.7 o posterior.
Mediante programación: debe ser lo primero que hace la aplicación, ya que ServicePointManager se inicializará solo 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 (máquina global): 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 |
---|---|
Alcance | perimetral |
Versión | 4.7 |
Tipo | Redestinación |
APIs afectadas
- System.Net.Security.SslStream
- System.Net.WebRequest
- System.Net.HttpWebRequest
- System.Net.FtpWebRequest
- System.Net.Mail.SmtpClient
- System.Net.Http
Windows Communication Foundation (WCF)
La serialización de caracteres de control con DataContractJsonSerializer ahora es compatible con ECMAScript V6 y V8
Detalles
En .NET Framework 4.6.2 y versiones anteriores, el System.Runtime.Serialization.Json.DataContractJsonSerializer no serializó algunos caracteres de control especiales, como \b, \f y \t, de una manera 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
En el caso de las aplicaciones que tienen como destino .NET Framework 4.7, esta característica está habilitada de forma predeterminada. Si este comportamiento no es deseable, puede no participar en 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 |
---|---|
Alcance | perimetral |
Versión | 4.7 |
Tipo | Redestinación |
Las API afectadas
- DataContractJsonSerializer.WriteObject(Stream, Object)
- DataContractJsonSerializer.WriteObject(XmlDictionaryWriter, Object)
- DataContractJsonSerializer.WriteObject(XmlWriter, Object)
La seguridad de mensajes 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 mensajes WCF además de SSL3.0 y TLS1.0 a través de las opciones 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 mensajes WCF está deshabilitada de forma predeterminada. Puede habilitarlo agregando la siguiente línea 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 |
---|---|
Alcance | perimetral |
Versión | 4.7 |
Tipo | Redestinación |
Windows Presentation Foundation (WPF)
Las llamadas a System.Windows.Input.PenContext.Disable en sistemas táctiles pueden producir una excepción del tipo 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 solucionado 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 |
---|---|
Alcance | perimetral |
Versión | 4.6.1 |
Tipo | Redestinación |
NullReferenceException en el código de control de excepciones de ImageSourceConverter.ConvertFrom
Detalles
Un error en el código de manejo de excepciones para ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) provocó que se lanzara un incorrecto System.NullReferenceException en lugar de la excepción prevista ( System.IO.DirectoryNotFoundException o System.IO.FileNotFoundException). Este cambio corrige ese error para que ahora el método lance la excepción correcta.
De forma predeterminada, todas las aplicaciones que se dirigen a .NET Framework 4.6.2 y a versiones anteriores continúan lanzando System.NullReferenceException por compatibilidad. Los desarrolladores que desarrollan para .NET Framework 4.7 y versiones posteriores deben encontrar las excepciones correctas.
Sugerencia
Los desarrolladores que deseen revertir a la obtención de System.NullReferenceException cuando tienen como destino .NET Framework 4.7 o posterior 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 |
---|---|
Alcance | perimetral |
Versión | 4.7 |
Tipo | Redestinación |
Las 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 *-columns. Esto cambiará el ancho real asignado a *-columns en varios casos:
- Cuando una o varias 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 dos primeros casos, los anchos generados por el nuevo algoritmo pueden ser significativamente diferentes de los generados por el algoritmo anterior; 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 anterior:
La asignación total a columnas puede superar el ancho de la cuadrícula. Esto puede ocurrir al asignar espacio a una columna cuya cuota proporcional es menor que su tamaño mínimo. El algoritmo asigna el tamaño mínimo, lo que reduce 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 ser inferior al 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 se ha indicado anteriormente, esto cambia el espacio disponible para la columna C, que obtiene menos (o más) asignación proporcional a la A.
Las columnas con pesos extremadamente grandes (> 10^298) se tratan como si tuvieran peso 10^298. No se respetan las diferencias proporcionales entre ellas (y entre columnas con pesos ligeramente más pequeños).
Las columnas con pesos infinitos no se controlan correctamente. (En realidad no se puede establecer un peso en Infinity, pero se trata de una restricción artificial. El código de asignación estaba intentando controlarlo, pero haciendo un trabajo incorrecto).
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 criterios siguientes:
- El ancho real asignado a una columna *-nunca es menor que su ancho mínimo ni mayor que su ancho máximo.
- A cada columna * que no se le asigna un ancho mínimo ni máximo se le asigna un ancho proporcional a su *-peso. Para ser precisos, si dos columnas se declaran con el ancho x* e y* respectivamente, y si ninguna columna recibe su ancho mínimo o máximo, los anchos reales v y w asignados a las columnas están en la misma proporción: v / w == x / y.
- El ancho total asignado a las columnas * de tipo proporcional es igual al espacio disponible después de asignar a las columnas restringidas (columnas fijas, automáticas y columnas * que se les asigna su ancho mínimo o máximo). Esto puede ser cero, por ejemplo, si la suma de los anchos mínimos supera el ancho disponible de la cuadrícula.
- Todas estas instrucciones deben interpretarse con respecto al diseño "ideal". Cuando el redondeo de diseño está en efecto, los anchos reales pueden diferir de los anchos ideales hasta en un píxel.
Nota
Todo lo que se dice sobre las columnas y los anchos de este artículo también se aplica 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 nuevo algoritmo, mientras que las aplicaciones destinadas a .NET Framework 4.6.2 o versiones anteriores verán el algoritmo anterior.
Para invalidar el valor predeterminado, use la siguiente configuración:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
El valor true
selecciona el algoritmo anterior, false
selecciona el nuevo algoritmo.
Nombre | Valor |
---|---|
Alcance | 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 soltar no mostrará la retroalimentación adecuada para la entrada táctil
- Esto no afecta a la entrada del lápiz óptico
- 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 deseen 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 quita este valor o se establece en false, se desactivará esta pila opcional. Tenga en cuenta que esta pila solo está disponible en Windows 10 Creators Update y versiones posteriores.
Nombre | Valor |
---|---|
Alcance | perimetral |
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 |
---|---|
Alcance | Secundaria |
Versión | 4.7 |
Tipo | Redestinación |
.NET Framework 4.7.1
ASP.NET
ASP.NET Mejoras de accesibilidad en .NET Framework 4.7.1
Detalles
A partir de .NET Framework 4.7.1, ASP.NET ha mejorado la forma en que los controles web de ASP.NET funcionan con la tecnología de accesibilidad en Visual Studio para mejorar el soporte a los clientes de ASP.NET. Estos incluyen los siguientes cambios:
- Cambios para implementar patrones de accesibilidad de la interfaz de usuario que faltan en los controles, como el cuadro de diálogo Agregar campo en el Asistente para vista de detalles o el cuadro de diálogo Configurar ListView del asistente de ListView.
- Cambios para mejorar la visualización en modo de alto contraste, como el Editor de Campos del Paginador 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, debe ejecutarse en .NET Framework 4.7.1 o posterior. La aplicación web puede beneficiarse de estos cambios de cualquiera de las maneras siguientes:
- Instale Visual Studio 2017 15.3 o posterior, que admite las nuevas características de accesibilidad con el siguiente conmutador AppContext por defecto.
- Para no participar en los comportamientos de accesibilidad heredados, agregue el modificador
Switch.UseLegacyAccessibilityFeatures
AppContext a la sección<runtime>
del archivo devenv.exe.config y establézelo enfalse
, 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>
Las aplicaciones que tienen como destino .NET Framework 4.7.1 o posterior y que desean conservar el comportamiento de accesibilidad heredado pueden optar por el uso de características de accesibilidad heredadas estableciendo explícitamente este modificador de AppContext en true
.
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7.1 |
Tipo | Redestinación |
Núcleo
Excepciones de subprocesos en segundo plano SerialPort
Detalles
Los subprocesos en segundo plano creados con flujos SerialPort ya no finalizan el proceso cuando se lanzan excepciones del SO.
En las aplicaciones que tienen como destino .NET Framework 4.7 y versiones anteriores, se finaliza un proceso cuando se produce una excepción de sistema operativo en un subproceso en segundo plano creado con una secuencia de SerialPort.
En las aplicaciones que tienen como destino .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 podrían bloquearse 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>
En el caso de las aplicaciones destinadas a versiones anteriores de .NET Framework, pero que se ejecutan en .NET Framework 4.7.1 o posterior, puede optar por el control de excepciones agregando lo siguiente a la sección <runtime>
del archivo app.config
:
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false" />
</runtime>
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7.1 |
Tipo | Redestinación |
APIs afectadas
ServiceBase no propaga las excepciones de 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 entorno de ejecución propaga excepciones a ServiceBase.Run para los servicios que no se pueden iniciar.
Sugerencia
En el inicio del servicio, si hay una excepción, esa excepción se propagará. Esto debería ayudar a diagnosticar casos en los que los servicios no se inician.
Si este comportamiento no es deseable, puede rechazarlo agregando el siguiente elemento AppContextSwitchOverrides
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 tiene como destino una versión anterior a la 4.7.1, pero quiere tener este comportamiento, agregue el siguiente elemento AppContextSwitchOverrides
a la sección runtime
del archivo de configuración de la aplicación:
<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=false" />
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7.1 |
Tipo | Redestinación |
APIs afectadas
Seguridad
Los algoritmos SignedXML y SignedXMS predeterminados han cambiado a SHA256
Detalles
En .NET Framework 4.7 y versiones anteriores, SignedXML y SignedCMS se establece de forma predeterminada en SHA1 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 nuevos valores de modificador de contexto para controlar si SHA1 (no seguro) o SHA256 se usa de forma predeterminada:
- Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms
- Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms Para las aplicaciones que tienen como destino .NET Framework 4.7.1 y versiones posteriores, si el uso de SHA256 no es deseable, puede restaurar el valor predeterminado a SHA1 agregando el siguiente modificador de configuración 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 |
---|---|
Alcance | Secundaria |
Versión | 4.7.1 |
Tipo | Redestinación |
APIs afectadas
- System.Security.Cryptography.Pkcs.CmsSigner
- System.Security.Cryptography.Xml.SignedXml
- System.Security.Cryptography.Xml.Reference
SignedXml.GetPublicKey devuelve RSACng en net462 (o Lightup) sin cambios de redestinación
Detalles
A partir de .NET Framework 4.6.2, el tipo concreto del objeto devuelto por el método SignedXml.GetPublicKey cambió (sin una peculiaridad) de una implementación cryptoServiceProvider a una implementación de Cng. Esto se debe a que la implementación ha cambiado de usar certificate.PublicKey.Key
a usar el certificate.GetAnyPublicKey
interno que reenvía a RSACertificateExtensions.GetRSAPublicKey.
Sugerencia
A partir de las aplicaciones que se ejecutan en .NET Framework 4.7.1, puede usar la implementación cryptoServiceProvider que se usa de forma predeterminada en .NET Framework 4.6.1 y versiones anteriores agregando el siguiente modificador de configuración 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 |
---|---|
Alcance | perimetral |
Versión | 4.6.2 |
Tipo | Redestinación |
APIs afectadas
Windows Communication Foundation (WCF)
Accesibilidad mejorada para algunas herramientas del SDK de .NET
Detalles
En el SDK de .NET Framework 4.7.1, las herramientas de SvcConfigEditor.exe y SvcTraceViewer.exe se han mejorado mediante la corrección de diversos problemas de accesibilidad. La mayoría de estos problemas eran pequeños, como un nombre que no se define o determinados patrones de automatización de la interfaz de usuario no se implementan correctamente. Aunque muchos usuarios no serían conscientes de estos valores incorrectos, los clientes que usan tecnologías de asistencia, como los lectores de pantalla, encontrarán estas herramientas del SDK más accesibles. Sin duda, estas correcciones cambian algunos comportamientos anteriores, como el orden de foco del teclado. Para obtener todas las correcciones de accesibilidad de estas herramientas, puede hacer lo siguiente en el archivo app.config:
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false"/>
</runtime>
Nombre | Valor |
---|---|
Alcance | perimetral |
Versión | 4.7.1 |
Tipo | Redestinación |
Windows Forms
Mejoras de accesibilidad en los controles de Windows Forms
Detalles
Windows Forms mejora el funcionamiento de las tecnologías de accesibilidad para admitir mejor a los clientes de Windows Forms. Estos incluyen los siguientes cambios a partir de .NET Framework 4.7.1:
- Cambios para mejorar la visualización durante el modo de contraste alto.
- Cambios para mejorar la experiencia del explorador de propiedades. Entre las mejoras del explorador de propiedades se incluyen las siguientes:
- Mejor navegación por teclado a través de las distintas ventanas de selección desplegable.
- Se reducen las tabulaciones innecesarias.
- Mejor elaboración de informes de tipos de control.
- Comportamiento mejorado del narrador.
- Cambios para implementar patrones de accesibilidad de la 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, debe ejecutarse en .NET Framework 4.7.1 o posterior. La aplicación puede beneficiarse de estos cambios de cualquiera de las maneras siguientes:
- Se vuelve a compilar para tener como destino .NET Framework 4.7.1. Estos cambios de accesibilidad están habilitados de forma predeterminada en las aplicaciones de Windows Forms que tienen como destino .NET Framework 4.7.1 o posterior.
- Opta por no participar en los comportamientos de accesibilidad heredados agregando el siguiente modificador AppContext a la sección
<runtime>
del archivo app.config y estableciendolo enfalse
, 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>
Las aplicaciones que tienen como destino .NET Framework 4.7.1 o posterior y que desean conservar el comportamiento de accesibilidad heredado pueden optar por el uso de características de accesibilidad heredadas estableciendo explícitamente este modificador de AppContext en true
.
Para obtener información general sobre la automatización de la interfaz de usuario, consulte la Información general sobre la automatización de la interfaz de usuario.
Se ha agregado compatibilidad con patrones y propiedades de automatización de la interfaz de usuario
Los clientes de accesibilidad pueden aprovechar las nuevas funcionalidades de accesibilidad de WinForms mediante patrones de invocación comunes descritos públicamente. Estos patrones no son específicos de WinForms. Por ejemplo, los clientes de accesibilidad pueden llamar al 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 y IAccessibleEx (si procede) están disponibles para objetos de accesibilidad de WinForms.
.NET Framework 4.7.1 agrega compatibilidad con los siguientes patrones y propiedades de automatización de la interfaz de usuario:
Los controles ToolStripSplitButton y ComboBox admiten ahora el patrón de expansión o contracción.
El control ToolStripMenuItem tiene un valor de la propiedad ControlType de ControlType.MenuItem.
El control ToolStripItem admite la propiedad NameProperty y el patrón de expansión o contracción.
El control ToolStripDropDownItem admite eventos AccessibleEvents en los que se indique StateChange y NameChange cuando la lista desplegable está expandida o contraída.
El control ToolStripDropDownButton tiene un valor de la propiedad ControlType de ControlType.MenuItem.
El control DataGridViewCheckBoxCell admite el TogglePattern.
Los controles NumericUpDown y DomainUpDown admiten la propiedad NameProperty y tienen una propiedad ControlType de ControlType.Spinner.
mejoras en el control PropertyGrid .NET Framework 4.7.1 agrega las siguientes mejoras al control PropertyBrowser:El botón Detalles del cuadro de diálogo Error que se muestra cuando el usuario escribe un valor incorrecto en el control PropertyGrid admite el patrón de expansión o contracción, notificaciones de cambio de estado y nombre, y una propiedad ControlType con un valor de ControlType.MenuItem.
El panel de mensajes que se muestra cuando el Detalles botón del cuadro de diálogo de error se expande ahora es accesible con el teclado y permite al Narrador anunciar el contenido del mensaje de error.
El AccessibleRole de las filas del control PropertyGrid ha cambiado de "Fila" a "Celda". La celda se asigna a la propiedad ControlType de UIA "DataItem", que le permite admitir los métodos abreviados de teclado adecuados y los anuncios de Narrador.
Las filas del control PropertyGrid que representan elementos de encabezado cuando el control PropertyGrid tiene una propiedad PropertySort establecida en PropertySort.Categorized tienen un valor de la propiedad ControlType de ControlType.Button.
Las filas del control PropertyGrid que representan elementos de encabezado cuando el control PropertyGrid tiene una propiedad PropertySort establecida en PropertySort.Categorized admiten el patrón de expansión o contracción.
Navegación de teclado mejorada entre la cuadrícula y la barra de herramientas encima de ella. Al presionar "Mayús-Tab", ahora se selecciona el primer botón de la barra de herramientas, en lugar de toda la barra de herramientas.
Los controles PropertyGrid que se muestran en el modo de contraste alto ahora dibujarán un rectángulo de foco alrededor del botón de la barra de herramientas que se corresponde al valor de la propiedad PropertySort actual.
Los controles PropertyGrid que se muestran en el modo de contraste alto y que tienen una propiedad PropertySort establecida en PropertySort.Categorized ahora mostrarán el fondo de los encabezados de categoría en un color de contraste alto.
PropertyGrid controla mejor la diferenciación entre los elementos de la barra de herramientas enfocados y los elementos de la barra de herramientas que indican el valor actual de la propiedad PropertySort. Esta corrección consta de un cambio de contraste alto y un cambio para escenarios que no son de contraste alto.
Los elementos ToolBar del control PropertyGrid que indica el valor actual de la propiedad PropertySort admiten el TogglePattern.
Compatibilidad mejorada de Narrador para distinguir la alineación seleccionada en el selector de alineación.
Cuando se muestra un control PropertyGrid vacío en un formulario, ahora recibirá el foco donde anteriormente no lo hacía.
uso de colores definidos por el sistema operativo en temas de contraste alto
- Los controles Button y CheckBox con su propiedad FlatStyle establecida en FlatStyle.System, que es el estilo predeterminado, ahora usan colores definidos por el sistema operativo en el tema de alto contraste, cuando se seleccionan. Anteriormente, los colores de texto y fondo no contrastaban y eran difíciles de leer.
- Los controles Button, CheckBox, RadioButton, Label, LinkLabely GroupBox con su propiedad Enabled establecida en false usaron un color sombreado para representar texto en temas de contraste alto, lo que da lugar a un contraste bajo con el fondo. Ahora, estos controles utilizan el color de texto deshabilitado definido por el sistema operativo. Esta corrección se aplica a los controles con la propiedad
FlatStyle
establecida en un valor distinto de FlatStyle.System. El sistema operativo gestiona los controles posteriores. - DataGridView ahora muestra un rectángulo visible alrededor del contenido de la celda que tiene el foco actual. Anteriormente, esto no era visible en ciertos 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 contrastaba lo suficiente y no era visible en los temas de contraste alto. NOTA: Windows 10 ha cambiado los valores de algunos colores del sistema de contraste alto. Windows Forms Framework se basa en el marco Win32. Para obtener la mejor experiencia, ejecute en la versión más reciente de Windows y opte por los cambios más recientes del sistema operativo agregando un archivo app.manifest en una aplicación de prueba y anulando los comentarios del código siguiente:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
Navegación con teclado mejorada
- Cuando un control ComboBox tiene su 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 primario 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 con Narrador mejorada
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, el Narrador no recibió una notificación y, como resultado, los usuarios no se informarían de que se había actualizado la propiedad CheckState.
El control LinkLabel ha cambiado la forma de notificar a Narrador el texto del control. Anteriormente, el Narrador anunció este texto dos veces y leyó los símbolos "&" como texto real, incluso cuando no son visibles para el usuario. El texto duplicado se eliminó de los anuncios del 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 |
---|---|
Alcance | Principal |
Versión | 4.8 |
Tipo | Redestinación |
APIs afectadas
- ToolStripDropDownButton.CreateAccessibilityInstance()
- DomainUpDown.DomainUpDownAccessibleObject.Name
- MonthCalendar.AccessibilityObject
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.
- El texto en los controles CheckBox y RadioButton, cuando son seleccionados, ahora es más fácil de ver que en versiones anteriores de .NET Framework.
- El borde de un ComboBox deshabilitado ahora es 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, ellos no lo hicieron.
- 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 de un control DataGrid ahora usa colores de tema. En versiones anteriores de .NET Framework, no lo hacía.
- El estilo de hipervínculo predeterminado ahora cambia al color de tema correcto al pasar el ratón. En las versiones anteriores de .NET Framework, esto no estaba presente.
- El foco del teclado en los botones de radio ahora está 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, eso no ocurrí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
- Expander ahora los lectores de pantalla anuncian los controles correctamente como grupos (expandir o contraer).
- DataGridCell ahora los lectores de pantalla anuncian los controles correctamente como celdas de cuadrícula de datos (localizadas).
- Ahora los lectores de pantalla anunciarán el nombre de un ComboBox editable.
- PasswordBox los lectores de pantalla ya no anuncian los controles como "no hay elemento a la vista".
Compatibilidad con LiveRegion
Los lectores de pantalla, como Narrador, ayudan a los usuarios a comprender la interfaz de usuario (UI) de una aplicación, normalmente mediante la descripción del elemento de interfaz de usuario que actualmente tiene el foco. Sin embargo, si un elemento de la interfaz de usuario cambia en algún lugar de la pantalla y no tiene el foco, es posible que el usuario no se informe y pierda información importante. LiveRegions está pensado para resolver este problema. Un desarrollador puede usarlos para informar al lector de pantalla o a cualquier otro cliente de automatización de la interfaz de usuario que se haya realizado un cambio importante en un elemento de la interfaz de usuario. Después, 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 lo importante que es informar al usuario del cambio realizado en la interfaz de usuario.
Sugerencia
Cómo participar o no en estos cambios
Para que la aplicación se beneficie de estos cambios, debe ejecutarse en .NET Framework 4.7.1 o posterior. La aplicación puede beneficiarse de estos cambios de cualquiera de las maneras siguientes:
Si se establece .NET Framework 4.7.1 como destino. Este es el enfoque recomendado. Estos cambios de accesibilidad están habilitados de forma predeterminada en aplicaciones WPF destinadas a .NET Framework 4.7.1 o 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 enfalse
, 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>
Las aplicaciones que tienen como destino .NET Framework 4.7.1 o posterior y que desean conservar el comportamiento de accesibilidad heredado pueden optar por el uso de características de accesibilidad heredadas estableciendo explícitamente este modificador de AppContext en true
.
Para obtener información general sobre la automatización de la interfaz de usuario, consulte introducción a la automatización de la interfaz de usuario .
Nombre | Valor |
---|---|
Alcance | Principal |
Versión | 4.7.1 |
Tipo | Redestinación |
APIs afectadas
- AutomationElementIdentifiers.LiveSettingProperty
- AutomationElementIdentifiers.LiveRegionChangedEvent
- System.Windows.Automation.AutomationLiveSetting
- AutomationProperties.LiveSettingProperty
- AutomationProperties.SetLiveSetting(DependencyObject, AutomationLiveSetting)
- AutomationProperties.GetLiveSetting(DependencyObject)
- AutomationPeer.GetLiveSettingCore()
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 generar el evento.
En .NET Framework 4.7 y versiones anteriores, la actualización a SelectedValue se produjo antes del evento en la mayoría de los casos, pero ocurrió después del evento si el cambio de selección se produjo al cambiar la propiedad SelectedValue.
Sugerencia
Las aplicaciones que tienen como destino .NET Framework 4.7.1 o posterior pueden rechazar este cambio y usar el comportamiento heredado agregando 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 posterior pueden habilitar el nuevo comportamiento agregando la línea siguiente a la sección <runtime>
del archivo de configuración de la aplicación:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7.1 |
Tipo | Redestinación |
APIs afectadas
Evento SelectionChanged y propiedad SelectedContent de TabControl
Detalles
A partir de .NET Framework 4.7.1, un TabControl actualiza el valor de su propiedad SelectedContent antes de generar el evento SelectionChanged, cuando cambia su selección. En .NET Framework 4.7 y versiones anteriores, la actualización a SelectedContent se produjo después del evento.
Sugerencia
Las aplicaciones que tienen como destino .NET Framework 4.7.1 o posterior pueden rechazar este cambio y usar el comportamiento heredado agregando 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 posterior pueden habilitar el nuevo comportamiento agregando la línea siguiente a la sección <runtime>
del archivo de configuración de la aplicación:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7.1 |
Tipo | Redestinación |
APIs afectadas
El algoritmo hash predeterminado para PACKAGEDigitalSignatureManager de WPF ahora es SHA256.
Detalles
El System.IO.Packaging.PackageDigitalSignatureManager
proporciona funcionalidad para firmas digitales en relación con los paquetes WPF. En .NET Framework 4.7 y versiones anteriores, el algoritmo predeterminado (PackageDigitalSignatureManager.DefaultHashAlgorithm) usado para firmar partes de un paquete era SHA1. Debido a problemas 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 toda la firma de paquetes, incluidos los documentos XPS.
Sugerencia
Un desarrollador que quiera usar este cambio mientras tiene como destino una versión de marco inferior a .NET Framework 4.7.1 o un desarrollador que requiera la funcionalidad anterior mientras que el destino es .NET Framework 4.7.1 o superior puede establecer la siguiente marca appContext de forma adecuada. Un valor true dará como resultado que SHA1 se use como algoritmo predeterminado; false da como resultado SHA256.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>
Nombre | Valor |
---|---|
Alcance | perimetral |
Versión | 4.7.1 |
Tipo | Redestinación |
API afectadas
Windows Workflow Foundation (WF)
Mejoras de accesibilidad en el diseñador de flujos de trabajo de Windows Workflow Foundation (WF)
Detalles
El diseñador de flujos de trabajo de Windows Workflow Foundation (WF) mejora cómo funciona con las tecnologías de accesibilidad. Estas mejoras incluyen los siguientes cambios:
- El orden de tabulación se cambia a izquierda a derecha y de arriba abajo en algunos controles:
- La ventana Inicializar correlación para establecer los datos de correlación para la actividad InitializeCorrelation.
- Ventana de definición de contenido para las actividades de Receive, Send, SendReplyy 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.
- Los iconos de advertencia ahora son accesibles mediante el teclado.
- El botón Más propiedades de la ventana Propiedades ahora es accesible mediante el teclado.
- Los usuarios del teclado ahora pueden acceder a los elementos de encabezado en los paneles Argumentos y Variables del Diseñador de flujos de trabajo.
- Visibilidad mejorada de los elementos con foco, como cuando:
- Agregar filas a cuadrículas de datos usadas por el Diseñador de flujos de trabajo y diseñadores de actividad.
- 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:
- 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.
- 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.
- Porcentaje de zoom en el Diseñador de flujos 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 eligen temas de contraste alto verán muchas mejoras en la visibilidad del Diseñador de flujos de trabajo y sus controles, como mejores relaciones de contraste entre elementos y cuadros de selección más notables usados para los elementos de foco.
Sugerencia
Si tiene una aplicación con un diseñador de flujo de trabajo rehospedado, la aplicación puede beneficiarse de estos cambios realizando cualquiera de estas acciones:
- Vuelva a compilar la aplicación para que se dirija 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 versiones anteriores, pero se ejecuta en .NET Framework 4.7.1, puede no participar en estos comportamientos de accesibilidad heredados agregando el siguiente modificador AppContext a la sección
<runtime>
del archivo de app.config y establézcalo enfalse
, 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>
Las aplicaciones que tienen como destino .NET Framework 4.7.1 o posterior y que desean conservar el comportamiento de accesibilidad heredado pueden optar por el uso de características de accesibilidad heredadas estableciendo explícitamente este modificador de AppContext en true
.
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7.1 |
Tipo | Redestinación |
.NET Framework 4.7.2
Núcleo
Permitir caracteres de control bidireccional Unicode en 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 quitaron incorrectamente de todos los URI aunque estuvieran presentes en su forma codificada por porcentaje. Para seguir mejor RFC 3987, ahora se permiten estos caracteres en los URI. Cuando se encuentran sin codificar en un URI, se codifican mediante porcentajes. Cuando se encuentran codificados por porcentaje, se dejan como están.
Sugerencia
En el caso de las aplicaciones que tienen como destino versiones de .NET Framework a partir de la versión 4.7.2, la compatibilidad con caracteres bidireccionales Unicode está habilitada de forma predeterminada. Si este cambio no es deseable, puede deshabilitarlo agregando el siguiente interruptor AppContextSwitchOverrides a la sección <runtime>
del archivo de configuración de la aplicación:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=true" />
</runtime>
En el caso de 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 caracteres bidireccionales Unicode está deshabilitada de forma predeterminada. Puede habilitarlo agregando el siguiente conmutador AppContextSwitchOverrides 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 |
---|---|
Alcance | Secundaria |
Versión | 4.7.2 |
Tipo | Redestinación |
APIs afectadas
DeflateStream usa API nativas para la descompresión
Detalles
A partir de .NET Framework 4.7.2, la implementación de 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 sustancial del rendimiento. Todas las aplicaciones .NET destinadas a .NET Framework versión 4.7.2 o posterior usan la implementación nativa. Este cambio puede dar lugar a algunas diferencias en el comportamiento, entre las que se incluyen:
- Los mensajes de excepción pueden ser diferentes. Sin embargo, el tipo de excepción que se produce sigue siendo el mismo.
- Algunas situaciones especiales, como no tener suficiente memoria para completar una operación, pueden controlarse de forma diferente.
- Hay diferencias conocidas para el análisis del encabezado de gzip (Nota: Solo se ve afectado
GZipStream
establecido para la descompresión): - Las excepciones al analizar encabezados no válidos se pueden producir en momentos diferentes.
- La implementación nativa aplica que los valores de algunas marcas reservadas dentro del encabezado gzip (es decir, FLG) se establecen según la especificación, lo que puede provocar que se produzca una excepción en la que se omiten los valores no válidos anteriormente.
Sugerencia
Si la descompresión con las APIs nativas ha afectado negativamente al comportamiento de su aplicación, puede desactivar esta función agregando el modificador Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression
a la sección runtime
del archivo app.config y configurarlo en true
.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true" />
</runtime>
</configuration>
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7.2 |
Tipo | Redestinación |
APIs afectadas
Asegúrese de que System.Uri utilice un conjunto de caracteres reservados coherente.
Detalles
En System.Uri, ciertos caracteres codificados por porcentaje que a veces se descodificaban ahora se dejan codificados de forma coherente. Esto ocurre en las propiedades y los métodos que acceden a la ruta, consulta, fragmento o componentes de userinfo del URI. El comportamiento solo cambiará cuando se cumplen las dos condiciones siguientes:
- El URI contiene la forma codificada de cualquiera de los siguientes caracteres reservados:
:
,'
,(
,)
,!
o*
. - El URI contiene un carácter Unicode o un carácter no reservado codificado. Si ambos valores anteriores son verdaderos, los caracteres reservados codificados se dejan codificados. En versiones anteriores de .NET Framework, se descodifican.
Sugerencia
En el caso de las aplicaciones destinadas a versiones de .NET Framework a partir de la versión 4.7.2, el nuevo comportamiento de descodificación está habilitado de forma predeterminada. Si este cambio no es deseable, puede deshabilitarlo agregando el siguiente conmutador AppContextSwitchOverrides a la sección <runtime>
del archivo de configuración de la aplicación.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=true" />
</runtime>
En el caso de las aplicaciones destinadas a versiones anteriores de .NET Framework, pero que se ejecutan en versiones a partir de .NET Framework 4.7.2, el nuevo comportamiento de descodificación está deshabilitado de forma predeterminada. Puede habilitarlo agregando el siguiente interruptor AppContextSwitchOverrides en la sección <runtime>
del archivo de configuración de la aplicación:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=false" />
</runtime>
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7.2 |
Tipo | Redestinación |
APIs afectadas
Resgen se niega a cargar 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ó de una ubicación que no es de confianza, no podrá 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 |
---|---|
Alcance | perimetral |
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 de archivo de origen y línea no estaba disponible al usar PDBs portátiles incluso si se solicitaba explícitamente.
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 |
---|---|
Alcance | perimetral |
Versión | 4.7.2 |
Tipo | Redestinación |
APIs afectadas
Windows Forms
Mejoras de accesibilidad en los controles de Windows Forms para .NET 4.7.2
Detalles
Windows Forms Framework mejora el funcionamiento de las tecnologías de accesibilidad para admitir mejor a los clientes de Windows Forms. Estos incluyen los siguientes cambios:
- Cambios para mejorar la visualización durante el modo de contraste alto.
- Cambios para mejorar la navegación por 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, debe ejecutarse en .NET Framework 4.7.2 o posterior. La aplicación puede beneficiarse de estos cambios de cualquiera de las maneras siguientes:
- Se vuelve a compilar para tener como destino .NET Framework 4.7.2. Estos cambios de accesibilidad están habilitados de forma predeterminada en las aplicaciones de Windows Forms que tienen como destino .NET Framework 4.7.2 o posterior.
- Tiene como destino .NET Framework 4.7.1 o una versión anterior y opta por excluirse de los comportamientos de accesibilidad heredados agregando el siguiente conmutador AppContext a la sección
<runtime>
del archivo de configuración de la aplicación y configurándolo enfalse
, 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 debe optar por las características de accesibilidad de .NET Framework 4.7.1. Las aplicaciones que tienen como destino .NET Framework 4.7.2 o posterior y que desean conservar el comportamiento de accesibilidad heredado pueden optar por el uso de características de accesibilidad heredadas estableciendo explícitamente este modificador de AppContext en true
.
uso de colores definidos por el sistema operativo en 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 texto y fondo no contrastaban y eran difíciles de leer.
- Los controles contenidos en un GroupBox que tiene su propiedad Enabled establecida en
false
ahora usarán colores definidos por el sistema operativo en el tema de alto contraste. - Los controles ToolStripButton, ToolStripComboBoxy ToolStripDropDownButton tienen una mayor relación de contraste de luminosidad en modo de contraste alto.
- DataGridViewLinkCell usará de forma predeterminada los colores definidos por el sistema operativo en modo de alto contraste para la propiedad DataGridViewLinkCell.LinkColor. NOTA: Windows 10 ha cambiado los valores de algunos colores del sistema de contraste alto. Windows Forms Framework se basa en el marco Win32. Para obtener la mejor experiencia, ejecute en la versión más reciente de Windows y opte por los cambios más recientes del sistema operativo agregando un archivo app.manifest en una aplicación de prueba y anulando los comentarios del código siguiente:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
Mejora en el soporte para el 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
- Las filas de un DataGridView ahora se pueden ordenar mediante el teclado. Ahora un usuario puede usar la clave F3 para ordenar por la columna actual.
- Cuando DataGridView.SelectionMode se establece en DataGridViewSelectionMode.FullRowSelect, el color del encabezado de la columna cambiará para indicar la columna actual a medida que el usuario navega a través de las celdas de la fila actual.
- Ahora la propiedad DataGridViewCell.DataGridViewCellAccessibleObject.Parent devuelve el control primario correcto.
Mejoras en indicaciones visuales
- Los controles RadioButton y CheckBox con una propiedad Text vacía ahora mostrarán un indicador de foco cuando reciban el foco.
Compatibilidad con la cuadrícula de propiedades mejorada
Los elementos secundarios de control PropertyGrid ahora devuelven un
true
para la propiedad IsReadOnlyProperty únicamente cuando se habilita un elemento PropertyGrid.Los elementos secundarios de control PropertyGrid ahora devuelven un
Navegación mejorada con tecladofalse
para la propiedad IsEnabledProperty solo cuando el usuario puede cambiar un elemento PropertyGrid. Para obtener información general sobre la automatización de la interfaz de usuario, consulte la sección Introducción a la Automatización de la Interfaz de Usuario.ToolStripButton ahora permite centrar el foco cuando está contenido en un ToolStripPanel con la propiedad TabStop configurada en
true
.
Nombre | Valor |
---|---|
Alcance | Principal |
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, debe ejecutarse en .NET Framework 4.7.2 o posterior. La aplicación puede beneficiarse de estos cambios de cualquiera de las maneras siguientes:
- Tiene como destino .NET Framework 4.7.2. Este cambio está habilitado de forma predeterminada en las aplicaciones de Windows Forms que tienen como destino .NET Framework 4.7.2 o posterior.
- Tiene como destino .NET Framework 4.7.1 o una versión anterior y opta por no participar en los comportamientos de accesibilidad heredados agregando el siguiente modificador de AppContext a la sección
<runtime>
del archivo app.config y establézándola enfalse
, como se muestra en el ejemplo siguiente.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue=false"/>
</runtime>
Las aplicaciones que tienen como destino .NET Framework 4.7.2 o posterior, y que desean conservar el comportamiento heredado pueden optar por usar el valor de control de código fuente heredado estableciendo explícitamente este modificador de AppContext en true
.
Nombre | Valor |
---|---|
Alcance | perimetral |
Versión | 4.7.2 |
Tipo | Redestinación |
Las API afectadas
El método PrivateFontCollection.AddFontFile libera los recursos de fuente.
Detalles
En el .NET Framework 4.7.1 y versiones anteriores, la clase System.Drawing.Text.PrivateFontCollection no libera los recursos de fuente GDI+ después de que el PrivateFontCollection sea descartado para los objetos Font que se agregan a esta colección utilizando 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, debe ejecutarse en .NET Framework 4.7.2 o posterior. La aplicación puede beneficiarse de estos cambios de cualquiera de las maneras siguientes:
- Se vuelve a compilar para tener como destino .NET Framework 4.7.2. Este cambio está habilitado de forma predeterminada en las aplicaciones de Windows Forms que tienen como destino .NET Framework 4.7.2 o posterior.
- Tiene como destino .NET Framework 4.7.1 o una versión anterior y opta por no participar en los comportamientos de accesibilidad heredados agregando el siguiente modificador de AppContext a la sección
<runtime>
del archivo app.config y establézándola enfalse
, como se muestra en el ejemplo siguiente.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Drawing.Text.DoNotRemoveGdiFontsResourcesFromFontCollection=false"/>
</runtime>
Las aplicaciones que tienen como destino .NET Framework 4.7.2 o posterior, y que desean conservar el comportamiento heredado pueden optar por no liberar recursos de fuente estableciendo explícitamente este modificador de AppContext en true
.
Nombre | Valor |
---|---|
Alcance | perimetral |
Versión | 4.7.2 |
Tipo | Redestinación |
APIs afectadas
Las acciones de los botones de subir y bajar del dominio de WinForm están sincronizadas ahora.
Detalles
En .NET Framework 4.7.1 y versiones anteriores, la acción DomainUpDown.UpButton() del control DomainUpDown se omite cuando hay texto presente en el control, y el desarrollador debe realizar 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 forma independiente en este escenario y permanecen sincronizadas.
Sugerencia
Para que una aplicación se beneficie de estos cambios, debe ejecutarse en .NET Framework 4.7.2 o posterior. La aplicación puede beneficiarse de estos cambios de cualquiera de las maneras siguientes:
- Se vuelve a compilar para tener como destino .NET Framework 4.7.2. Este cambio está habilitado de forma predeterminada en las aplicaciones de Windows Forms que tienen como destino .NET Framework 4.7.2 o posterior.
- Descarta el comportamiento de desplazamiento heredado agregando el siguiente AppContext Switch a la sección
<runtime>
del archivo de configuración de la aplicación y configurándola enfalse
, como se muestra en el siguiente ejemplo.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling=false"/>
</runtime>
Nombre | Valor |
---|---|
Alcance | perimetral |
Versión | 4.7.2 |
Tipo | Redestinación |
APIs afectadas
Windows Presentation Foundation (WPF)
El foco del teclado ahora se mueve correctamente entre varias capas de hospedaje de WinForms/WPF
Detalles
Considere la posibilidad de que una aplicación WPF hospede un control WinForms que, a su vez, hospeda controles WPF. Es posible que los usuarios no puedan saltar fuera de la capa de WinForms si el primer o el último control de esa capa es el WPF System.Windows.Forms.Integration.ElementHost
. Este cambio corrige este problema, y los usuarios ahora pueden salir de la capa de WinForms utilizando la tecla de tabulación. Es posible que las aplicaciones automatizadas que dependen de que el foco no salga nunca de la capa de WinForms ya no funcionen como se esperaba.
Sugerencia
Un desarrollador que quiera usar este cambio mientras tiene como destino una versión de marco inferior a .NET 4.7.2 puede establecer el siguiente conjunto de marcas de AppContext en false para que el cambio se habilite.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false"/>
</runtime>
</configuration>
Las aplicaciones WPF deben participar en todas las mejoras tempranas de accesibilidad para obtener las mejoras posteriores. 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 |
---|---|
Alcance | perimetral |
Versión | 4.7.2 |
Tipo | Redestinación |
El algoritmo hash predeterminado para el compilador de marcado de WPF ahora es SHA256.
Detalles
El markupCompiler de WPF proporciona servicios de compilación para archivos de marcado XAML. En .NET Framework 4.7.1 y versiones anteriores, el algoritmo hash predeterminado usado para las sumas de comprobación era SHA1. Debido a problemas 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 toda la generación de checksum para los archivos de marcado durante la compilación.
Sugerencia
Un desarrollador que tenga como destino .NET Framework 4.7.2 o superior y que quiera revertir al comportamiento de hash SHA1 debe establecer la siguiente marca appContext.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=true"/>
</runtime>
</configuration>
Un desarrollador que quiera usar el hash SHA256 mientras tiene como destino una versión de marco inferior a .NET 4.7.2 debe establecer la marca 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 |
---|---|
Alcance | 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 puede crear un System.Windows.Threading.Dispatcher en el subproceso de 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. Debido a esto, WPF puede llamar a Dispatcher.Invoke para completar el proceso de limpieza. En determinadas aplicaciones, este cambio en el tiempo del finalizador puede provocar excepciones durante el apagado de AppDomain o del proceso. 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 ayudar a aliviar (pero no eliminar) problemas de tiempo que pueden producirse debido al cambio de limpieza. Para deshabilitar el cambio en la limpieza, use la siguiente marca appContext.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotInvokeInWeakEventTableShutdownListener=true"/>
</runtime>
</configuration>
Nombre | Valor |
---|---|
Alcance | perimetral |
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
Supongamos que tiene una colección ADO de elementos de tipo Order
, con una relación denominada "OrderDetails" relacionada con una colección de elementos de tipo Detail
a través de la clave principal "OrderID". En la 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 surge cuando se cambia la clave principal OrderID
del elemento maestro. ADO cambia automáticamente el OrderID
de cada uno de los registros afectados de la colección Details (es decir, los copiados en la colección D). ¿Pero qué pasa 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 sigue usando la colección D, que ahora está vacía. - Nuevo comportamiento: la colección D no cambia. Cada uno de sus elementos genera una notificación de cambio para la propiedad
OrderID
. ListBox sigue usando la colección D y muestra los detalles con el nuevoOrderID
. WPF implementa el nuevo comportamiento creando la colección D de otra manera: llamando al método ADO DataRowView.CreateChildView(DataRelation, Boolean) con el argumentofollowParent
establecido entrue
.
Sugerencia
Una aplicación obtiene el nuevo comportamiento mediante el siguiente modificador AppContext.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Data.DoNotUseFollowParentWhenBindingToADODataRelation=false"/>
</runtime>
</configuration>
El modificador tiene como valor predeterminado true
(comportamiento anterior) para las aplicaciones que tienen como destino .NET 4.7.1 o inferior, y para false
(nuevo comportamiento) para las aplicaciones que tienen como destino .NET 4.7.2 o superior.
Nombre | Valor |
---|---|
Alcance | Secundaria |
Versión | 4.7.2 |
Tipo | Reorientación de anuncios |
FocusVisual de WPF para los controles RadioButton y CheckBox ahora se muestra correctamente cuando 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 los controles no tienen ningún conjunto de contenido. Esto puede hacer que la transición entre temas sea confusa y que el elemento visual de enfoque sea difícil de ver. En .NET Framework 4.7.2, estos objetos visuales ahora son más coherentes entre temas y más fácilmente visibles en temas clásicos y de contraste alto.
Sugerencia
Un desarrollador que trabaja con .NET Framework 4.7.2 y que quiera revertir al comportamiento de .NET 4.7.1 deberá establecer la siguiente marca AppContext.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true;"/>
</runtime>
</configuration>
Un desarrollador que quiera usar este cambio mientras tiene como destino una versión de marco inferior a .NET 4.7.2 debe establecer las siguientes marcas de AppContext. Tenga en cuenta que todas las marcas deben establecerse correctamente y la versión instalada de .NET Framework debe ser 4.7.2 o superior. Las aplicaciones wpF deben participar en todas las mejoras de accesibilidad anteriores para obtener las mejoras más recientes. Para ello, asegúrese de que tanto los conmutadores AppContext "Switch.UseLegacyAccessibilityFeatures" como "Switch.UseLegacyAccessibilityFeatures.2" estén establecidos en false.
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;"/>
</runtime>
</configuration>
Nombre | Valor |
---|---|
Alcance | perimetral |
Versión | 4.7.2 |
Tipo | Redestinación |
La selección de texto textBox/PasswordBox de WPF no sigue los colores del sistema
Detalles
En .NET Framework 4.7.1 y versiones anteriores, WPF System.Windows.Controls.TextBox
y System.Windows.Controls.PasswordBox
solo podían representar una selección de texto en la capa Adorner. En algunos temas del sistema, esto ocluía texto, lo que dificultaba la lectura. En .NET Framework 4.7.2 y versiones posteriores, los desarrolladores tienen la opción de habilitar un esquema de representación de selección no basado en Adorner que solucione este problema.
Sugerencia
Un desarrollador que quiera usar este cambio debe establecer la siguiente marca appContext adecuadamente. 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 |
---|---|
Alcance | perimetral |
Versión | 4.7.2 |
Tipo | Redestinación |
Windows Workflow Foundation (WF)
Evitar la recursividad infinita 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 de flujo de trabajo está en un estado en el que está esperando que se complete otra solicitud 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
. Dado que la instancia del servicio de flujo de trabajo está ocupada esperando a que se complete la otra solicitud WCF pendiente, el elemento de trabajo creado permanece en cola. La operación de 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 la instancia de flujo de trabajo persista. 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 esta appSetting es false
, por lo que las instancias de 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 no enfrenta el problema, no es necesario hacerlo.
Nombre | Valor |
---|---|
Alcance | perimetral |
Versión | 4.7.2 |
Tipo | Redestinación |