Redirecionar alterações para migração para o .NET Framework 4.7.x

Este artigo lista os problemas de compatibilidade de aplicativo que foram introduzidos no .NET Framework 4.7, 4.7.1 e 4.7.2.

.NET Framework 4.7

ASP.NET

HttpRuntime.AppDomainAppPath gera NullReferenceException

Detalhes

No .NET Framework 4.6.2, o runtime gera T:System.NullReferenceException ao recuperar um valor P:System.Web.HttpRuntime.AppDomainAppPath que inclui caracteres nulos. No .NET Framework 4.6.1 e versões anteriores, o runtime gera T:System.ArgumentNullException.

Sugestão

Você pode fazer o seguinte para responder a essa alteração:

• Identifique o T:System.NullReferenceException se o aplicativo estiver sendo executado no .NET Framework 4.6.2.
• Atualize para o .NET Framework 4.7, que restaura o comportamento anterior e gera T:System.ArgumentNullException.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Redirecionando

APIs afetadas

• HttpRuntime.AppDomainAppPath

Limitação de solicitações simultâneas por sessão

Detalhes

No .NET Framework 4.6.2 e versões anteriores, o ASP.NET executa solicitações com a mesma Sessionid sequencialmente e sempre emite a Sessionid por meio de um cookie por padrão. Se uma página levar muito tempo para responder, pressionar F5 no navegador prejudicará significativamente o desempenho do servidor. Na correção, adicionou-se um contador que acompanha as solicitações enfileiradas e encerra as solicitações quando elas excedem um limite especificado. O valor padrão é 50. Se o limite for alcançado, um aviso será registrado no log de eventos e uma resposta HTTP 500 poderá ser registrada no log do IIS.

Sugestão

Para restaurar o comportamento antigo, você pode adicionar a seguinte configuração ao arquivo web.config para recusar o novo comportamento.

<appSettings>
    <add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7
Tipo	Redirecionando

Rede

O valor padrão de ServicePointManager.SecurityProtocol é SecurityProtocolType.System.Default

Detalhes

A partir dos aplicativos destinados ao .NET Framework 4.7, o valor padrão da propriedade ServicePointManager.SecurityProtocol é SecurityProtocolType.SystemDefault. Essa alteração permite que APIs de rede do .NET Framework baseadas em SslStream (como FTP, HTTPS e SMTP) herdem os protocolos de segurança padrão do sistema operacional em vez de usar valores embutidos em código definidos pelo .NET Framework. O padrão varia de acordo com o sistema operacional e qualquer configuração personalizada executada pelo administrador do sistema. Para obter informações sobre o protocolo SChannel padrão em cada versão do sistema operacional Windows, confira Protocols in TLS/SSL (Schannel SSP) [Protocolos em TLS/SSL (Schannel SSP)].

Para aplicativos direcionados a uma versão anterior do .NET Framework, o valor padrão da propriedade ServicePointManager.SecurityProtocol depende da versão do .NET Framework de destino. Consulte a seção de Rede das Alterações de redirecionamento para a migração do .NET Framework 4.5.2 para 4.6 para obter mais informações.

Sugestão

Esta alteração afeta aplicativos direcionados ao .NET Framework 4.7 ou a versões posteriores. Se você preferir usar um protocolo definido em vez de contar com o padrão do sistema, defina explicitamente o valor da propriedade ServicePointManager.SecurityProtocol. Se você não quiser essa alteração, recuse-a adicionando uma definição de configuração à seção <runtime> do arquivo de configuração de aplicativo. O exemplo a seguir mostra a seção <runtime> e a opção de recusa Switch.System.Net.DontEnableSystemDefaultTlsVersions:

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

Nome	Valor
Escopo	Secundária
Versão	4.7
Tipo	Redirecionando

APIs afetadas

• ServicePointManager.SecurityProtocol

SslStream dá suporte a Alertas de TLS

Detalhes

Após um handshake de TLS com falha, um System.IO.IOException com uma exceção System.ComponentModel.Win32Exception interna será lançado pela primeira operação de Leitura/Gravação de E/S. O código System.ComponentModel.Win32Exception.NativeErrorCode do System.ComponentModel.Win32Exception pode ser mapeado para o Alerta TLS da parte remota com o uso de códigos de erro do Schannel para alertas TLS e SSL. Para saber mais, confira RFC 2246: Seção 7.2.2, Alertas de erro.
O comportamento no .NET Framework 4.6.2 e nas versões anteriores é que o canal de transporte (normalmente a conexão TCP) atingirá o tempo limite durante a gravação ou a leitura se a outra parte falhar no handshake e rejeitar a conexão logo depois.

Sugestão

Os aplicativos que chamam APIs de E/S de rede, como Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32), devem tratar IOException ou System.TimeoutException.
O recurso de Alertas TLS é habilitado por padrão, começando com o .NET Framework 4.7. Os aplicativos direcionados às versões 4.0 a 4.6.2 do .NET Framework em execução no .NET Framework 4.7 ou em um sistema superior terão o recurso desabilitado para preservar a compatibilidade.
A API de configuração a seguir está disponível para habilitar ou desabilitar o recurso para os aplicativos do .NET Framework 4.6 e posteriores em execução no .NET Framework 4.7 ou posterior.

• Por meio de programação: precisa ser a primeira ação do aplicativo, pois o ServicePointManager é inicializado apenas uma 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>
  

• Chave do Registro (global do computador): defina o valor como false para habilitar o recurso no .NET Framework 4.6 a 4.6.2.

  Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
  - Type: String
  - Value: "true"
  

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7
Tipo	Redirecionando

APIs afetadas

• System.Net.Security.SslStream
• System.Net.WebRequest
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest
• System.Net.Mail.SmtpClient
• System.Net.Http

Segurança

CspParameters.ParentWindowHandle agora espera o valor HWND

Detalhes

O valor ParentWindowHandle, introduzido no .NET Framework 2.0, permite que um aplicativo registre um valor de identificador de janela pai, de modo que qualquer interface do usuário necessária para acessar a chave (por exemplo, uma caixa de diálogo de solicitação de PIN ou de consentimento) seja aberta como um filho modal para a janela especificada. A partir dos aplicativos destinados ao .NET Framework 4.7, um aplicativo do Windows Forms pode definir a propriedade ParentWindowHandle com código como o seguinte:

cspParameters.ParentWindowHandle = form.Handle;

Em versões anteriores do .NET Framework, esperava-se que o valor fosse um System.IntPtr representando um local na memória em que o valor de HWND residia. A definição da propriedade como form.Handle no Windows 7 e em versões anteriores não tinha nenhum efeito. No Windows 8 e em versões posteriores, isso resulta em "System.Security.Cryptography.CryptographicException: O parâmetro está incorreto."

Sugestão

Os aplicativos direcionados ao .NET Framework 4.7 ou posterior que desejam registrar um relacionamento de janela pai são incentivados a usar o formato simplificado:

cspParameters.ParentWindowHandle = form.Handle;

Usuários que identificaram que o valor correto a ser passado era o endereço de um local da memória que mantinha o valor de form.Handle podem recusar essa alteração de comportamento definindo o comutador AppContext Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle como true:

• Configurando de forma programática as opções de compatibilidade em AppContext, conforme explicado aqui.
• Adicionando a seguinte linha na seção <runtime> do arquivo app.config:

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

Por outro lado, usuários que quiserem aceitar o novo comportamento no runtime do .NET Framework 4.7 quando o aplicativo for carregado em versões anteriores do .NET Framework podem definir a opção de AppContext como false.

Nome	Valor
Escopo	Secundária
Versão	4.7
Tipo	Redirecionando

APIs afetadas

• CspParameters.ParentWindowHandle

SslStream dá suporte a Alertas de TLS

Detalhes

Após um handshake de TLS com falha, um System.IO.IOException com uma exceção System.ComponentModel.Win32Exception interna será lançado pela primeira operação de Leitura/Gravação de E/S. O código System.ComponentModel.Win32Exception.NativeErrorCode do System.ComponentModel.Win32Exception pode ser mapeado para o Alerta TLS da parte remota com o uso de códigos de erro do Schannel para alertas TLS e SSL. Para saber mais, confira RFC 2246: Seção 7.2.2, Alertas de erro.
O comportamento no .NET Framework 4.6.2 e nas versões anteriores é que o canal de transporte (normalmente a conexão TCP) atingirá o tempo limite durante a gravação ou a leitura se a outra parte falhar no handshake e rejeitar a conexão logo depois.

Sugestão

Os aplicativos que chamam APIs de E/S de rede, como Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32), devem tratar IOException ou System.TimeoutException.
O recurso de Alertas TLS é habilitado por padrão, começando com o .NET Framework 4.7. Os aplicativos direcionados às versões 4.0 a 4.6.2 do .NET Framework em execução no .NET Framework 4.7 ou em um sistema superior terão o recurso desabilitado para preservar a compatibilidade.
A API de configuração a seguir está disponível para habilitar ou desabilitar o recurso para os aplicativos do .NET Framework 4.6 e posteriores em execução no .NET Framework 4.7 ou posterior.

• Por meio de programação: precisa ser a primeira ação do aplicativo, pois o ServicePointManager é inicializado apenas uma 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>
  

• Chave do Registro (global do computador): defina o valor como false para habilitar o recurso no .NET Framework 4.6 a 4.6.2.

  Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
  - Type: String
  - Value: "true"
  

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7
Tipo	Redirecionando

APIs afetadas

• System.Net.Security.SslStream
• System.Net.WebRequest
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest
• System.Net.Mail.SmtpClient
• System.Net.Http

Windows Communication Foundation (WCF)

Serialização de caracteres de controle com DataContractJsonSerializer agora é compatível com ECMAScript V6 e V8

Detalhes

No .NET framework 4.6.2 e versões anteriores, System.Runtime.Serialization.Json.DataContractJsonSerializer não serializava alguns caracteres de controle especiais, como \b, \f e \t, de maneira compatível com os padrões ECMAScript V6 e V8. A partir do .NET Framework 4.7, a serialização desses caracteres de controle é compatível com o ECMAScript V6 e V8.

Sugestão

Por padrão, esse novo layout é habilitado para aplicativos que se destinam ao .NET Framework 4.7. Se esse comportamento não for desejado, você poderá recusar esse recurso adicionando a seguinte linha na seção <runtime> do arquivo app.config ou web.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7
Tipo	Redirecionando

APIs afetadas

• DataContractJsonSerializer.WriteObject(Stream, Object)
• DataContractJsonSerializer.WriteObject(XmlDictionaryWriter, Object)
• DataContractJsonSerializer.WriteObject(XmlWriter, Object)

A segurança de mensagens do WCF agora pode usar o TLS1.1 e o TLS1.2

Detalhes

A partir do .NET Framework 4.7, os clientes podem configurar o TLS1.1 ou o TLS1.2 na segurança de mensagens do WCF, além do SSL3.0 e o TLS1.0, por meio das configurações do aplicativo.

Sugestão

No .NET Framework 4.7, a compatibilidade com o TLS1.1 e o TLS1.2 na segurança de mensagens do WCF é desabilitada por padrão. É possível habilitá-la adicionando a seguinte linha à seção <runtime> do arquivo web.config:

<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7
Tipo	Redirecionando

Windows Presentation Foundation (WPF)

Chamadas para System.Windows.Input.PenContext.Disable em sistemas habilitados para toque podem gerar ArgumentException

Detalhes

Em algumas circunstâncias, chamadas para o método interno System.Windows.Intput.PenContext.Disable em sistemas habilitados para toque podem gerar uma T:System.ArgumentException sem tratamento devido à reentrância.

Sugestão

Esse problema foi resolvido no .NET Framework 4.7. Para evitar a exceção, atualize para uma versão do .NET Framework a partir de 4.7.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.1
Tipo	Redirecionando

NullReferenceException no código de tratamento de exceções de ImageSourceConverter.ConvertFrom

Detalhes

Um erro no código de manipulação de exceções para ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) fez um System.NullReferenceException incorreto ser gerado, em vez da exceção pretendida (System.IO.DirectoryNotFoundException ou System.IO.FileNotFoundException). Essa alteração corrige esse erro, de modo que o método agora gera a exceção certa.

Por padrão todos os aplicativos direcionados ao .NET Framework 4.6.2 e anteriores continuam a gerar System.NullReferenceException para manter a compatibilidade. Os desenvolvedores que direcionarem ao .NET Framework 4.7 e superiores, observação as exceções certas.

Sugestão

Os desenvolvedores que desejam reverter para receber System.NullReferenceException quando tiverem o .NET Framework 4.7 ou mais recentes como destino podem adicionar/mesclar o seguinte ao arquivo App.config do aplicativo:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7
Tipo	Redirecionando

APIs afetadas

• ImageSourceConverter.ConvertFrom(ITypeDescriptorContext, CultureInfo, Object)

Alocação de espaço para colunas com estrela em Grades do WPF

Detalhes

A partir do .NET Framework 4.7, o WPF substitui o algoritmo que usa Grid para alocar espaço para *-colunas. Isso altera a largura real atribuída a colunas com * em diversos casos:

• Quando uma ou mais *-colunas também têm uma largura mínima ou máxima que substitui a alocação proporcional para essa coluna. (A largura mínima pode derivar de uma declaração MinWidth explícita ou de um mínimo implícito obtido do conteúdo da coluna. A largura máxima só pode ser definida explicitamente de uma declaração MaxWidth.)
• Quando uma ou mais colunas com * declaram um peso de * extremamente grande, maior que 10^298.
• Quando os pesos de * são diferentes o suficiente para encontrar instabilidade de ponto flutuante (estouro, estouro negativo, perda de precisão).
• Quando o arredondamento de layout está habilitado e o DPI de exibição efetivo é suficientemente alto. Nos dois primeiros casos, as larguras produzidas pelo novo algoritmo podem ser significativamente diferentes das produzidas pelo algoritmo antigo. No último caso, a diferença será no máximo um ou dois pixels.

O novo algoritmo corrige vários bugs presentes no algoritmo antigo:

• A alocação total de colunas pode exceder a largura da grade. Isso pode ocorrer ao alocar espaço para uma coluna cujo compartilhamento proporcional seja menor que seu tamanho mínimo. O algoritmo aloca o tamanho mínimo, o que reduz o espaço disponível para outras colunas. Se não houver nenhuma coluna de * restante para alocar, a alocação total será muito grande.

• A alocação total pode ser menor que a largura da grade. Esse é o problema duplo do n° 1, que surge ao alocar para uma coluna cujo compartilhamento proporcional é maior do que seu tamanho máximo, sem nenhuma coluna com * restante para concluir o processo.

• Duas colunas com * podem receber alocações que não sejam proporcionais a seus pesos. Esta é uma versão atenuada da n° 1 e da n° 2, que surge ao alocar para colunas de * A, B e C (nessa ordem), quando o compartilhamento proporcional de B viola sua restrição mínima (ou máxima). Como acima, isso altera o espaço disponível para a coluna C, que obtém uma alocação proporcional menor (ou maior) que a de A.

• As colunas com pesos muito grandes (> 10^298) são tratadas como se tivessem o peso 10^298. Não são consideradas as diferenças proporcionais entre elas (e entre colunas com pesos um pouco menores).

• As colunas com pesos infinitos não são tratadas corretamente. (Na verdade, você não pode definir um peso como Infinito, mas essa é uma restrição artificial. O código de alocação estava tentando lidar com isso, mas estava fazendo um trabalho ruim.)

• Vários problemas secundários, evitando estouro, subfluxo, perda de precisão e problemas semelhantes de ponto flutuante.

• Os ajustes de arredondamento de layout são incorretos em um DPI suficientemente alto. O novo algoritmo produz resultados que atendam aos seguintes critérios:

  • A largura real atribuída a uma coluna de * nunca é menor que sua largura mínima nem maior que sua largura máxima.
  • A cada *-coluna que não tiver sua largura mínima ou máxima atribuída, será atribuída uma largura proporcional ao seu *-peso. Para ser mais preciso, se duas colunas forem declaradas com largura x* e y*, respectivamente e se nenhuma coluna receber sua largura mínima ou máxima, as larguras reais v e w atribuídas às colunas estarão na mesma proporção: v / w == x / y.
  • A largura total alocada para colunas * "proporcionais" é igual ao espaço disponível após a alocação para as colunas restritas (colunas *, fixas e automáticas com a largura mínima ou máxima alocada). Isso pode ser zero, por exemplo se a soma das larguras mínimas excede a largura disponível da grade.
  • Todas essas instruções devem ser interpretadas em relação ao layout "ideal". Quando o arredondamento de layout está em vigor, as larguras reais podem diferir das larguras ideais em até um pixel.

Observação

Tudo o que foi dito sobre colunas e larguras neste artigo também se aplica a linhas e alturas.

Sugestão

Por padrão, os aplicativos direcionados a versões do .NET Framework começando com o .NET Framework 4.7 usarão o novo algoritmo, enquanto os aplicativos direcionados ao .NET Framework 4.6.2 ou a versões anteriores usarão o algoritmo antigo.

Para substituir o padrão, use a seguinte definição de configuração:

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

O valor true seleciona o algoritmo antigo, false seleciona o novo algoritmo.

Nome	Valor
Escopo	Secundária
Versão	4.7
Tipo	Redirecionando

Pilha de toque baseada em ponteiro do WPF

Detalhes

Essa alteração possibilita habilitar uma pilha de toque/caneta do WPF baseada em WM_POINTER opcional. Desenvolvedores que não habilitarem explicitamente essa opção não deverão ver alterações no comportamento de toque/caneta do WPF. Problemas conhecidos atuais com a pilha de toque/caneta baseada em WM_POINTER opcional:

• Não há suporte para escrita à tinta em tempo real.
• Embora os plug-ins de caneta e escrita à tinta ainda funcionem, eles serão processados no thread da interface do usuário, o que pode levar a um desempenho ruim.
• Alterações de comportamento devido a alterações na promoção de eventos de toque/caneta para eventos de mouse.
• A manipulação pode se comportar de maneira diferente
• Arrastar/soltar não mostrará comentários apropriados para entrada por toque
• Isso não afeta entrada de caneta
• Arrastar/soltar não pode mais ser iniciado em eventos de toque/caneta
• Isso pode fazer com que o aplicativo pare de responder até que a entrada do mouse seja detectada.
• Em vez disso, os desenvolvedores devem iniciar a ação de arrastar e soltar usando eventos de mouse.

Sugestão

Desenvolvedores que desejam habilitar essa pilha podem adicionar/mesclar o seguinte ao arquivo app.config do aplicativo:

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

Remover isso ou definir o valor como false desabilita essa pilha opcional. Observe que essa pilha está disponível somente na Atualização do Windows 10 para Criadores e superiores.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7
Tipo	Redirecionando

Windows Workflow Foundation (WF)

Somas de verificação de fluxo de trabalho alteradas de MD5 para SHA1

Detalhes

Para compatibilidade com a depuração com o Visual Studio, o runtime de fluxo de trabalho gera uma soma de verificação para uma instância de fluxo de trabalho usando um algoritmo de hash. No .NET Framework 4.6.2 e versões anteriores, o hash de soma de verificação do fluxo de trabalho usava o algoritmo MD5, o que causou problemas em sistemas habilitados para FIPS. A partir do .NET Framework 4.7, o algoritmo será o SHA1. Se o código persistir a essas somas de verificação, eles serão incompatíveis.

Sugestão

Se o código não conseguir carregar instâncias de fluxo de trabalho devido a uma falha na soma de verificação, tente configurar a opção AppContext"Switch.System.Activities.UseMD5ForWFDebugger" como true. No código:

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

Ou em nossa configuração:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
  </runtime>
</configuration>

Nome	Valor
Escopo	Secundária
Versão	4.7
Tipo	Redirecionando

.NET Framework 4.7.1

ASP.NET

Melhorias de acessibilidade do ASP.NET no .NET Framework 4.7.1

Detalhes

A partir do .NET Framework 4.7.1, o ASP.NET melhorou o funcionamento dos controles da Web ASP.NET com a tecnologia de acessibilidade no Visual Studio para dar melhor suporte a clientes do ASP.NET. Isso inclui as seguintes alterações:

• Alterações para implementar padrões de acessibilidade de interface do usuário ausentes nos controles, como a caixa de diálogo Adicionar Campo no assistente de Exibição de Detalhes ou a caixa de diálogo Configurar ListView do assistente ListView.
• Alterações para melhorar a exibição no modo de Alto Contraste, como o Editor de Campos do Pager de Dados.
• Alterações para melhorar as experiências de navegação por teclado para controles como a caixa de diálogo Campos no assistente Editar Campos do Pager do controle DataPager, a caixa de diálogo Configurar ObjectContext ou a caixa de diálogo Configurar Seleção de Dados do assistente Configurar Fonte de Dados.

Sugestão

Como aceitar ou recusar essas alterações Para se beneficiar dessas alterações, o Designer do Visual Studio deverá ser executado no .NET Framework 4.7.1 ou posterior. O aplicativo Web pode se beneficiar dessas alterações de uma das seguintes maneiras:

• Instalar o Visual Studio 2017 15.3 ou posterior, que dá suporte a novas funcionalidades de acessibilidade com a seguinte opção de AppContext por padrão.
• Recusar os comportamentos de acessibilidade herdados adicionando a opção de AppContext Switch.UseLegacyAccessibilityFeatures à seção <runtime> do arquivo devenv.exe.config e configurando-a como false, como mostra o exemplo a seguir.

<?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>

Aplicativos destinados ao .NET Framework 4.7.1 ou posterior que desejam preservar o comportamento de acessibilidade herdado pode aceitar o uso das funcionalidades de acessibilidade herdadas definindo explicitamente essa opção de AppContext como true.

Nome	Valor
Escopo	Secundária
Versão	4.7.1
Tipo	Redirecionando

Núcleo

Exceções de thread de tela de fundo de SerialPort

Detalhes

Threads em segundo plano criados com fluxos SerialPort não terminam o processo quando são geradas exceções do sistema operacional.
Em aplicativos direcionados ao .NET Framework 4.7 e a versões anteriores, um processo é terminado quando uma exceção do sistema operacional é gerada em um thread em segundo plano criado com um fluxo SerialPort.
Nos aplicativos direcionados ao .NET Framework 4.7.1 e a versões anteriores, os threads em segundo plano esperam pelos eventos do SO relacionados à porta serial ativa e podem falhar em alguns casos, como uma remoção repentina da porta serial.

Sugestão

Para aplicativos destinados ao .NET Framework 4.7.1, será possível recusar a manipulação de exceções se ela não for desejável adicionando o seguinte à seção <runtime> do arquivo app.config:

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

Para aplicativos destinados a versões anteriores do .NET Framework mas executados no .NET Framework 4.7.1 ou posterior, é possível aceitar a manipulação de exceções adicionando o seguinte à seção <runtime> do arquivo app.config:

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

Nome	Valor
Escopo	Secundária
Versão	4.7.1
Tipo	Redirecionando

APIs afetadas

• System.IO.Ports.SerialPort

ServiceBase não propaga exceções de OnStart

Detalhes

No .NET Framework 4.7 e nas versões anteriores, as exceções geradas durante a inicialização do serviço não são propagadas para o chamador de ServiceBase.Run.

Começando com os aplicativos direcionados ao .NET Framework 4.7.1, o runtime propaga exceções para ServiceBase.Run de serviços que falham ao iniciar.

Sugestão

Na inicialização do serviço, se houver uma exceção, essa exceção será propagada. Isso deve ajudar a diagnosticar casos em que os serviços falham ao iniciar.

Se esse comportamento não for desejado, você poderá recusá-lo, adicionando o seguinte elemento AppContextSwitchOverrides à seção runtime do arquivo de configuração de aplicativo:

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

Se seu aplicativo for destinado a uma versão anterior à 4.7.1, mas você desejar ter esse comportamento, adicione o seguinte elemento AppContextSwitchOverrides à seção runtime do arquivo de configuração de aplicativo:

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

Nome	Valor
Escopo	Secundária
Versão	4.7.1
Tipo	Redirecionando

APIs afetadas

• ServiceBase.Run(ServiceBase)
• ServiceBase.Run(ServiceBase[])

Segurança

Algoritmos SignedXML e SignedXMS padrão alterados para SHA256

Detalhes

No .NET Framework 4.7 e anteriores, SignedXML e SignedCMS usam SHA1 como padrão para algumas operações. A partir do .NET Framework 4.7.1, SHA256 é habilitado por padrão para essas operações. Essa alteração é necessária porque SHA1 não é mais considerado seguro.

Sugestão

Há dois novos valores de alternância de contexto para controlar se SHA1 (inseguro) ou SHA256 é usado por padrão:

• Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms
• Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms Para os aplicativos destinados ao .NET Framework 4.7.1 e versões posteriores, se o uso do SHA256 for indesejável, restaure o padrão para o SHA1 adicionando a seguinte opção de configuração à seção runtime do arquivo de configuração de aplicativo:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=true;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=true" />

Para aplicativos destinados ao .NET Framework 4.7 e a versões anteriores, é possível aceitar essa alteração adicionando a seguinte opção de configuração à seção do runtime do arquivo de configuração de seu aplicativo:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />

Nome	Valor
Escopo	Secundária
Versão	4.7.1
Tipo	Redirecionando

APIs afetadas

• System.Security.Cryptography.Pkcs.CmsSigner
• System.Security.Cryptography.Xml.SignedXml
• System.Security.Cryptography.Xml.Reference

SignedXml.GetPublicKey retorna RSACng em net462 (ou lightup) sem redirecionar a alteração

Detalhes

A partir do .NET Framework 4.6.2, o tipo concreto de objeto retornado pelo método SignedXml.GetPublicKey foi alterado (sem um quirk) de uma implementação de CryptoServiceProvider para uma implementação de Cng. Isso ocorreu porque a implementação foi alterada: do uso de certificate.PublicKey.Key para o uso do certificate.GetAnyPublicKey interno, que encaminha para RSACertificateExtensions.GetRSAPublicKey.

Sugestão

Começando com aplicativos em execução no .NET Framework 4.7.1, é possível usar a implementação de CryptoServiceProvider usada por padrão no .NET Framework 4.6.1 e versões anteriores adicionando a seguinte opção de configuração à seção runtime do arquivo de configuração do aplicativo:

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Redirecionando

APIs afetadas

• SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm)

Windows Communication Foundation (WCF)

Acessibilidade aprimorada para algumas ferramentas do SDK do .NET

Detalhes

No SDK do .NET Framework 4.7.1, as ferramentas SvcConfigEditor.exe e SvcTraceViewer.exe foram melhoradas com a correção de vários problemas de acessibilidade. A maioria eram problemas pequenos como um nome que não está definido ou certos padrões de automação de interface do usuário implementados incorretamente. Embora muitos usuários não estejam cientes desses valores incorretos, os clientes que usam tecnologias adaptativas como leitores de tela considerarão estas ferramentas de SDK mais acessíveis. Certamente, essas correções alteram alguns comportamentos anteriores, como a ordem do foco do teclado. Para obter todas as correções de acessibilidade nessas ferramentas, é possível adicionar o seguinte ao arquivo app.config:

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.1
Tipo	Redirecionando

Windows Forms

Melhorias de acessibilidade em controles do Windows Forms

Detalhes

O Windows Forms está melhorando a forma como funciona com tecnologias de acessibilidade para dar um melhor suporte a seus clientes. Isso inclui as seguintes alterações começando com o .NET Framework 4.7.1:

• Alterações para melhorar a exibição durante o modo de Alto Contraste.
• Alterações para melhorar a experiência no pesquisador de propriedades. As melhorias no pesquisador de propriedades incluem:
• Melhor navegação de teclado por meio das várias janelas de seleção suspensa.
• Redução de paradas de tabulação desnecessárias.
• Melhor relatório de tipos de controle.
• Melhor comportamento do Narrador.
• Alterações para implementar padrões de acessibilidade de interface do usuário ausentes em controles.

Sugestão

Como aceitar ou recusar essas alterações Para que o aplicativo se beneficie dessas alterações, ele precisa ser executado no .NET Framework 4.7.1 ou posterior. O aplicativo pode se beneficiar dessas alterações de uma das seguintes maneiras:

• Ele é recompilado para ser destinado ao .NET Framework 4.7.1. Essas alterações de acessibilidade são habilitadas por padrão em aplicativos do Windows Forms destinados ao .NET Framework 4.7.1 ou posterior.
• Ele recusa os comportamentos de acessibilidade herdados adicionando a seguinte Opção de AppContext à seção <runtime> do arquivo app.config e configurando-a como false, como mostra o exemplo a seguir.

<?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>

Aplicativos destinados ao .NET Framework 4.7.1 ou posterior que desejam preservar o comportamento de acessibilidade herdado pode aceitar o uso das funcionalidades de acessibilidade herdadas definindo explicitamente essa opção de AppContext como true.

Para obter uma visão geral de automação da interface do usuário, confira a Visão geral de automação da interface do usuário.

Adicionado o suporte para padrões e propriedades de automação de interface do usuário

Os clientes de acessibilidade podem aproveitar as novas funcionalidades de acessibilidade do WinForms usando padrões de invocação comuns, descritos publicamente. Esses padrões não são específicos do WinForms. Por exemplo, clientes de acessibilidade podem chamar o método QueryInterface na interface IAccessible (MAAS) para obter uma interface IServiceProvider. Se essa interface estiver disponível, os clientes poderão usar seu método QueryService para solicitar uma interface IAccessibleEx. Para obter mais informações, consulte Usar IAccessibleEx de um cliente. Começando com o .NET Framework 4.7.1, IServiceProvider e IAccessibleEx (quando aplicáveis) estão disponíveis para objetos de acessibilidade do WinForms.

O .NET Framework 4.7.1 adiciona suporte aos seguintes padrões e propriedades de automação da interface do usuário:

• Os controles ToolStripSplitButton e ComboBox dão suporte ao Padrão expandir/recolher.

• O ToolStripMenuItem controle tem uma propriedade ControlType com valor ControlType.MenuItem.

• O controle ToolStripItem é compatível com a propriedade NameProperty e com o padrão expandir/recolher.

• O controle ToolStripDropDownItem dá suporte a AccessibleEvents indicando StateChange e NameChange quando a lista suspensa é expandida ou recolhida.

• O ToolStripDropDownButton controle tem uma propriedade ControlType com valor de ControlType.MenuItem.

• O controle DataGridViewCheckBoxCell permite o TogglePattern.

• Os controles NumericUpDown e DomainUpDown permitem a propriedade NameProperty e têm um ControlType igual a ControlType.Spinner.

  Aprimoramentos do controle de PropertyGrid O .NET Framework 4.7.1 adicionou os seguintes aprimoramentos ao controle de PropertyBrowser:

• O botão Detalhes na caixa de diálogo de erro exibida quando o usuário insere um valor incorreto no controle PropertyGrid dá suporte ao Padrão de expandir/recolher, notificações de alteração de estado e nome e uma propriedade ControlType com um valor de ControlType.MenuItem.

• O painel de mensagem exibido quando o botão Detalhes da caixa de diálogo de erro é expandido agora é acessível por teclado e permite que o Narrador anuncie o conteúdo da mensagem de erro.

• A AccessibleRole de linhas no controle PropertyGrid foi alterada de "Linha" para "Célula". A célula é mapeada para o ControlType "DataItem" da UIA, o que permite dar suporte aos atalhos de teclado apropriados e aos comunicados do narrador.

• As linhas do controle PropertyGrid que representam itens de cabeçalho quando o controle PropertyGrid tem uma propriedade PropertySort definida como PropertySort.Categorized têm uma propriedade ControlType com o valor ControlType.Button.

• As linhas do controle PropertyGrid que representam itens de cabeçalho quando o controle PropertyGrid tem uma propriedade PropertySort definida como PropertySort.Categorized dão suporte ao padrão Expandir/Recolher.

• Melhoria da navegação por teclado entre a grade e a barra de ferramentas acima dela. Se você pressionar "Shift-Tab" agora, o primeiro botão de barra de ferramentas será selecionado, em vez de toda a barra de ferramentas.

• Controles PropertyGrid exibidos no modo de Alto Contraste agora desenharão um retângulo de foco ao redor do botão da barra de ferramentas correspondente ao valor da propriedade PropertySort atual.

• Controles PropertyGrid exibidos no modo de Alto Contraste e com uma propriedade PropertySort definida como PropertySort.Categorized agora exibirão o segundo plano dos cabeçalhos de categoria em uma cor altamente contrastante.

• Controles PropertyGrid diferenciam melhor itens da barra de ferramentas com foco e itens da barra de ferramentas que indicam o valor atual da propriedade PropertySort. Essa correção consiste em uma alteração de Alto Contraste e em uma alteração para cenários que não são de Alto Contraste.

• Os itens de ToolBar do controle PropertyGrid que indicam o valor atual da propriedade PropertySort são compatíveis com o TogglePattern.

• Suporte aprimorado do Narrador para distinguir o alinhamento selecionado no Seletor de Alinhamento.

• Quando um controle PropertyGrid vazio é exibido em um formulário, agora ele recebe foco onde antes não receberia.

Uso de cores definidas pelo sistema operacional em temas de Alto Contraste

• Os controles Button e CheckBox com a propriedade FlatStyle definida como FlatStyle.System, que é o estilo padrão, agora usam cores definidas pelo SO no tema de Alto Contraste quando selecionado. Anteriormente, as cores de texto e de tela de fundo não eram contrastantes e eram difíceis de ler.
• Os controles Button, CheckBox, RadioButton, Label, LinkLabel e GroupBox com a propriedade Enabled definida como false usavam uma cor sombreada para renderizar o texto nos temas de Alto Contraste, resultando em pouco contraste em relação ao segundo plano. Agora esses controles usam a cor de "Texto Desabilitado" definida pelo sistema operacional. Essa correção aplica-se a controles com a propriedade FlatStyle definida com um valor diferente de FlatStyle.System. Os últimos controles são renderizados pelo sistema operacional.
• DataGridView agora renderiza um retângulo visível em torno do conteúdo da célula que tem o foco atual. Anteriormente, isso não era visível em certos temas de Alto Contraste.
• Os controles ToolStripMenuItem com uma propriedade Enabled definida como false agora usam a cor de "Texto Desabilitado" definida pelo sistema operacional.
• Os controles ToolStripMenuItem com a propriedade Checked definida como true agora renderizam a marca de seleção associada com uma cor do sistema contrastante. Antes, a cor da marca de seleção não era contrastante o suficiente e não era visível em temas de Alto Contraste. Observação: o Windows 10 mudou os valores de algumas cores do sistema de Alto Contraste. A estrutura do Windows Forms é baseada na estrutura do Win32. Para obter a melhor experiência, execute a última versão do Windows e aceite as alterações mais recentes do sistema operacional adicionando um arquivo app.manifest a um aplicativo de teste e removendo o comentário do seguinte código:

<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

Melhoria na navegação por teclado

• Quando um controle ComboBox tem a propriedadeDropDownStyle definida como ComboBoxStyle.DropDownList e é o primeiro controle na ordem de tabulação no formulário, agora ele exibe um retângulo de foco quando o formulário pai é aberto usando o teclado. Antes desta alteração, o foco do teclado ficava nesse controle, mas um indicador de foco não era renderizado.

Melhor suporte ao Narrador

• O controle MonthCalendar tem suporte adicional para tecnologias de assistência para acessar o controle, incluindo a capacidade do Narrador ler o valor do controle, quando antes ele não podia.

• O controle CheckedListBox agora notifica o Narrador quando a propriedade CheckBox.CheckState é alterada. Antes, o Narrador não recebia uma notificação e, como resultado, os usuários não eram informados sobre a atualização da propriedade CheckState.

• O controle LinkLabel alterou a maneira como notifica o Narrador do texto no controle. Antes, o Narrador anunciava esse texto duas vezes e lia símbolos "&" como texto real, mesmo que eles não fossem visíveis para um usuário. O texto duplicado foi removido dos anúncios do Narrador, bem como símbolos "&" desnecessários.

• Os tipos de controle DataGridViewCell agora relatam corretamente o status de somente leitura para o Narrador e outras tecnologias assistenciais.

• O Narrator agora é capaz de ler o Menu do Sistema das janelas filhas em aplicativos [Multiple-Document Interface]~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md).

• O Narrador agora é capaz de ler controles ToolStripMenuItem com uma propriedade ToolStripItem.Enabled definida como false. Antes, o Narrador não conseguia focar itens de menu desabilitados para ler o conteúdo.

Nome	Valor
Escopo	Principal
Versão	4.8
Tipo	Redirecionando

APIs afetadas

• ToolStripDropDownButton.CreateAccessibilityInstance()
• DomainUpDown.DomainUpDownAccessibleObject.Name
• MonthCalendar.AccessibilityObject

Windows Presentation Foundation (WPF)

Melhorias de acessibilidade no WPF

Detalhes

Melhorias de Alto Contraste

• Agora, o foco do controle Expander é visível. Em versões anteriores do .NET Framework, isso não acontecia.
• Agora, é mais fácil ver o texto nos controles CheckBox e RadioButton quando eles estão selecionados do que nas versões anteriores do .NET Framework.
• A borda de um ComboBox desabilitado agora é da mesma cor do texto desabilitado. Em versões anteriores do .NET Framework, isso não acontecia.
• Botões desabilitados e com foco usam a cor de tema correta. Em versões anteriores do .NET Framework, isso não acontecia.
• O botão suspenso agora fica visível quando um estilo do controle ComboBox é definido como ToolBar.ComboBoxStyleKey. Em versões anteriores do .NET Framework, isso não acontecia.
• A seta de indicação de classificação em um controle DataGrid agora usa cores do tema. Em versões anteriores do .NET Framework, isso não acontecia.
• O estilo do hiperlink padrão agora é alterado para a cor de tema correto ao passar o mouse. Em versões anteriores do .NET Framework, isso não acontecia.
• O foco do teclado em botões de opção agora fica visível. Em versões anteriores do .NET Framework, isso não acontecia.
• A coluna da caixa de seleção do controle DataGrid usa as cores esperadas para o feedback de foco do teclado. Em versões anteriores do .NET Framework, isso não acontecia.
• os visuais de foco do teclado agora estão visíveis nos controles ComboBox e ListBox. Em versões anteriores do .NET Framework, isso não acontecia.

Melhorias de interação do leitor de tela

• Agora, controles Expander são anunciados corretamente como grupos (expandir/recolher) por leitores de tela.
• Agora, controles DataGridCell são anunciados corretamente como uma célula de grade de dados (localizada) por leitores de tela.
• Leitores de tela agora anunciam o nome de um ComboBox editável.
• Os controles PasswordBox não são mais anunciados como "nenhum item na exibição” pelos leitores de tela.

Suporte para LiveRegion

Os leitores de tela, como o narrador, ajudam as pessoas a entender a interface do usuário de um aplicativo, geralmente descrevendo o elemento de interface do usuário atualmente em foco. No entanto, se um elemento da interface do usuário for alterado em alguma parte da tela e não tiver o foco, o usuário poderá não ser informado e poderá perder informações importantes. LiveRegions devem resolver esse problema. O desenvolvedor pode usá-las para informar o leitor de tela ou qualquer outro cliente de Automação da interface do usuário de que foi feita uma alteração importante em um elemento da interface do usuário. Em seguida, o leitor de tela pode decidir como e quando informar o usuário dessa alteração. A propriedade LiveSetting também permite que o leitor de tela saiba o quanto é importante informar o usuário sobre a alteração feita na interface do usuário.

Sugestão

Como aceitar ou recusar essas alterações

Para que o aplicativo se beneficie dessas alterações, ele precisa ser executado no .NET Framework 4.7.1 ou posterior. O aplicativo pode se beneficiar dessas alterações de uma das seguintes maneiras:

• Defina o .NET Framework 4.7.1 como destino. Essa é a abordagem recomendada. Essas alterações de acessibilidade estão habilitadas por padrão em aplicativos WPF destinados ao .NET Framework 4.7.1 ou posterior.

• Recusar os comportamentos de acessibilidade herdados adicionando a seguinte Opção de AppContext à seção <runtime> do arquivo de configuração de aplicativo e configurando-a como false, como mostra o exemplo a seguir.

  <?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>
  

Os aplicativos destinados ao .NET Framework 4.7.1 ou a versões posteriores que desejam preservar o comportamento de acessibilidade herdado podem aceitar o uso das funcionalidades de acessibilidade herdadas definindo explicitamente essa opção de AppContext como true. Para ter uma visão geral da automação da interface do usuário, confira Visão geral da automação da interface do usuário.

Nome	Valor
Escopo	Principal
Versão	4.7.1
Tipo	Redirecionando

APIs afetadas

• AutomationElementIdentifiers.LiveSettingProperty
• AutomationElementIdentifiers.LiveRegionChangedEvent
• System.Windows.Automation.AutomationLiveSetting
• AutomationProperties.LiveSettingProperty
• AutomationProperties.SetLiveSetting(DependencyObject, AutomationLiveSetting)
• AutomationProperties.GetLiveSetting(DependencyObject)
• AutomationPeer.GetLiveSettingCore()

Evento SelectionChanged e propriedade SelectedValue do seletor

Detalhes

Começando com o .NET Framework 4.7.1, um Selector sempre atualiza o valor de sua propriedade SelectedValue antes de acionar o evento SelectionChanged, quando sua seleção é alterada. Isso torna a propriedade SelectedValue consistente com as outras propriedades de seleção (SelectedItem e SelectedIndex), que são atualizadas antes que o evento seja acionado.

No .NET Framework 4.7 e nas versões anteriores, a atualização de SelectedValue ocorria antes do evento na maioria dos casos, mas ocorria depois do evento quando a alteração da seleção era causada pela alteração da propriedade SelectedValue.

Sugestão

Aplicativos destinados ao .NET Framework 4.7.1 ou posteriores podem recusar essa alteração e usar o comportamento herdado adicionando o seguinte à seção <runtime> do arquivo de configuração de aplicativo:

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

Aplicativos destinados ao .NET Framework 4.7 ou anteriores, mas que são executados no .NET Framework 4.7.1 ou posteriores podem habilitar o novo comportamento adicionando a seguinte linha à seção <runtime> do arquivo de configuração de aplicativo:

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

Nome	Valor
Escopo	Secundária
Versão	4.7.1
Tipo	Redirecionando

APIs afetadas

• TabControl.SelectedContent
• Selector.SelectionChanged

Evento TabControl SelectionChanged e propriedade SelectedContent

Detalhes

A partir do .NET Framework 4.7.1, um TabControl atualiza o valor de sua propriedade SelectedContent antes de acionar o evento SelectionChanged, quando sua seleção é alterada. No .NET Framework 4.7 e em versões anteriores, a atualização de SelectedContent acontecia depois do evento.

Sugestão

Aplicativos destinados ao .NET Framework 4.7.1 ou posteriores podem recusar essa alteração e usar o comportamento herdado adicionando o seguinte à seção <runtime> do arquivo de configuração de aplicativo:

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

Aplicativos destinados ao .NET Framework 4.7 ou anteriores, mas que são executados no .NET Framework 4.7.1 ou posteriores podem habilitar o novo comportamento adicionando a seguinte linha à seção <runtime> do arquivo de configuração de aplicativo:

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

Nome	Valor
Escopo	Secundária
Versão	4.7.1
Tipo	Redirecionando

APIs afetadas

• TabControl.SelectedContent
• Selector.SelectionChanged

O algoritmo de hash padrão para o PackageDigitalSignatureManager do WPF agora é SHA256

Detalhes

O System.IO.Packaging.PackageDigitalSignatureManager fornece funcionalidade para assinaturas digitais em relação a pacotes do WPF. No .NET Framework 4.7 e em versões anteriores, o algoritmo padrão (PackageDigitalSignatureManager.DefaultHashAlgorithm) usado para assinar partes de um pacote era SHA1. Devido a questões de segurança recentes com SHA1, esse padrão foi alterado para o SHA256 a partir do .NET Framework 4.7.1. Esta alteração afeta a assinatura de todos os pacotes, incluindo documentos XPS.

Sugestão

O desenvolvedor que desejará utilizar essa alteração ao direcionar a uma versão do framework abaixo do .NET 4.7.1 ou que precisar da funcionalidade anterior ao direcionar ao .NET 4.7.1 ou posteriores poderá definir o seguinte sinalizador de AppContext adequadamente. O valor true fará com que SHA1 seja usado como algoritmo padrão; false fará com que SHA256 seja usado.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.1
Tipo	Redirecionando

APIs afetadas

• PackageDigitalSignatureManager.DefaultHashAlgorithm

Windows Workflow Foundation (WF)

Melhorias de acessibilidade no designer de fluxo de trabalho do Windows Workflow Foundation (WF)

Detalhes

O designer de fluxo de trabalho do Windows Workflow Foundation (WF) está melhorando a forma como funciona com tecnologias de acessibilidade. essas melhorias incluem as seguintes alterações:

• A ordem de tabulação é alterada para esquerda para a direita e de cima para baixo em alguns controles:
• A janela de inicialização de correlação para definir dados de correlação para a atividade InitializeCorrelation
• A janela de definição de conteúdo para as atividades Receive, Send, SendReply e ReceiveReply
• Mais funções estão disponíveis por meio do teclado:
• Ao editar as propriedades de uma atividade, grupos de propriedades podem ser recolhidos pelo teclado na primeira vez em que são colocados em foco.
• Ícones de aviso agora são acessíveis por teclado.
• O botão Mais Propriedades na janela Propriedades agora pode ser acessado pelo teclado.
• Usuários do teclado agora podem acessar os itens de cabeçalho nos painéis de Argumentos e Variáveis do Designer de Fluxo de Trabalho.
• Melhor visibilidade de itens com foco, como ao:
• Adicionar linhas às grades de dados usadas pelo Designer de Fluxo de Trabalho e por designers de atividades.
• Percorrer campos nas atividades ReceiveReply e SendReply.
• Definir valores padrão para variáveis ou argumentos
• Agora, leitores de tela podem reconhecer corretamente:
• Pontos de interrupção definidos no Designer de Fluxo de Trabalho.
• As atividades FlowSwitch<T>, FlowDecision e CorrelationScope.
• O conteúdo da atividade Receive.
• O Tipo de Destino da atividade InvokeMethod.
• A caixa de combinação Exceção e a seção Finalmente na atividade TryCatch.
• A caixa de combinação Tipo de Mensagem, o divisor na janela Adicionar Inicializadores de Correlação, a janela Definição de Conteúdo e a janela de Definição de CorrelatesOn nas atividades de mensagens (Receive, Send, SendReply e ReceiveReply).
• Transições de máquinas de estado e destinos de transição.
• Anotações e conectores em atividades FlowDecision.
• Os menus de contexto (clique com o botão direito do mouse) para atividades.
• Os editores de valor de propriedade, o botão Limpar Pesquisa, os botões de classificação Por Categoria e Ordem Alfabética e a caixa de diálogo Editor de Expressão na grade de propriedades.
• A porcentagem de zoom no Designer de Fluxo de Trabalho.
• O separador nas atividades Parallel e Pick.
• A atividade InvokeDelegate.
• A janela Selecionar Tipos para atividades de dicionário (Microsoft.Activities.AddToDictionary<TKey,TValue>, Microsoft.Activities.RemoveFromDictionary<TKey,TValue> etc.).
• A janela Procurar e Selecionar um Tipo .NET.
• Trilhas de navegação no Designer de Fluxo de Trabalho.
• Usuários que escolherem temas de Alto Contraste verão muitas melhorias na visibilidade do Designer de Fluxo de Trabalho e em seus controles, como melhores taxas de contraste entre elementos e caixas de seleção mais notáveis usadas para elementos de foco.

Sugestão

Se você tiver um aplicativo com um designer de fluxo de trabalho hospedado novamente, seu aplicativo poderá se beneficiar dessas alterações ao executar qualquer uma das seguintes ações:

• Recompilar o aplicativo para ser destinado ao .NET Framework 4.7.1. Essas alterações de acessibilidade são habilitadas por padrão.
• Se seu aplicativo for destinado ao .NET Framework 4.7 ou anterior, mas estiver em execução no .NET Framework 4.7.1, você poderá recusar esses comportamentos de acessibilidade herdados adicionando a seguinte opção de AppContext à seção <runtime> do arquivo app.config e definindo-a como false, como mostra o exemplo a seguir.

<?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>

Aplicativos destinados ao .NET Framework 4.7.1 ou posterior que desejam preservar o comportamento de acessibilidade herdado pode aceitar o uso das funcionalidades de acessibilidade herdadas definindo explicitamente essa opção de AppContext como true.

Nome	Valor
Escopo	Secundária
Versão	4.7.1
Tipo	Redirecionando

.NET Framework 4.7.2

Núcleo

Permitir caracteres de controle bidirecionais Unicode em URIs

Detalhes

O Unicode especifica vários caracteres de controle especiais usados para especificar a orientação do texto. Nas versões anteriores do .NET Framework, esses caracteres eram excluídos incorretamente de todos os URIs mesmo quando estavam presentes em sua forma codificada por porcentagem. Para atender melhor ao RFC 3987, agora esses caracteres são permitidos nos URIs. Quando encontrados sem codificação em um URI, eles são codificados por porcentagem. Quando encontrados codificados por porcentagem, eles são deixados no estado em que se encontram.

Sugestão

Para aplicativos direcionados a versões do .NET Framework começando com a 4.7.2, o suporte para caracteres bidirecionais Unicode é habilitado por padrão. Se essa alteração não for desejada, você poderá desabilitá-la adicionando a seguinte opção AppContextSwitchOverrides à seção <runtime> do arquivo de configuração de aplicativo:

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

Para aplicativos direcionados a versões anteriores do .NET Framework, mas executados em versões começando com o .NET Framework 4.7.2, o suporte para caracteres bidirecionais Unicode é desabilitado por padrão. Você poderá habilitá-la adicionando a seguinte opção AppContextSwitchOverrides à seção <runtime> do arquivo de configuração de aplicativo:

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

Nome	Valor
Escopo	Secundária
Versão	4.7.2
Tipo	Redirecionando

APIs afetadas

• System.Uri

O DeflateStream usa APIs nativas para descompactação

Detalhes

Começando com o .NET Framework 4.7.2, a implementação da descompactação na classe T:System.IO.Compression.DeflateStream foi alterada para usar APIs nativas do Windows por padrão. Normalmente, isso resulta em uma melhoria significativa de desempenho. Todos os aplicativos .NET direcionados ao .NET Framework versão 4.7.2 ou superior usam a implementação nativo. Essa alteração pode resultar em algumas diferenças no comportamento, que incluem:

• As mensagens de exceção podem ser diferentes. No entanto, o tipo de exceção gerada permanece o mesmo.
• Algumas situações especiais, como não ter memória suficiente para concluir uma operação, podem ser tratadas de maneira diferente.
• Existem diferenças conhecidas para analisar o cabeçalho gzip (observação: somente o GZipStream definido para descompactação é afetado):
• As exceções durante a análise de cabeçalhos inválidos podem ser geradas em momentos diferentes.
• A implementação nativa impõe que os valores de alguns sinalizadores reservados dentro do cabeçalho gzip (ou seja, FLG) são definidos de acordo com a especificação, o que pode causar a geração de uma exceção em casos em que, anteriormente, valores inválidos eram ignorados.

Sugestão

Se a descompactação com as APIs nativas tiver prejudicado o comportamento do aplicativo, você poderá recusar esse recurso adicionando a opção Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression à seção runtime do arquivo app.config e configurando-a como true:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true" />
  </runtime>
</configuration>

Nome	Valor
Escopo	Secundária
Versão	4.7.2
Tipo	Redirecionando

APIs afetadas

• System.IO.Compression.DeflateStream
• System.IO.Compression.GZipStream

Verifique se o System.URI usa um conjunto consistente de caracteres reservados

Detalhes

No System.Uri, determinados caracteres codificados por porcentagem que, às vezes, eram decodificados agora permanecem codificados de forma consistente. Isso ocorre nas propriedades e nos métodos que acessam os componentes de caminho, consulta, fragmento ou informações do usuário do URI. O comportamento será alterado somente quando os dois itens a seguir forem verdadeiros:

• O URI contiver a forma codificada de um dos seguintes caracteres reservados: :, ', (, ), ! ou *.
• O URI contiver um caractere Unicode ou não reservado codificado. Se ambas as condições acima forem verdadeiras, os caracteres reservados codificados serão deixados codificados. Nas versões anteriores do .NET Framework, eles são decodificados.

Sugestão

Para aplicativos direcionados a versões do .NET Framework começando com a 4.7.2, o novo comportamento de decodificação é habilitado por padrão. Se essa alteração não for desejada, você poderá desabilitá-la adicionando a seguinte opção AppContextSwitchOverrides à seção <runtime> do arquivo de configuração de aplicativo:

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

Para aplicativos direcionados a versões anteriores do .NET Framework, mas executados em versões começando com o .NET Framework 4.7.2, o novo comportamento de decodificação é desabilitado por padrão. É possível habilitá-lo adicionando a seguinte opção AppContextSwitchOverrides à seção <runtime> do arquivo de configuração de aplicativo:

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

Nome	Valor
Escopo	Secundária
Versão	4.7.2
Tipo	Redirecionando

APIs afetadas

• System.Uri

O resgen se recusa a carregar conteúdos da Web

Detalhes

Os arquivos .resx podem conter uma entrada formatada em binário. Se você tentar usar o resgen para carregar um arquivo que foi baixado de um local não confiável, ele não carregará a entrada por padrão.

Sugestão

Os usuários do resgen que precisam carregar entradas formatadas em binário de locais não confiáveis podem remover a marca da Web do arquivo de entrada ou aplicar a peculiaridade de recusa. Adicione a seguinte configuração do registro para aplicar a peculiaridade de recusa. Adicione a seguinte configuração de registro para aplicar a peculiaridade de recusa para todo o computador: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\SDK] "AllowProcessOfUntrustedResourceFiles"="true"

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando

Os rastreamentos de pilha obtidos ao usar PDBs portáteis agora incluem informações de arquivo de origem e de linha, quando solicitadas

Detalhes

Começando com o .NET Framework 4.7.2, os rastreamentos de pilha obtidos ao usar PDBs portáteis incluem informações de arquivo de origem e de linha, quando solicitadas. Nas versões anteriores do .NET Framework 4.7.2, as informações de arquivo de origem e de linha não estariam disponíveis ao usar PDBs portáteis, mesmo quando solicitadas explicitamente.

Sugestão

Para os aplicativos direcionados ao .NET Framework 4.7.2, você pode recusar as informações de arquivo de origem e de linha ao usar PDBs portáteis, caso não as deseje, adicionando o seguinte à seção <runtime> do arquivo app.config:

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

Para aplicativos direcionados a versões anteriores do .NET Framework mas executados no .NET Framework 4.7.2 ou posterior, você pode aceitar as informações de arquivo de origem e de linha ao usar PDBs portáteis adicionando o seguinte à seção <runtime> do arquivo app.config:

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando

APIs afetadas

• StackTrace(Boolean)
• StackTrace(Exception, Boolean)
• StackTrace(Exception, Int32, Boolean)

Windows Forms

Melhorias de acessibilidade nos controles do Windows Forms para o .NET 4.7.2

Detalhes

O Windows Forms Framework está melhorando sua maneira de trabalhar com tecnologias de acessibilidade para melhorar o suporte aos clientes do Windows Forms. Isso inclui as seguintes alterações:

• Alterações para melhorar a exibição durante o modo de Alto Contraste.
• Alterações para melhorar a navegação pelo teclado nos controles DataGridView e MenuStrip.
• Alterações na interação com o Narrator.

Sugestão

Como aceitar ou recusar essas alterações Para que o aplicativo se beneficie dessas alterações, ele precisa ser executado no .NET Framework 4.7.2 ou posterior. O aplicativo pode se beneficiar dessas alterações de uma das seguintes maneiras:

• Ser recompilado para ser direcionado ao .NET Framework 4.7.2. Essas alterações de acessibilidade são habilitadas por padrão nos aplicativos do Windows Forms direcionados ao .NET Framework 4.7.2 ou posterior.
• Ser direcionado ao .NET Framework 4.7.1 ou a uma versão anterior e recusar os comportamentos de acessibilidade herdados, adicionando a seguinte Opção AppContext à seção <runtime> do arquivo de configuração de aplicativo e definindo-a como false, como mostra o exemplo a seguir.

<?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>

Observe que para aceitar os recursos de acessibilidade adicionados no .NET Framework 4.7.2, você também precisa aceitar os recursos de acessibilidade do .NET Framework 4.7.1. Os aplicativos destinados ao .NET Framework 4.7.2 ou a versões posteriores que desejam preservar o comportamento de acessibilidade herdado podem aceitar o uso das funcionalidades de acessibilidade herdadas definindo explicitamente essa opção AppContext como true.

Uso de cores definidas pelo sistema operacional em temas de Alto Contraste

• A seta suspensa do ToolStripDropDownButton agora usa cores definidas pelo sistema operacional no tema de Alto Contraste.
• Os controles Button, RadioButton e CheckBox com FlatStyle definido como FlatStyle.Flat ou FlatStyle.Popup, agora usam cores definidas pelo SO no tema de Alto Contraste quando selecionado. Anteriormente, as cores de texto e de tela de fundo não eram contrastantes e eram difíceis de ler.
• Os controles contidos em uma GroupBox que tem sua propriedade Enabled definida como false agora usam cores definidas pelo SO no tema de Alto Contraste.
• Os controles ToolStripButton, ToolStripComboBox e ToolStripDropDownButton têm uma taxa maior de contraste de luminosidade no modo de Alto Contraste.
• Por padrão, a DataGridViewLinkCell usará as cores definidas pelo SO no modo de Alto Contraste para a propriedade DataGridViewLinkCell.LinkColor. Observação: o Windows 10 mudou os valores de algumas cores do sistema de Alto Contraste. A estrutura do Windows Forms é baseada na estrutura do Win32. Para obter a melhor experiência, execute a última versão do Windows e aceite as alterações mais recentes do sistema operacional adicionando um arquivo app.manifest a um aplicativo de teste e removendo o comentário do seguinte código:

<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

Melhor suporte ao Narrador

• O Narrator agora apresenta o valor da propriedade ToolStripMenuItem.ShortcutKeys quando apresenta o texto de um ToolStripMenuItem.
• O Narrator agora indica quando um ToolStripMenuItem tem sua propriedade Enabled definida como false.
• O Narrator agora fornece comentários sobre o estado de uma caixa de seleção quando a propriedade ListView.CheckBoxes está definida como true.
• A ordem de foco do modo de varredura do Narrator agora é consistente com a ordem visual dos controles na janela de diálogo de download do ClickOnce.

Melhoria no suporte à acessibilidade da DataGridView

• As linhas em uma DataGridView agora podem ser classificadas usando o teclado. Agora um usuário pode usar a tecla F3 para classificar pela coluna atual.
• Quando o DataGridView.SelectionMode for definido como DataGridViewSelectionMode.FullRowSelect, o cabeçalho da coluna mudará de cor para indicar a coluna atual à medida que o usuário pressionar Tab para percorrer as células na linha atual.
• A propriedade DataGridViewCell.DataGridViewCellAccessibleObject.Parent agora retorna o controle pai correto.

Melhoria das indicações visuais

• Os controles RadioButton e CheckBox com uma propriedade Text vazia agora exibirão um indicador de foco quando receberem o foco.

Melhoria no suporte à grade de propriedade

• Os elementos filhos do controle PropertyGrid agora retornam true para a propriedade IsReadOnlyProperty somente quando um elemento PropertyGrid está habilitado.

• Os elementos filhos do controle PropertyGrid agora retornam um false para a propriedade IsEnabledProperty somente quando um elemento PropertyGrid pode ser alterado pelo usuário. Para obter uma visão geral de automação da interface do usuário, confira a Visão geral de automação da interface do usuário.

  Melhoria na navegação por teclado

• ToolStripButton agora permite o foco quando contido em um ToolStripPanel que tem a propriedade TabStop definida como true.

Nome	Valor
Escopo	Principal
Versão	4.7.2
Tipo	Redirecionando

A propriedade ContextMenuStrip.SourceControl contém um controle válido no caso de ToolStripMenuItems aninhados

Detalhes

No .NET Framework 4.7.1 e nas versões anteriores, a propriedade ContextMenuStrip.SourceControl retorna nulo incorretamente quando o usuário abre o menu de controles ToolStripMenuItem aninhados. No .NET Framework 4.7.2 e posterior, a propriedade SourceControl é sempre definida como o controle do código-fonte real.

Sugestão

Como aceitar ou recusar essas alterações Para que um aplicativo se beneficie dessas alterações, ele precisa ser executado no .NET Framework 4.7.2 ou posterior. O aplicativo pode se beneficiar dessas alterações de uma das seguintes maneiras:

• Ser direcionado ao .NET Framework 4.7.2. Essa alteração é habilitada por padrão nos aplicativos do Windows Forms direcionados ao .NET Framework 4.7.2 ou posterior.
• Ser direcionado ao .NET Framework 4.7.1 ou a uma versão anterior e recusar os comportamentos de acessibilidade herdados, adicionando a seguinte Opção AppContext à seção <runtime> do arquivo app.config e definindo-a como false, como mostra o exemplo a seguir.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue=false"/>
</runtime>

Os aplicativos direcionados ao .NET Framework 4.7.2 ou posterior que desejam preservar o comportamento de acessibilidade herdado podem aceitar o uso do controle do código-fonte herdado definindo explicitamente essa opção AppContext como true.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando

APIs afetadas

• ContextMenuStrip.SourceControl

O método PrivateFontCollection.AddFontFile libera os recursos de fonte

Detalhes

No .NET Framework 4.7.1 e nas versões anteriores, a classe System.Drawing.Text.PrivateFontCollection não libera os recursos de fonte GDI+ depois que a PrivateFontCollection é descartada para os objetos Font que são adicionados a essa coleção usando o método AddFontFile(String). No .NET Framework 4.7.2 e posterior Dispose libera as fontes GDI+ que foram adicionadas à coleção como arquivos.

Sugestão

Como aceitar ou recusar essas alterações Para que um aplicativo se beneficie dessas alterações, ele precisa ser executado no .NET Framework 4.7.2 ou posterior. O aplicativo pode se beneficiar dessas alterações de uma das seguintes maneiras:

• Ser recompilado para ser direcionado ao .NET Framework 4.7.2. Essa alteração é habilitada por padrão nos aplicativos do Windows Forms direcionados ao .NET Framework 4.7.2 ou posterior.
• Ser direcionado ao .NET Framework 4.7.1 ou a uma versão anterior e recusar os comportamentos de acessibilidade herdados, adicionando a seguinte Opção AppContext à seção <runtime> do arquivo app.config e definindo-a como false, como mostra o exemplo a seguir.

<runtime>
<AppContextSwitchOverrides value="Switch.System.Drawing.Text.DoNotRemoveGdiFontsResourcesFromFontCollection=false"/>
</runtime>

Os aplicativos direcionados ao .NET Framework 4.7.2 ou posterior que desejam preservar o comportamento herdado podem aceitar não liberar os recursos de fonte definindo explicitamente essa opção AppContext como true.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando

APIs afetadas

• PrivateFontCollection.AddFontFile(String)
• FontCollection.Dispose()

As ações de upbutton e downbutton de domínio do WinForm agora estão sincronizadas

Detalhes

No .NET Framework 4.7.1 e nas versões anteriores, a ação DomainUpDown.UpButton() do controle DomainUpDown é ignorada quando o texto do controle está presente e o desenvolvedor precisa usar a ação DomainUpDown.DownButton() no controle antes de usar a ação DomainUpDown.UpButton(). Começando com o .NET Framework 4.7.2, as ações DomainUpDown.UpButton() e DomainUpDown.DownButton() funcionam de forma independente neste cenário e permanecem em sincronização.

Sugestão

Para que o aplicativo se beneficie dessas alterações, ele deverá ser executado no .NET Framework 4.7.2 ou posterior. O aplicativo pode se beneficiar dessas alterações de uma das seguintes maneiras:

• Ser recompilado para ser direcionado ao .NET Framework 4.7.2. Essa alteração é habilitada por padrão nos aplicativos do Windows Forms direcionados ao .NET Framework 4.7.2 ou posterior.
• Recusar o comportamento de rolagem herdado adicionando a seguinte Opção de AppContext à seção <runtime> do arquivo de configuração de aplicativo e configurando-a como false, como mostra o exemplo a seguir.

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling=false"/>
</runtime>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando

APIs afetadas

• DomainUpDown.UpButton()
• DomainUpDown.DownButton()

Windows Presentation Foundation (WPF)

O foco do teclado agora é movido corretamente em várias camadas de hospedagem do WinForms/WPF

Detalhes

Considere um aplicativo WPF que hospede um controle do WinForms que, por sua vez, hospede controles do WPF. É possível que os usuários não consigam sair com Tab da camada do WinForms se o primeiro ou o último controle nessa camada for o System.Windows.Forms.Integration.ElementHost do WPF. Essa alteração corrige esse problema e os usuários agora conseguem sair com Tab da camada do WinForms. Os aplicativos automatizados baseados em foco que nunca saem da camada do WinForms podem não funcionar mais conforme o esperado.

Sugestão

O desenvolvedor que desejar utilizar esta alteração ao direcionar a uma versão do framework abaixo do .NET 4.7.2 poderá definir o seguinte conjunto de sinalizadores de AppContext como false para que a alteração seja habilitada.

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

Os aplicativos WPF precisam aceitar todas as melhorias de acessibilidade iniciais para obter as melhorias mais recentes. Em outras palavras, ambas as opções Switch.UseLegacyAccessibilityFeatures e Switch.UseLegacyAccessibilityFeatures.2 precisam ser definidas. O desenvolvedor que precisar da funcionalidade anterior ao direcionar ao .NET 4.7.2 ou a versões posteriores poderá definir o seguinte sinalizador de AppContext como true para que a alteração seja desabilitada.

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando

O algoritmo de hash padrão do compilador de marcação do WPF agora é o SHA256

Detalhes

O MarkupCompiler do WPF fornece serviços de compilação para arquivos de marcação XAML. No .NET Framework 4.7.1 e nas versões anteriores, o algoritmo de hash padrão usado para as somas de verificação era o SHA1. Devido a questões de segurança recentes com o SHA1, esse padrão foi alterado para o SHA256 começando com o .NET Framework 4.7.2. Essa alteração afeta toda a geração de soma de verificação para arquivos de marcação durante a compilação.

Sugestão

O desenvolvedor que direcionar ao .NET Framework 4.7.2 ou superior e desejar reverter para o comportamento de hash do SHA1 precisará definir o sinalizador de AppContext a seguir.

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

O desenvolvedor que desejar utilizar o hash SHA256 ao direcionar a uma versão do framework abaixo do .NET 4.7.2 precisará definir o sinalizador de AppContext abaixo. Observe que a versão instalada do .NET Framework precisará ser a 4.7.2 ou superior.

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

Nome	Valor
Escopo	Transparente
Versão	4.7.2
Tipo	Redirecionando

A manipulação de desligamento do AppDomain do WPF já pode chamar Dispatcher.Invoke na limpeza de eventos fracos

Detalhes

No .NET Framework 4.7.1 e em versões anteriores, o WPF potencialmente cria um System.Windows.Threading.Dispatcher no thread de finalizador do .NET durante o desligamento do AppDomain. Isso foi corrigido no .NET Framework 4.7.2 e em versões posteriores, fazendo com que a limpeza de eventos fracos obtenha o reconhecimento de thread. Devido a isso, o WPF pode chamar Dispatcher.Invoke para concluir o processo de limpeza. Em alguns aplicativos, essa alteração no tempo do finalizador potencialmente pode causar exceções durante o desligamento do processo ou do AppDomain. Em geral, isso é visto em aplicativos que não desligam corretamente os dispatchers em execução nos threads de trabalho antes do desligamento do processo ou do AppDomain. Esses aplicativos devem ter cuidado para gerenciar corretamente o tempo de vida dos dispatchers.

Sugestão

No .NET Framework 4.7.2 e em versões posteriores, os desenvolvedores podem desabilitar essa correção para ajudar a aliviar (mas não eliminar) problemas de tempo que possam ocorrer devido à alteração na limpeza. Para desabilitar a alteração na limpeza, use o sinalizador de AppContext a seguir.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotInvokeInWeakEventTableShutdownListener=true"/>
</runtime>
</configuration>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando

WPF alterando uma chave primária ao exibir dados ADO em um cenário de detalhes/mestre

Detalhes

Suponha que você tenha uma coleção ADO de itens do tipo Order, com uma relação chamada "OrderDetails", relacionando-a a uma coleção de itens do tipo Detail por meio da chave primária "OrderID". No seu aplicativo WPF, você pode vincular um controle de lista aos detalhes de determinado pedido:

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

em que o DataContext é um Order. O WPF obtém o valor da propriedade OrderDetails, uma coleção D de todos os itens Detail cuja OrderID corresponde à OrderID do item mestre. A alteração de comportamento surge quando você altera a OrderID da chave primária do item mestre. O ADO altera automaticamente a OrderID de cada um dos registros afetados na coleção Detalhes (ou seja, os que foram copiados na coleção D). Mas o que acontece com D?

• Comportamento antigo: a coleção D é apagada. O item mestre não gera uma notificação de alteração para a propriedade OrderDetails. O ListBox continua a usar a coleção D, que agora está vazia.
• Novo comportamento: a coleção D fica inalterada. Cada um dos seus itens gera uma notificação de alteração para a propriedade OrderID. O ListBox continua a usar a coleção D e exibe os detalhes com a nova OrderID. O WPF implementa o novo comportamento criando a coleção D de uma forma diferente: chamando o método ADO DataRowView.CreateChildView(DataRelation, Boolean) com o argumento followParent definido como true.

Sugestão

Um aplicativo obtém o novo comportamento usando o comutador AppContext a seguir.

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

O padrão do comutador é true (comportamento antigo) para aplicativos direcionados para o .NET 4.7.1 ou anterior e false (novo comportamento) para aplicativos direcionados para o .NET 4.7.2 ou posterior.

Nome	Valor
Escopo	Secundária
Versão	4.7.2
Tipo	Redirecionando

O FocusVisual do WPF para RadioButton e CheckBox agora é exibido corretamente quando os controles não têm nenhum conteúdo

Detalhes

No .NET Framework 4.7.1 e nas versões anteriores, o System.Windows.Controls.CheckBox e o System.Windows.Controls.RadioButton do WPF têm visuais de foco inconsistentes e, nos temas Clássico e de Alto Contraste, eles têm visuais de foco incorretos. Esses problemas ocorrem quando os controles não têm nenhum conjunto de conteúdo. Isso pode dificultar a transição entre os temas e deixar o visual de foco confuso. No .NET Framework 4.7.2, agora esses visuais são mais consistentes entre os temas e mais facilmente visíveis nos temas Clássico e de Alto Contraste.

Sugestão

O desenvolvedor que direcionar ao .NET Framework 4.7.2 e desejar reverter para o comportamento no .NET 4.7.1 precisará definir o sinalizador de AppContext a seguir.

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

O desenvolvedor que desejar utilizar essa alteração ao direcionar a uma versão do framework abaixo do .NET 4.7.2 precisará definir os sinalizadores de AppContext a seguir. Observe que todos os sinalizadores precisam ser definidos corretamente e a versão instalada do .NET Framework precisa ser a 4.7.2 ou superior. Os aplicativos WPF precisam aceitar todas as melhorias de acessibilidade anteriores para obter as mais recentes. Para fazer isso, verifique se as opções AppContext 'Switch.UseLegacyAccessibilityFeatures' e 'Switch.UseLegacyAccessibilityFeatures.2' estão definidas como false.

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando

A seleção de texto da caixa de TextBox/PasswordBox do WPF não segue as cores do sistema

Detalhes

No .NET Framework 4.7.1 e nas versões anteriores, o System.Windows.Controls.TextBox e o System.Windows.Controls.PasswordBox do WPF somente podiam renderizar uma seleção de texto na camada de Adorno. Em alguns temas do sistema, isso obstruía o texto, dificultando a leitura. No .NET Framework 4.7.2 e nas versões posteriores, os desenvolvedores têm a opção de habilitar um esquema de renderização de seleção não baseado no Adorno que elimina esse problema.

Sugestão

O desenvolvedor que desejar utilizar essa alteração precisará definir o seguinte sinalizador de AppContext adequadamente. Para utilizar esse recurso, a versão instalada do .NET Framework precisará ser a 4.7.2 ou superior. Para habilitar a seleção não baseada em Adorno, use o sinalizador de AppContext a seguir.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Text.UseAdornerForTextboxSelectionRendering=false"/>
</runtime>
</configuration>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando

Windows Workflow Foundation (WF)

Evitando a recursão infinita para IWorkflowInstanceManagement.TransactedCancel e IWorkflowInstanceManagement.TransactedTerminate

Detalhes

Em algumas circunstâncias, ao usar as APIs IWorkflowInstanceManagement.TransactedCancel ou IWorkflowInstanceManagement.TransactedTerminate para cancelar ou terminar uma instância de serviço de fluxo de trabalho, a instância de fluxo de trabalho pode encontrar um excedente de pilha devido à recursão infinita quando o runtime do Workflow tenta persistir a instância de serviço como parte do processamento da solicitação. O problema ocorre quando a instância de fluxo de trabalho está em um estado em que aguarda a conclusão de outras solicitações do WCF pendentes para outro serviço. As operações TransactedCancel e TransactedTerminate criam itens de trabalho que são colocados na fila da instância do serviço de fluxo de trabalho. Esses itens de trabalho não são executados como parte do processamento da solicitação TransactedCancel/TransactedTerminate. Como a instância de serviço do fluxo de trabalho está ocupada esperando a conclusão da outra solicitação do WCF pendente, o item de trabalho criado permanece na fila. A operação TransactedCancel/TransactedTerminate é concluída e o controle é retornado ao cliente. Quando a transação associada à operação TransactedCancel/TransactedTerminate tenta ser confirmada, ela precisa persistir o estado da instância de serviço do fluxo de trabalho. Mas como há uma solicitação de WCF pendente para a instância, o runtime de fluxo de trabalho não consegue persistir a instância de serviço do fluxo de trabalho e um loop de recursão infinita causa o excedente de pilha. Como TransactedCancel e TransactedTerminate apenas criam um item de trabalho na memória, o fato de que existe uma transação não tem nenhum efeito. Uma reversão da transação não descarta o item de trabalho. Para resolver esse problema, começando com o .NET Framework 4.7.2, foi introduzido um AppSetting que pode ser adicionado ao serviço de fluxo de trabalho web.config/app.config para solicitar que as transações de TransactedCancel e TransactedTerminate sejam ignoradas. Isso permite que a transação seja confirmada sem esperar que a instância de fluxo de trabalho seja persistida. A AppSetting desse recurso é chamada microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate. O valor true indica que a transação deve ser ignorada, evitando o excedente de pilha. O valor padrão dessa AppSetting é false, portanto, as instâncias de serviço do fluxo de trabalho existentes não são afetadas.

Sugestão

Se você estiver usando o AppFabric ou outro cliente IWorkflowInstanceManagement e encontrar um excedente de pilha na instância de serviço do fluxo de trabalho durante a tentativa de cancelar ou terminar uma instância de fluxo de trabalho, você poderá adicionar o seguinte à seção <appSettings> do arquivo web.config/app.config para o serviço de fluxo de trabalho:

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

Se o problema não ocorrer, não será necessário fazer isso.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.7.2
Tipo	Redirecionando