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

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

.NET Framework 4.7

ASP.NET

HttpRuntime.AppDomainAppPath gera uma exceção NullReferenceException

Detalhes

No .NET Framework 4.6.2, o runtime lança um 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 um T:System.ArgumentNullException.

Sugestão

Você pode fazer qualquer uma das seguintes etapas para responder a esta alteração:

• Manipule o T:System.NullReferenceException se o aplicativo estiver em execução no .NET Framework 4.6.2.
• Atualize para o .NET Framework 4.7, que restaura o comportamento anterior e lança um T:System.ArgumentNullException.

APIs afetadas

• HttpRuntime.AppDomainAppPath

Limitar solicitações simultâneas por sessão

Detalhes

No .NET Framework 4.6.2 e anterior, ASP.NET executa solicitações com o mesmo Sessionid sequencialmente e ASP.NET sempre emite o Sessionid por meio de cookies por padrão. Se uma página levar muito tempo para responder, isso prejudicará significativamente o desempenho do servidor apenas pressionando F5 no navegador. Na correção, adicionamos um contador para acompanhar as solicitações na fila e encerrar as solicitações quando elas excederem um limite especificado. O valor padrão é 50. Se o limite for atingido, 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>

Rede

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

Detalhes

Começando com aplicativos direcionados ao .NET Framework 4.7, o valor padrão da propriedade ServicePointManager.SecurityProtocol é SecurityProtocolType.SystemDefault. Essa alteração permite que as APIs de rede do .NET Framework com base no 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)].

Sugestão

Essa alteração afeta aplicativos direcionados ao .NET Framework 4.7 ou versões posteriores. Se você preferir usar um protocolo definido em vez de depender do padrão do sistema, poderá definir explicitamente o valor da propriedade ServicePointManager.SecurityProtocol. Se essa alteração for indesejável, você poderá recusar a alteração adicionando uma configuração à seção <runtime> do arquivo de configuração do 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>

APIs afetadas

• ServicePointManager.SecurityProtocol

O SslStream dá suporte a alertas 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

Aplicativos que chamam APIs de E/S de rede, como Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32), devem lidar com IOException ou System.TimeoutException.
O recurso alertas TLS é habilitado por padrão, começando com o .NET Framework 4.7. Aplicativos destinados a versões do .NET Framework de 4.0 a 4.6.2 em execução em um sistema .NET Framework 4.7 ou 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 aplicativos .NET Framework 4.6 e posteriores em execução no .NET Framework 4.7 ou posterior.

• Programaticamente: deve ser a primeira coisa que o aplicativo faz, pois o ServicePointManager será 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 – 4.6.2.

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

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;

Nas versões anteriores do .NET Framework, esperava-se que o valor fosse um System.IntPtr representando um local na memória em que o HWND valor residia. Ao definir a propriedade para form.Handle no Windows 7 e em versões anteriores, não teve efeito, mas 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;

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

• Definindo programaticamente as opções de compatibilidade no AppContext, conforme explicado nos Comunicados do .NET no Build 2015.
• 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, os usuários que desejam aceitar o novo comportamento no runtime do .NET Framework 4.7 quando o aplicativo é carregado em versões mais antigas do .NET Framework podem definir a opção AppContext como false.

APIs afetadas

• CspParameters.ParentWindowHandle

O SslStream dá suporte a alertas 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

Aplicativos que chamam APIs de E/S de rede, como Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32), devem lidar com IOException ou System.TimeoutException.
O recurso alertas TLS é habilitado por padrão, começando com o .NET Framework 4.7. Aplicativos destinados a versões do .NET Framework de 4.0 a 4.6.2 em execução em um sistema .NET Framework 4.7 ou 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 aplicativos .NET Framework 4.6 e posteriores em execução no .NET Framework 4.7 ou posterior.

• Programaticamente: deve ser a primeira coisa que o aplicativo faz, pois o ServicePointManager será 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 – 4.6.2.

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

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)

A 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, o System.Runtime.Serialization.Json.DataContractJsonSerializer não serializou alguns caracteres de controle especiais, como \b, \f e \t, de uma forma 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 ECMAScript V6 e V8.

Sugestão

Para aplicativos direcionados ao .NET Framework 4.7, esse recurso é habilitado por padrão. Se esse comportamento não for desejável, você poderá recusar esse recurso adicionando a seguinte linha à seção <runtime> do arquivo app.config ou web.config:

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

APIs afetadas

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

A segurança de mensagens do WCF agora é capaz de usar TLS1.1 e 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 do TLS1.0 por meio das configurações de aplicativo.

Sugestão

No .NET Framework 4.7, o suporte para TLS1.1 e TLS1.2 na segurança de mensagens do WCF é desabilitado por padrão. Você pode habilitá-lo adicionando a seguinte linha à seção <runtime> do arquivo app.config ou web.config:

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

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 começando com o .NET Framework 4.7.

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

Detalhes

Um erro no código de tratamento de exceção para ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) fez com que um System.NullReferenceException incorreto fosse gerado em vez da exceção pretendida (System.IO.DirectoryNotFoundException ou System.IO.FileNotFoundException). Essa alteração corrige esse erro para que o método agora gere 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 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>

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 Grid usa para alocar espaço para *-columns. Isso alterará a largura real atribuída a *-columns em vários 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, a partir 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 a DPI de exibição efetiva é suficientemente alta. Nos dois primeiros casos, as larguras produzidas pelo novo algoritmo podem ser significativamente diferentes daquelas 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 para colunas pode exceder a largura da grade. Isso pode ocorrer ao alocar espaço para uma coluna cuja quota proporcional é menor que seu tamanho mínimo. O algoritmo aloca o tamanho mínimo, o que diminui 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 menos (ou mais) alocação proporcional do que A.

• Colunas com pesos extremamente grandes (> 10^298) são tratadas como se tivessem peso 10^298. Diferenças proporcionais entre elas (e entre colunas com pesos ligeiramente menores) não são respeitadas.

• 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 atendem aos seguintes critérios:

  • A largura real atribuída a uma *-coluna 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 preciso, se duas colunas forem declaradas com largura x* e y* respectivamente, e se nenhuma das colunas receber a 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 exceder 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.

Sugestão

Por padrão, os aplicativos destinados a versões do .NET Framework a partir do .NET Framework 4.7 verão o novo algoritmo, enquanto os aplicativos destinados ao .NET Framework 4.6.2 ou versões anteriores verã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.

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 a escrita à tinta e o StylusPlugins ainda funcionem, eles serão processados no Thread de 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 potencialmente 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 desativará essa pilha opcional. Observe que essa pilha está disponível apenas no Windows 10 Creators Update e acima.

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

.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, ASP.NET melhorou a forma como os controles Web ASP.NET funcionam com a tecnologia de acessibilidade no Visual Studio para dar melhor suporte aos clientes ASP.NET. Elas incluem as seguintes alterações:

• Alterações para implementar padrões de acessibilidade de interface do usuário ausentes em 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 Paginador 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 desativar essas alterações Para que o Visual Studio Designer se beneficie dessas alterações, ele deve ser executado no .NET Framework 4.7.1 ou posterior. O aplicativo Web pode se beneficiar dessas alterações de qualquer uma das seguintes maneiras:

• Instale o Visual Studio 2017 15.3 ou posterior, que dá suporte aos novos recursos de acessibilidade com o seguinte AppContext Switch por padrão.
• Opte por não usar os comportamentos de acessibilidade herdados adicionando a opção Switch.UseLegacyAccessibilityFeatures AppContext à seção <runtime> no arquivo devenv.exe.config e defini-la 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 direcionados ao .NET Framework 4.7.1 ou posterior e que desejam preservar o comportamento de acessibilidade herdado podem optar pelo uso de recursos de acessibilidade herdados definindo explicitamente essa opção AppContext como true.

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.
Em aplicativos destinados ao .NET Framework 4.7.1 ou uma versão posterior, os threads em segundo plano esperam por eventos do sistema operacional relacionados à porta serial ativa e podem falhar em alguns casos, como remoção repentina da porta serial.

Sugestão

Para aplicativos que têm como alvo o .NET Framework 4.7.1, você pode optar por não usar o tratamento de exceções, se isso 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, você pode optar pela 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>

APIs afetadas

• System.IO.Ports.SerialPort

O ServiceBase não propaga exceções do OnStart

Detalhes

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

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

Sugestão

No início do serviço, se houver uma exceção, essa exceção será propagada. Isso deve ajudar a diagnosticar casos em que os serviços não são iniciados.

Se esse comportamento for indesejável, você poderá recusar isso adicionando o seguinte elemento AppContextSwitchOverrides à seção runtime do arquivo de configuração do aplicativo:

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

Se o aplicativo tiver como destino uma versão anterior à 4.7.1, mas você quiser ter esse comportamento, adicione o seguinte elemento AppContextSwitchOverrides à seção runtime do arquivo de configuração do aplicativo:

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

APIs afetadas

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

Segurança

Algoritmos padrão SignedXML e SignedXMS foram alterados para SHA256.

Detalhes

No .NET Framework 4.7 e anterior, SignedXML e SignedCMS são padrão para SHA1 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 aplicativos que têm como alvo o .NET Framework 4.7.1 e versões posteriores, se o uso de SHA256 for indesejável, você pode restaurar o padrão para SHA1 adicionando a seguinte chave de configuração à seção runtime do arquivo de configuração do seu aplicativo:

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

Para aplicativos direcionados ao .NET Framework 4.7 e versões anteriores, você pode optar por essa alteração 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.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />

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 do objeto retornado pelo método SignedXml.GetPublicKey foi alterado (sem uma peculiaridade) de uma implementação CryptoServiceProvider para uma implementação de Cng. Isso ocorre porque a implementação mudou de usar certificate.PublicKey.Key para usar a certificate.GetAnyPublicKey interna que encaminha para RSACertificateExtensions.GetRSAPublicKey.

Sugestão

Começando com aplicativos em execução no .NET Framework 4.7.1, você pode usar a implementação 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" />

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 de SvcConfigEditor.exe e SvcTraceViewer.exe foram aprimoradas corrigindo problemas variados de acessibilidade. A maioria deles eram pequenos problemas, como um nome não sendo definido ou determinados padrões de automação da interface do usuário não sendo implementados corretamente. Embora muitos usuários não estejam cientes desses valores incorretos, os clientes que usam tecnologias adaptativas, como leitores de tela, acharão essas ferramentas do SDK mais acessíveis. Certamente, essas correções alteram alguns comportamentos anteriores, como a ordem de foco do teclado. Para obter todas as correções de acessibilidade nessas ferramentas, você pode adicionar o seguinte ao arquivo app.config:

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

Windows Forms

Melhorias de acessibilidade nos controles do Windows Forms

Detalhes

O Windows Forms está melhorando o funcionamento com tecnologias de acessibilidade para dar melhor suporte aos clientes do Windows Forms. Elas incluem 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 do navegador de propriedades. As melhorias no Navegador 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 nos controles.

Sugestão

Como aceitar ou desativar essas alterações Para que o aplicativo se beneficie dessas alterações, ele deve ser executado no .NET Framework 4.7.1 ou posterior. O aplicativo pode se beneficiar dessas alterações de qualquer 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 opta por não usar 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.

<?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 direcionados ao .NET Framework 4.7.1 ou posterior e que desejam preservar o comportamento de acessibilidade herdado podem optar pelo uso de recursos de acessibilidade herdados definindo explicitamente essa opção AppContext como true.

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

Foi adicionado suporte para padrões e propriedades de Automação da Interface do Usuário

Os clientes de acessibilidade podem aproveitar a nova funcionalidade de acessibilidade do WinForms usando padrões comuns de invocação descritos publicamente. Esses padrões não são específicos do WinForms. Por exemplo, os 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. A partir do .NET Framework 4.7.1, IServiceProvider e IAccessibleEx (quando aplicável) estão disponíveis para objetos de acessibilidade do WinForms.

O .NET Framework 4.7.1 adiciona suporte para os 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 dá suporte ao TogglePattern.

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

  Melhorias no controle PropertyGrid o .NET Framework 4.7.1 adiciona as seguintes melhorias ao controle 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 mensagens exibido quando o botão Detalhes da caixa de diálogo de erro é expandido agora está acessível ao 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.

• Navegação de teclado aprimorada entre a grade e a Barra de Ferramentas acima dela. Pressionar "Shift-Tab" agora seleciona o primeiro botão Barra de Ferramentas, em vez de toda a Barra de Ferramentas.

• Os 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.

• Os 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.

• Os 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 da barra de ferramentas de controle PropertyGrid que indicam o valor atual da propriedade PropertySort dão suporte ao TogglePattern.

• Suporte aprimorado ao 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 sistema operacional no tema de Alto Contraste quando selecionadas. Anteriormente, as cores de texto e plano de fundo não eram contrastantes e eram difíceis de ler.
• Os controles Button, CheckBox, RadioButton, Label, LinkLabele GroupBox com a propriedade Enabled definida como falso usaram uma cor sombreada para renderizar texto em temas de Alto Contraste, resultando em baixo contraste em relação à tela de fundo. Agora, esses controles usam a cor "Texto desabilitado" definida pelo sistema operacional. Essa correção se aplica a controles com a propriedade FlatStyle definida como 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 determinados 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 alterou valores para algumas cores do sistema de alto contraste. O Windows Forms Framework é baseado na estrutura Win32. Para obter a melhor experiência, execute na versão mais recente do Windows e opte pelas alterações mais recentes do sistema operacional adicionando um arquivo app.manifest em um aplicativo de teste e cancelando o comentário do seguinte código:

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

Navegação de teclado aprimorada

• 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 dessa alteração, o foco do teclado estava nesse controle, mas um indicador de foco não foi renderizado.

Aprimoramento do suporte do Narrador

• O controle MonthCalendar adicionou suporte para tecnologias adaptativas acessarem o controle, incluindo a capacidade do Narrador de ler o valor do controle quando anteriormente não era possível.

• O controle CheckedListBox agora notifica o Narrador quando a propriedade CheckBox.CheckState é alterada. Anteriormente, o Narrador não recebia notificação e, como resultado, os usuários não seriam informados de que a propriedade CheckState havia sido atualizada.

• O controle LinkLabel alterou a maneira como notifica o Narrador do texto no controle. Anteriormente, o Narrador anunciou este texto duas vezes e leu símbolos de "&" como texto real, mesmo que eles não estejam visíveis para um usuário. O texto duplicado foi removido dos anúncios do Narrador, assim como os 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. Anteriormente, o Narrador não conseguia se concentrar em itens de menu desabilitados para ler o conteúdo.

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. Nas versões anteriores do .NET Framework, não era.
• O texto em controles CheckBox e RadioButton quando eles são selecionados agora é mais fácil de ver do que nas versões anteriores do .NET Framework.
• A borda de um ComboBox desabilitado agora é a mesma cor do texto desabilitado. Nas versões anteriores do .NET Framework, não era.
• Botões desabilitados e com foco usam a cor de tema correta. Nas 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. Nas versões anteriores do .NET Framework, não era.
• A seta de indicação de classificação em um controle DataGrid agora usa cores do tema. Em versões anteriores do .NET Framework, não.
• O estilo de hiperlink padrão agora muda para a cor correta do tema quando se passa o mouse sobre ele. Em versões anteriores do .NET Framework, não.
• O foco do teclado em botões de opção agora fica visível. Nas versões anteriores do .NET Framework, não era.
• 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, não.
• os visuais de foco do teclado agora estão visíveis nos controles ComboBox e ListBox. Nas versões anteriores do .NET Framework, não era.

melhorias de interação do leitor de tela

• Agora, os controles Expander são anunciados corretamente como grupos (expandir/recolher) por leitores de tela.
• Agora, os 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 em exibição" por leitores de tela.

Suporte para LiveRegion

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 que atualmente tem foco. No entanto, se um elemento de interface do usuário for alterado em algum lugar da tela e não tiver o foco, o usuário poderá não ser informado e perder informações importantes. As LiveRegions são destinadas a resolver esse problema. Um desenvolvedor pode usá-los para informar o leitor de tela ou qualquer outro cliente de automação de interface do usuário que uma alteração importante foi feita em um elemento de interface do usuário. O leitor de tela pode decidir como e quando informar o usuário sobre essa 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 sair dessas alterações

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

• Defina o .NET Framework 4.7.1 como destino. Essa é a abordagem recomendada. Essas alterações de acessibilidade sã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>
  

Aplicativos direcionados ao .NET Framework 4.7.1 ou posterior e que desejam preservar o comportamento de acessibilidade herdado podem optar pelo uso de recursos de acessibilidade herdados definindo explicitamente essa opção AppContext como true. Para obter uma visão geral da automação da interface do usuário, consulte Visão geral da automação da interface do usuário.

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 de gerar o evento.

No .NET Framework 4.7 e versões anteriores, a atualização para SelectedValue ocorreu antes do evento na maioria dos casos, mas ocorreu após o evento se a alteração da seleção foi causada pela alteração da propriedade SelectedValue.

Sugestão

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

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

Aplicativos direcionados ao .NET Framework 4.7 ou anterior, mas que estão em execução no .NET Framework 4.7.1 ou posterior, podem habilitar o novo comportamento adicionando a seguinte linha à seção <runtime> do arquivo .configuration do aplicativo:

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

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 disparar o evento SelectionChanged, quando sua seleção é alterada. No .NET Framework 4.7 e versões anteriores, a atualização para SelectedContent acontecia após o evento.

Sugestão

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

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

Aplicativos direcionados ao .NET Framework 4.7 ou anterior, mas que estão em execução no .NET Framework 4.7.1 ou posterior, podem habilitar o novo comportamento adicionando a seguinte linha à seção <runtime> do arquivo .configuration do aplicativo:

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

APIs afetadas

• TabControl.SelectedContent
• Selector.SelectionChanged

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

Detalhes

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

Sugestão

Um desenvolvedor que deseja utilizar essa alteração ao direcionar uma versão da estrutura abaixo do .NET Framework 4.7.1 ou um desenvolvedor que requer a funcionalidade anterior ao direcionar o .NET Framework 4.7.1 ou superior pode definir o sinalizador AppContext a seguir adequadamente. Um valor verdadeiro resultará em SHA1 sendo usado como o algoritmo padrão; resultados falsos em SHA256.

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

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 WF (Windows Workflow Foundation) está melhorando a maneira como ele funciona com tecnologias de acessibilidade. Essas melhorias incluem as seguintes alterações:

• A ordem de tabulação é alterada para a 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, SendReplye 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.
• Os ícones de aviso agora estão acessíveis por teclado.
• O botão Mais Propriedades na janela Propriedades agora está acessível pelo teclado.
• Os usuários de teclado agora podem acessar os itens de cabeçalho nos painéis Argumentos e Variáveis do Designer de Fluxo de Trabalho.
• Aperfeiçoamento na visibilidade de itens em foco, como quando:
• Adicionando linhas a grades de dados usadas pelo Designer de Fluxo de Trabalho e designers de atividades.
• Percorrer campos nas atividades ReceiveReply e SendReply.
• Definindo valores padrão para variáveis ou argumentos
• Os leitores de tela agora 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.
• Os usuários que escolherem temas de Alto Contraste verão muitas melhorias na visibilidade do Designer de Fluxo de Trabalho e seus controles, como melhores proporções de contraste entre elementos e caixas de seleção mais perceptí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 executando uma destas ações:

• Recompile seu aplicativo para direcionar o .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 direcionados ao .NET Framework 4.7.1 ou posterior e que desejam preservar o comportamento de acessibilidade herdado podem optar pelo uso de recursos de acessibilidade herdados definindo explicitamente essa opção AppContext como true.

.NET Framework 4.7.2

Núcleo

Permitir caracteres de controle bidirecional Unicode em URIs

Detalhes

O Unicode especifica vários caracteres de controle especiais usados para especificar a orientação do texto. Em versões anteriores do .NET Framework, esses caracteres foram removidos incorretamente de todas as URIs, mesmo que estivessem presentes em sua forma codificada por porcentagem. Para atender melhor ao RFC 3987, agora esses caracteres são permitidos nos URIs. Quando encontrados não codificados 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 destinados a versões do .NET Framework a partir do 4.7.2, o suporte para caracteres bidirecionais Unicode é habilitado por padrão. Se essa alteração for indesejável, você poderá desabilitá-la adicionando a seguinte configuração AppContextSwitchOverrides na seção <runtime> do arquivo de configuração do aplicativo.

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

Para aplicativos destinados a versões anteriores do .NET Framework, mas que estão em execução em versões que começam com o .NET Framework 4.7.2, o suporte para caracteres bidirecionais Unicode é 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.DontKeepUnicodeBidiFormattingCharacters=false" />
</runtime>

APIs afetadas

• System.Uri

DeflateStream usa APIs nativas para descompactação

Detalhes

A partir do .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 melhora substancial no desempenho. Todos os aplicativos .NET direcionados ao .NET Framework versão 4.7.2 ou superior usam a implementação nativa. Essa alteração pode resultar em algumas diferenças de comportamento, que incluem:

• 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 forma diferente.
• Há diferenças conhecidas para processar o cabeçalho gzip (nota: apenas o conjunto GZipStream 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) sejam definidos de acordo com a especificação, o que pode fazer com que ele gere uma exceção em que valores anteriormente inválidos foram ignorados.

Sugestão

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

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

APIs afetadas

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

Verifique se System.Uri usa um conjunto de caracteres reservado consistente

Detalhes

Em System.Uri, determinados caracteres codificados por porcentagem que às vezes eram decodificados agora permanecem consistentemente codificados. 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 ambos os seguintes forem verdadeiros:

• O URI contém a forma codificada de qualquer um dos seguintes caracteres reservados: :, ', (, ), ! ou *.
• O URI contiver um caractere Unicode ou não reservado codificado. Se ambos forem verdadeiros, os caracteres reservados codificados permanecem codificados. Nas versões anteriores do .NET Framework, elas são decodificadas.

Sugestão

Para aplicativos destinados a versões do .NET Framework a partir da 4.7.2, o novo comportamento de decodificação é habilitado por padrão. Se essa alteração for indesejável, você poderá desabilitá-la adicionando a seguinte configuração AppContextSwitchOverrides na seção <runtime> do arquivo de configuração do aplicativo.

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

Para aplicativos destinados a versões anteriores do .NET Framework, mas que estão em execução em versões que começam 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>

APIs afetadas

• System.Uri

O Resgen se recusa a carregar conteúdo da Web

Detalhes

Arquivos .resx podem conter entrada formatada binária. 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"

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. Em versões anteriores ao .NET Framework 4.7.2, as informações de arquivo de origem e linha não estariam disponíveis ao usar PDBs portáteis, mesmo que explicitamente solicitadas.

Sugestão

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

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

Para aplicativos destinados a versões anteriores do .NET Framework, mas executados no .NET Framework 4.7.2 ou posterior, você pode optar pelas informações de arquivo de origem e 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>

APIs afetadas

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

Windows Forms

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

Detalhes

O Windows Forms Framework está melhorando o funcionamento com tecnologias de acessibilidade para dar melhor suporte aos clientes do Windows Forms. Elas incluem as seguintes alterações:

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

Sugestão

Como aceitar ou sair dessas alterações Para que o aplicativo se beneficie dessas alterações, ele deve ser executado no .NET Framework 4.7.2 ou posterior. O aplicativo pode se beneficiar dessas alterações de qualquer 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 em aplicativos do Windows Forms destinados ao .NET Framework 4.7.2 ou posterior.
• Ele tem como destino o .NET Framework 4.7.1 ou versão anterior e opta por não usar os comportamentos de acessibilidade herdados adicionando os seguintes AppContext Switch à seção <runtime> do arquivo de configuração do aplicativo e definindo-o 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 deve optar pelos recursos de acessibilidade do .NET Framework 4.7.1. Aplicativos direcionados ao .NET Framework 4.7.2 ou posterior e que desejam preservar o comportamento de acessibilidade herdado podem optar pelo uso de recursos de acessibilidade herdados 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 sistema operacional quando o tema de Alto Contraste está selecionado. Anteriormente, as cores de texto e plano de fundo não eram contrastantes e eram difíceis de ler.
• Os controles contidos em um GroupBox que tem sua propriedade Enabled definida como false agora usarão cores definidas pelo sistema operacional no tema alto contraste.
• Os controles ToolStripButton, ToolStripComboBoxe ToolStripDropDownButton têm uma maior taxa de contraste de luminosidade no Modo de Alto Contraste.
• DataGridViewLinkCell usará, por padrão, cores definidas pelo sistema operacional no modo de Alto Contraste para a propriedade DataGridViewLinkCell.LinkColor. OBSERVAÇÃO: o Windows 10 alterou valores para algumas cores do sistema de alto contraste. O Windows Forms Framework é baseado na estrutura Win32. Para obter a melhor experiência, execute na versão mais recente do Windows e opte pelas alterações mais recentes do sistema operacional adicionando um arquivo app.manifest em um aplicativo de teste e cancelando o comentário do seguinte código:

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

Aprimoramento do suporte do 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.

suporte aprimorado à acessibilidade do DataGridView

• As linhas em um DataGridView agora podem ser classificadas usando o teclado. Agora, um usuário pode usar a chave 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 enquanto o usuário navega pelas células da linha atual.
• A propriedade DataGridViewCell.DataGridViewCellAccessibleObject.Parent agora retorna o controle pai correto.

Melhoria das Indicações visuais

• Os controles RadioButton e CheckBox com a propriedade Text vazia agora exibirão um indicador de foco quando receberem 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 da automação da interface do usuário, consulte a visão geral da automação da interface do usuário .

  Navegação de teclado aprimorada

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

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

Detalhes

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

Sugestão

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

• Ele tem como destino o .NET Framework 4.7.2. Essa alteração é habilitada por padrão em aplicativos do Windows Forms destinados ao .NET Framework 4.7.2 ou posterior.
• Ele tem como destino o .NET Framework 4.7.1 ou uma versão anterior e opta por não usar os comportamentos de acessibilidade herdados adicionando os seguintes AppContext Switch à seção <runtime> do arquivo app.config e definindo-o como false, como mostra o exemplo a seguir.

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

Aplicativos direcionados ao .NET Framework 4.7.2 ou posterior e que desejam preservar o comportamento herdado podem optar pelo uso do valor de controle do código-fonte herdado definindo explicitamente essa opção AppContext como true.

APIs afetadas

• ContextMenuStrip.SourceControl

O método PrivateFontCollection.AddFontFile libera 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+ após o descarte do PrivateFontCollection para objetos Font que são adicionados a esta 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 sair dessas alterações Para que um aplicativo se beneficie dessas alterações, ele deve ser executado no .NET Framework 4.7.2 ou posterior. O aplicativo pode se beneficiar dessas alterações de qualquer uma das seguintes maneiras:

• Ser recompilado para ser direcionado ao .NET Framework 4.7.2. Essa alteração é habilitada por padrão em aplicativos do Windows Forms destinados ao .NET Framework 4.7.2 ou posterior.
• Ele tem como destino o .NET Framework 4.7.1 ou uma versão anterior e opta por não usar os comportamentos de acessibilidade herdados adicionando os seguintes AppContext Switch à seção <runtime> do arquivo app.config e definindo-o como false, como mostra o exemplo a seguir.

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

Aplicativos direcionados ao .NET Framework 4.7.2 ou posterior e que desejam preservar o comportamento herdado podem optar por não liberar recursos de fonte definindo explicitamente essa opção AppContext como true.

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 do DomainUpDown.UpButton() é ignorada quando o texto do controle está presente, e o desenvolvedor é obrigado a usar a ação DomainUpDown.DownButton() no controle antes de usar a ação DomainUpDown.UpButton(). A partir do .NET Framework 4.7.2, as ações DomainUpDown.UpButton() e DomainUpDown.DownButton() funcionam independentemente nesse cenário e permanecem em sincronia.

Sugestão

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

• Ser recompilado para ser direcionado ao .NET Framework 4.7.2. Essa alteração é habilitada por padrão em aplicativos do Windows Forms destinados ao .NET Framework 4.7.2 ou posterior.
• Opta por não usar o comportamento de rolagem herdado adicionando o seguinte AppContext Switch na seção <runtime> do arquivo de configuração do aplicativo e configurando-o como false, conforme demonstra o exemplo a seguir.

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

APIs afetadas

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

Windows Presentation Foundation (WPF)

O foco do teclado agora se move corretamente entre várias camadas de hospedagem do WinForms/WPF

Detalhes

Considere um aplicativo WPF que hospeda um controle WinForms que, por sua vez, hospeda controles WPF. Talvez os usuários não consigam sair da camada WinForms se o primeiro ou o último controle nessa camada for o WPF System.Windows.Forms.Integration.ElementHost. Essa alteração corrige esse problema e os usuários agora podem sair da camada WinForms. Aplicativos automatizados que dependem do foco nunca escapam da camada WinForms podem não funcionar mais conforme o esperado.

Sugestão

Um desenvolvedor que deseja utilizar essa alteração ao direcionar uma versão do framework abaixo do .NET 4.7.2 pode definir o seguinte conjunto de flags 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 do WPF devem aceitar todas as melhorias de acessibilidade antecipadas para obter as melhorias posteriores. 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>

O algoritmo de hash padrão para o Compilador de Marcação do WPF agora é SHA256

Detalhes

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

Sugestão

Um desenvolvedor que tem como destino o .NET Framework 4.7.2 ou superior e deseja reverter para o comportamento de hash SHA1 deve definir o seguinte sinalizador AppContext.

<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 deve ser 4.7.2 ou superior.

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

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 pode potencialmente criar um System.Windows.Threading.Dispatcher no thread de finalização do .NET durante o encerramento 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 determinados aplicativos, essa alteração na temporização do finalizador pode potencialmente causar exceções durante o AppDomain ou o encerramento do processo. 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 versões posteriores, os desenvolvedores podem desabilitar essa correção para ajudar a aliviar (mas não eliminar) problemas de tempo que podem ocorrer devido à alteração de limpeza. Para desabilitar a alteração na limpeza, use o sinalizador AppContext a seguir.

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

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". Em seu aplicativo WPF, você pode associar um controle de lista aos detalhes de um 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 chave primária OrderID do item mestre. O ADO altera automaticamente o OrderID de cada um dos registros afetados na coleção Details (ou seja, os copiados para a 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. A ListBox continua a usar a coleção D, que agora está vazia.
• Novo comportamento: a coleção D está 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 maneira 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 a seguinte opção AppContext.

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

O padrão é true (comportamento antigo) para aplicativos destinados ao .NET 4.7.1 ou inferior e false (novo comportamento) para aplicativos destinados ao .NET 4.7.2 ou superior.

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

Detalhes

No .NET Framework 4.7.1 e versões anteriores, o WPF System.Windows.Controls.CheckBox e System.Windows.Controls.RadioButton têm visuais de foco inconsistentes e, em temas clássicos e de alto contraste, visuais de foco incorretos. Esses problemas ocorrem em casos em que os controles não têm nenhum conjunto de conteúdo. Isso pode tornar a transição entre temas confusa e o visual de foco difícil de ver. No .NET Framework 4.7.2, esses visuais agora são mais consistentes entre temas e mais facilmente visíveis em temas clássicos e de alto contraste.

Sugestão

Um desenvolvedor que está trabalhando com o .NET Framework 4.7.2 e deseja retornar ao comportamento do .NET 4.7.1 precisará definir o seguinte sinalizador AppContext.

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

Um desenvolvedor que deseja utilizar essa alteração ao direcionar uma versão da estrutura abaixo do .NET 4.7.2 deve definir os seguintes sinalizadores AppContext. Observe que todos os sinalizadores devem ser definidos adequadamente e a versão instalada do .NET Framework deve ser 4.7.2 ou superior. Os aplicativos WPF são necessários para aceitar todas as melhorias de acessibilidade anteriores para obter as melhorias mais recentes. Para fazer isso, verifique se os interruptores do AppContext 'Switch.UseLegacyAccessibilityFeatures' e 'Switch.UseLegacyAccessibilityFeatures.2' estão definidos como false.

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

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

Detalhes

No .NET Framework 4.7.1 e nas versões anteriores, o WPF System.Windows.Controls.TextBox e System.Windows.Controls.PasswordBox só poderiam renderizar uma seleção de texto na camada adorno. Em alguns temas do sistema, isso ocluiria o texto, dificultando a leitura. No .NET Framework 4.7.2 e posterior, os desenvolvedores têm a opção de habilitar um esquema de renderização de seleção não baseado em Adorner que alivia esse problema.

Sugestão

Um desenvolvedor que deseja utilizar essa alteração deve definir o seguinte sinalizador 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>

Windows Workflow Foundation (WF)

Evitando a recursão sem fim 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 ocorrerá se a instância de fluxo de trabalho estiver em um estado em que está aguardando a conclusão de alguma outra solicitação WCF pendente 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 de TransactedCancel/TransactedTerminate. Como a instância do serviço de fluxo de trabalho está ocupada aguardando a conclusão da outra solicitação WCF pendente, o item de trabalho criado permanece na fila. A operação de TransactedCancel/TransactedTerminate é concluída e o controle é retornado de volta 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 se confirme sem esperar que a instância do fluxo de trabalho persista. 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 desse AppSetting é false, portanto, as instâncias de serviço de 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 você não estiver encontrando o problema, não precisará fazer isso.