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

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

.NET Framework 4.7

ASP.NET

HttpRuntime.AppDomainAppPath lança uma NullReferenceException

Detalhes

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

Sugestão

Você pode seguir um destes procedimentos para responder a essa alteração:

• Manipule o T:System.NullReferenceException se seu aplicativo estiver sendo executado 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 anteriores, o 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 demorar muito tempo para responder, ela degradará significativamente o desempenho do servidor apenas pressionando F5 no navegador. Na correção, adicionamos um contador para rastrear as solicitações enfileiradas 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 seu arquivo de web.config para desativar o novo comportamento.

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

Ligação em rede

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

Detalhes

Começando com 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 codificados 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 operativo Windows, consulte Protocolos em TLS/SSL (SSP Schannel).

Sugestão

Essa alteração afeta os aplicativos destinados ao .NET Framework 4.7 ou versões posteriores. Se preferir usar um protocolo definido em vez de confiar no padrão do sistema, você pode definir explicitamente o valor da propriedade ServicePointManager.SecurityProtocol. Se essa alteração for indesejável, você pode desativá-la adicionando uma definição de configuração à seção de tempo de execução do arquivo de configuração do aplicativo. O exemplo a seguir mostra a seção <runtime> e a opção de exclusão Switch.System.Net.DontEnableSystemDefaultTlsVersions:

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

APIs afetadas

• ServicePointManager.SecurityProtocol

SslStream suporta alertas TLS

Detalhes

Após um handshake TLS com falha, um System.IO.IOException com uma exceção de 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 para o System.ComponentModel.Win32Exception pode ser mapeado para o Alerta TLS da parte remota usando os códigos de erro Schannel para alertas TLS e SSL. Para obter mais informações, consulte RFC 2246: Secção 7.2.2 Alertas de erro.
O comportamento no .NET Framework 4.6.2 e anteriores é que o canal de transporte (geralmente conexão TCP) expirará durante a gravação ou leitura se a outra parte falhou o handshake e imediatamente depois rejeitou a conexão.

Sugestão

Os 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 a partir do .NET Framework 4.7. Os 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 o .NET Framework 4.6 e aplicativos posteriores executados no .NET Framework 4.7 ou posterior.

• Programaticamente: Deve ser a primeira coisa que o aplicativo faz, já que 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 (máquina global): 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 uma aplicação registe um valor de identificador de janela pai de tal forma que qualquer interface do utilizador necessária para aceder à chave (como um prompt de PIN ou caixa de diálogo de consentimento) seja aberta como uma janela modal secundária à janela especificada. A partir de aplicações direcionadas ao .NET Framework 4.7, uma aplicação do Windows Forms pode definir a propriedade ParentWindowHandle com o seguinte código:

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 onde residia o valor de HWND. Definindo a propriedade como forma. Handle no Windows 7 e versões anteriores não teve efeito, mas no Windows 8 e versões posteriores, resulta em um "System.Security.Cryptography.CryptographicException: O parâmetro está incorreto."

Sugestão

As aplicações destinadas ao .NET Framework 4.7 ou superior que pretendem registar uma relação de janela pai são incentivadas a usar a forma simplificada:

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 continha o valor form.Handle podem desativar a alteração de comportamento definindo a opção AppContext Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle como true:

• Ao definir programaticamente comutadores de compatibilidade no AppContext, conforme explicado em Anúncios do .NET na Build 2015.
• Adicionando a seguinte linha à 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 tempo de execução 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

SslStream suporta alertas TLS

Detalhes

Após um handshake TLS com falha, um System.IO.IOException com uma exceção de 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 para o System.ComponentModel.Win32Exception pode ser mapeado para o Alerta TLS da parte remota usando os códigos de erro Schannel para alertas TLS e SSL. Para obter mais informações, consulte RFC 2246: Secção 7.2.2 Alertas de erro.
O comportamento no .NET Framework 4.6.2 e anteriores é que o canal de transporte (geralmente conexão TCP) expirará durante a gravação ou leitura se a outra parte falhou o handshake e imediatamente depois rejeitou a conexão.

Sugestão

Os 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 a partir do .NET Framework 4.7. Os 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 o .NET Framework 4.6 e aplicativos posteriores executados no .NET Framework 4.7 ou posterior.

• Programaticamente: Deve ser a primeira coisa que o aplicativo faz, já que 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 (máquina global): 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 serializava alguns caracteres de controle especiais, como \b, \f e \t, de 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 destinados ao .NET Framework 4.7, esse recurso é habilitado por padrão. Se esse comportamento não for desejável, você pode desativar 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)

Segurança de mensagem WCF agora é capaz de usar TLS1.1 e TLS1.2

Detalhes

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

Sugestão

No .NET Framework 4.7, o suporte para TLS1.1 e TLS1.2 na segurança de mensagens 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 poderão lançar uma ArgumentException

Detalhes

Em algumas circunstâncias, chamadas para o método interno System.Windows.Input.PenContext.Disable em sistemas sensíveis ao toque podem lançar um T:System.ArgumentException não tratado 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.

Exceção NullReferenceException no código de gestão 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 lançado 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 lance a exceção correta.

Por padrão, todos os aplicativos destinados ao .NET Framework 4.6.2 e versões anteriores continuam a lançar System.NullReferenceException para compatibilidade. Os desenvolvedores que estejam a trabalhar com o .NET Framework 4.7 e posterior devem ver as exceções corretas.

Sugestão

Os programadores que desejam reverter para obter System.NullReferenceException ao direcionar o .NET Framework 4.7 ou posterior podem adicionar ou mesclar o seguinte ao ficheiro App.config da sua aplicação:

<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 em grade do WPF para colunas em estrela

Detalhes

A partir do .NET Framework 4.7, o WPF substitui o algoritmo que Grid usa para alocar espaço para colunas *. Isso alterará a largura real atribuída às colunas * 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 declaram um peso extremamente grande, maior que 10^298.
• Quando os pesos-* são suficientemente diferentes para encontrar instabilidade de ponto flutuante (transbordamento, subfluxo, 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 daquelas produzidas pelo algoritmo antigo; No último caso, a diferença será de no máximo um ou dois pixels.

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

• A alocação total nas colunas pode exceder a largura da grelha. Isso pode ocorrer ao alocar espaço para uma coluna cuja participação proporcional é menor do 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 colunas * restantes para alocar, a alocação total será excessivamente grande.

• A alocação total pode ficar aquém da largura da Grid. Este é o duplo problema para #1, que surge ao alocar para uma coluna cuja participação proporcional é maior do que seu tamanho máximo, sem colunas *-restantes para ocupar a folga.

• Duas *-colunas podem receber alocações não proporcionais aos seus *-pesos. Esta é uma versão mais suave de #1/#2, que surge quando se aloca às colunas A, B e C (nessa ordem), onde a quota proporcional de B viola a sua restrição mínima (ou máxima). Como acima, isso altera o espaço disponível para a coluna C, que recebe menos (ou mais) alocação proporcional do que A.

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

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

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

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

  • A largura real atribuída a uma coluna * nunca é inferior à sua largura mínima nem superior à sua largura máxima.
  • A cada coluna *, à qual não é atribuída a sua largura mínima ou máxima, é atribuída uma largura proporcional ao seu *-peso. Para ser preciso, se duas colunas são declaradas com largura x* e y* respectivamente, e se nenhuma coluna recebe sua largura mínima ou máxima, as larguras reais v e w atribuídas às colunas estã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, automáticas e *-colunas que são alocadas com a sua largura mínima ou máxima). Isso pode ser zero, por exemplo, se a soma das larguras mínimas exceder a largura disponível da grade.
  • Todas estas afirmaçõ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 começando com o .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 WPF Pointer-Based

Detalhes

Essa alteração adiciona a capacidade de habilitar uma pilha opcional baseada em WM_POINTER para toque/caneta no WPF. Os desenvolvedores que não habilitam isso explicitamente não devem ver nenhuma alteração no comportamento de toque/caneta do WPF. Problemas conhecidos atuais com pilha de toque/caneta opcional baseada em WM_POINTER:

• Sem suporte para escrita digital em tempo real.
• Embora a tinta digital e o StylusPlugins ainda funcionem, eles serão processados no thread da interface do usuário, o que pode levar a um desempenho ruim.
• Mudanças comportamentais devido a mudanças na promoção de eventos de toque/caneta para eventos com mouse
• A manipulação pode agir de forma diferente
• Arrastar e largar não mostrará o feedback apropriado para a entrada tátil
• Isso não afeta a entrada da 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 detetada.
• Em vez disso, os desenvolvedores devem iniciar o recurso de arrastar e soltar a partir de eventos do mouse.

Sugestão

Os desenvolvedores que desejam habilitar esta pilha podem adicionar/mesclar o seguinte ao ficheiro App.config da sua aplicação:

<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 superior.

Windows Workflow Foundation (WF)

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

Detalhes

Para dar suporte à depuração com o Visual Studio, o tempo de execução do Workflow 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 causava problemas em sistemas com FIPS ativado. Começando com o .NET Framework 4.7, o algoritmo é SHA1. Se o seu código tiver armazenado esses checksums, 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 de soma de verificação, tente definir a opção de AppContext "Switch.System.Activities.UseMD5ForWFDebugger" como true. No código:

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

Ou na configuração:

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

.NET Framework 4.7.1

ASP.NET

ASP.NET Melhorias de acessibilidade no .NET Framework 4.7.1

Detalhes

A partir do .NET Framework 4.7.1, o ASP.NET melhorou o funcionamento dos Controlos Web ASP.NET com tecnologia de acessibilidade no Visual Studio, a fim de oferecer melhor suporte aos clientes ASP.NET. Estas incluem as seguintes alterações:

• Alterações para implementar padrões de acessibilidade da interface do usuário ausentes nos controles, como a caixa de diálogo Adicionar campo no assistente para 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 pelo 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 não 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 uma das seguintes maneiras:

• Instale o Visual Studio 2017 15.3 ou posterior, que, por padrão, oferece suporte aos novos recursos de acessibilidade com o seguinte alternador AppContext.
• Desative os comportamentos de acessibilidade herdados adicionando a opção Switch.UseLegacyAccessibilityFeatures AppContext à seção <runtime> no arquivo devenv.exe.config e definindo-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>

Os aplicativos destinados ao .NET Framework 4.7.1 ou posterior e 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 em segundo plano SerialPort

Detalhes

Os threads em segundo plano criados com fluxos de SerialPort não encerram mais o processo quando exceções do sistema operacional são lançadas.
Em aplicativos destinados ao .NET Framework 4.7 e versões anteriores, um processo é encerrado quando uma exceção do sistema operacional é lançada em um thread em segundo plano criado com um fluxo de SerialPort.
Em aplicativos destinados ao .NET Framework 4.7.1 ou uma versão posterior, os threads em segundo plano aguardam eventos do sistema operacional relacionados à porta serial ativa e podem falhar em alguns casos, como a remoção repentina da porta serial.

Sugestão

Para aplicativos destinados ao .NET Framework 4.7.1, você pode desativar o tratamento de exceções se não for desejável, adicionando o seguinte à seção <runtime> do seu arquivo de 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 pelo tratamento de exceções adicionando o seguinte à seção <runtime> do seu 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 lançadas na inicialização do serviço não são propagadas para o chamador de ServiceBase.Run.

Começando com aplicações destinadas ao .NET Framework 4.7.1, o runtime propaga exceções para o ServiceBase.Run para serviços que falham em 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ê pode desativá-lo adicionando o seguinte elemento AppContextSwitchOverrides à seção runtime do arquivo de configuração do aplicativo:

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

Se o seu aplicativo se destina a uma versão anterior à 4.7.1, mas você deseja 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

Os algoritmos padrão SignedXML e SignedXMS foram alterados para SHA256.

Detalhes

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

Sugestão

Há dois novos valores de comutador 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 destinados ao .NET Framework 4.7.1 e versões posteriores, se o uso de SHA256 for indesejável, você poderá restaurar o padrão para SHA1 adicionando a seguinte opção de configuração à seção de tempo de execução do arquivo de configuração do 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 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 no net462 (ou lightup) sem alterar o redirecionamento

Detalhes

A partir do .NET Framework 4.6.2, o tipo concreto do objeto retornado pelo método SignedXml.GetPublicKey mudou (sem uma peculiaridade) de uma implementação CryptoServiceProvider para uma implementação Cng. Isso ocorre porque a implementação mudou de usar certificate.PublicKey.Key para usar o certificate.GetAnyPublicKey interno que encaminha para RSACertificateExtensions.GetRSAPublicKey.

Sugestão

Começando com aplicativos executados 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 melhorada para algumas ferramentas do SDK do .NET

Detalhes

No .NET Framework SDK 4.7.1, as ferramentas SvcConfigEditor.exe e SvcTraceViewer.exe foram melhoradas corrigindo vários problemas de acessibilidade. A maioria deles eram pequenos problemas, como um nome não sendo definido ou certos 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 assistenciais, como leitores de tela, acharão essas ferramentas 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, pode adicionar o seguinte ao seu arquivo app.config:

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

Formulários do Windows

Melhorias de acessibilidade nos controles do Windows Forms

Detalhes

O Windows Forms está a melhorar a forma como funciona com tecnologias de acessibilidade para melhor suportar os clientes do Windows Forms. Elas incluem as seguintes alterações começando com o .NET Framework 4.7.1:

• Alterações para melhorar o ecrã 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 por teclado através das várias janelas de seleção suspensas.
• Redução de paradas de tabulação desnecessárias.
• Melhoria na comunicação dos tipos de controlo.
• Comportamento melhorado do narrador.
• Alterações para implementar padrões de acessibilidade da interface do usuário ausentes nos controles.

Sugestão

Como aceitar ou não 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 uma das seguintes maneiras:

• Foi recompilado para ter como alvo o .NET Framework 4.7.1. Essas alterações de acessibilidade são habilitadas por padrão em aplicativos Windows Forms destinados ao .NET Framework 4.7.1 ou posterior.
• Ele desativa 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>

Os aplicativos destinados ao .NET Framework 4.7.1 ou posterior e 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 .

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 de invocação comuns 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 podem usar seu método QueryService para solicitar uma interface IAccessibleEx. Para obter mais informações, consulte Usando 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 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 suportam o padrão Expandir/Recolher.

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

• O controlo ToolStripItem suporta a propriedade NameProperty e o padrão Expandir/Recolher.

• O controlo ToolStripDropDownItem suporta AccessibleEvents indicando alteração de estado e alteração de nome quando o menu suspenso é expandido ou recolhido.

• O controle ToolStripDropDownButton tem um valor de propriedade ControlType de ControlType.MenuItem.

• O controle DataGridViewCheckBoxCell suporta o TogglePattern.

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

  Melhorias no controle PropertyGrid O .NET Framework 4.7.1 adiciona os seguintes aprimoramentos ao controle PropertyBrowser:

• O botão Detalhes na caixa de diálogo de erro que é exibido quando o usuário insere um valor incorreto no controle suporta o padrão Expandir/Recolher, notificações de alteração de estado e nome e uma propriedade ControlType com um valor de .

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

• O AccessibleRole de linhas no controlo PropertyGrid foi alterado de "Linha" para "Célula". A célula é mapeada para o tipo de controlo UIA "DataItem", o que lhe possibilita suportar atalhos de teclado apropriados e anúncios do Narrador.

• As linhas de controlo PropertyGrid que representam itens de cabeçalho têm, quando o controlo PropertyGrid possui uma propriedade PropertySort definida como PropertySort.Categorized, um valor de propriedade ControlType de ControlType.Button.

• As linhas de controle PropertyGrid que representam itens de cabeçalho quando o controle PropertyGrid tem uma propriedade PropertySort definida para PropertySort.Categorized suportam o padrão Expandir/Recolher.

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

• PropertyGrid controles exibidos no modo Alto Contraste agora desenharão um retângulo de foco ao redor do botão Barra de Ferramentas que corresponde ao valor atual da propriedade PropertySort.

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

• PropertyGrid controles diferencia melhor entre os itens da Barra de Ferramentas com foco e os 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 uma alteração para cenários que não sejam de Alto Contraste.

• Os itens de controlo da Barra de Ferramentas PropertyGrid, que indicam o valor atual da propriedade PropertySort, suportam o TogglePattern.

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

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

Uso de cores definidas pelo sistema operacional em temas de alto contraste

• Os controles Button e CheckBox com sua propriedade FlatStyle definida como FlatStyle.System, que é o estilo padrão, agora usam cores definidas pelo SO no tema Alto Contraste quando selecionado. Anteriormente, o texto e as cores de fundo não eram contrastantes e eram difíceis de ler.
• Os controles Button, CheckBox, RadioButton, Label, LinkLabele GroupBox com sua propriedade Enabled definida como falso usavam uma cor sombreada para renderizar texto em temas de Alto Contraste, resultando em baixo contraste contra o plano de fundo. Agora, esses controles usam a cor "Texto desativado" 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 ao redor do conteúdo da célula que tem o foco atual. Anteriormente, isso não era visível em certos temas de Alto Contraste.
• ToolStripMenuItem controles com sua propriedade Enabled definida como false agora usam a cor "Texto desativado" definida pelo sistema operacional.
• ToolStripMenuItem controles com sua propriedade Checked definida como true agora renderizam a marca de seleção associada em uma cor contrastante do sistema. Anteriormente, a cor da marca de seleção não tinha contraste suficiente e não era visível em temas de Alto Contraste. NOTA: O Windows 10 alterou os valores de algumas cores de sistema de alto contraste. 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 descomentando o seguinte código:

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

Navegação por teclado melhorada

• Quando um controle ComboBox tem sua propriedade DropDownStyle definida como ComboBoxStyle.DropDownList e é o primeiro controle na ordem de tabulação no formulário, ele agora 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.

Suporte melhorado do Narrador

• O controle MonthCalendar adicionou suporte para tecnologias assistivas para acessar o controle, incluindo a capacidade do Narrador de ler o valor do controle quando anteriormente não podia.

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

• O controle LinkLabel mudou a maneira como notifica o Narrador sobre o texto do no controle. Anteriormente, o Narrador anunciou este texto duas vezes e leu os símbolos "&" como texto real, mesmo que eles não sejam visíveis para um usuário. O texto duplicado foi removido dos anúncios do Narrador, bem como os símbolos "&" desnecessários.

• Os tipos de controlo DataGridViewCell agora relatam corretamente o estado de só leitura ao Narrador e a outras tecnologias de apoio.

• O Narrador agora é capaz de ler o Menu do Sistema de janelas-filho em [Multiple-Document Interface]~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md) aplicações.

• O Narrador agora é capaz de ler ToolStripMenuItem controles com uma propriedade ToolStripItem.Enabled definida como false. Anteriormente, o Narrador não conseguia se concentrar em itens de menu desativados 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 no alto contraste

• O foco para o controle de Expander agora é visível. Em versões anteriores do .NET Framework, não era.
• O texto nos controles CheckBox e RadioButton quando eles são selecionados agora é mais fácil de ver do que em versões anteriores do .NET Framework.
• A borda de um ComboBox desativado agora é da mesma cor do texto desativado. Em versões anteriores do .NET Framework, não era.
• Os botões desativados e focados agora usam a cor correta do tema. Em versões anteriores do .NET Framework, eles não funcionavam.
• O botão suspenso agora fica visível quando o estilo de um controle ComboBox é definido como ToolBar.ComboBoxStyleKey. Em versões anteriores do .NET Framework, não era.
• A seta do indicador de ordenação num controlo DataGrid agora utiliza cores de tema. Em versões anteriores do .NET Framework, isso não acontecia.
• O estilo de hiperlink padrão agora muda para a cor correta do tema ao passar o mouse. Em versões anteriores do .NET Framework, isso não acontecia.
• O foco do teclado nos botões de rádio agora está visível. Em versões anteriores do .NET Framework, não era.
• A coluna da caixa de seleção do controle DataGrid agora usa as cores esperadas para comentários sobre o foco do teclado. Em versões anteriores do .NET Framework, isso não acontecia.
• Os elementos visuais de foco do teclado agora são visíveis nos controlos ComboBox e ListBox. Em versões anteriores do .NET Framework, não era.

Melhorias na interação do leitor de tela

• Expander controles agora são anunciados corretamente como grupos (expandir/recolher) pelos leitores de tela.
• Os controlos DataGridCell agora são anunciados corretamente como célula de grelha de dados (localizada) pelos leitores de ecrã.
• Os leitores de ecrã agora anunciarão o nome de um elemento ComboBoxeditável.
• PasswordBox controles não são mais anunciados como "nenhum item em exibição" pelos leitores de tela.

Suporte LiveRegion

Os leitores de tela, como o Narrador, ajudam as pessoas a entender a interface do usuário (UI) de um aplicativo, geralmente descrevendo o elemento da interface do usuário que atualmente tem foco. No entanto, se um elemento da interface do usuário mudar em algum lugar na tela e não tiver o foco, o usuário pode não ser informado e perder informações importantes. LiveRegions destinam-se a resolver este problema. Um desenvolvedor pode usá-los para informar o leitor de tela ou qualquer outro cliente UI Automation que uma alteração importante foi feita em um elemento da interface do usuário. O leitor de ecrã pode então decidir como e quando informar o utilizador desta alteração. A propriedade LiveSetting também permite que o Leitor de Tela saiba o quão importante é informar o utilizador sobre alterações na interface.

Sugestão

Como optar por participar ou não destas 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 uma das seguintes maneiras:

• Destinar o .NET Framework 4.7.1. Esta é 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.

• Ele desativa os comportamentos de acessibilidade herdados adicionando o seguinte AppContext Switch na 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" />
    </runtime>
  </configuration>
  

Os aplicativos destinados 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 Seletor SelectionChanged e propriedade SelectedValue

Detalhes

A partir do .NET Framework 4.7.1, um Selector sempre atualiza o valor de sua propriedade SelectedValue antes de gerar 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 aconteceu antes do evento na maioria dos casos, mas aconteceu depois do evento se a alteração de seleção foi causada pela alteração da propriedade SelectedValue.

Sugestão

Os aplicativos destinados ao .NET Framework 4.7.1 ou posterior podem desativar 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>

Os aplicativos destinados ao .NET Framework 4.7 ou anterior, mas 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 SelectionChanged do TabControl e Propriedade SelectedContent

Detalhes

A partir do .NET Framework 4.7.1, um TabControl atualiza o valor de sua propriedade SelectedContent antes de gerar o evento SelectionChanged, quando sua seleção é alterada. No .NET Framework 4.7 e versões anteriores, a atualização para SelectedContent aconteceu após o evento.

Sugestão

Os aplicativos destinados ao .NET Framework 4.7.1 ou posterior podem desativar 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>

Os aplicativos destinados ao .NET Framework 4.7 ou anterior, mas 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 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 começando com o .NET Framework 4.7.1. Essa alteração afeta toda a assinatura 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 seguinte sinalizador AppContext apropriadamente. Um valor true 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 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 a esquerda para a direita e de cima para baixo em alguns controles:
• A janela de correlação para inicializar os 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 através do teclado:
• Ao editar as propriedades de uma atividade, os grupos de propriedades podem ser recolhidos pelo teclado na primeira vez que forem selecionados.
• Os ícones de aviso agora estão acessíveis pelo teclado.
• O botão Mais Propriedades na janela Propriedades agora está acessível pelo teclado.
• Os usuários do teclado agora podem acessar os itens de cabeçalho nos painéis Argumentos e Variáveis do Designer de Fluxo de Trabalho.
• Melhor visibilidade de itens com foco em casos como:
• Adicionar linhas a grades de dados usadas pelo Designer de Fluxo de Trabalho e designers de atividades.
• Navegação pelos 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>, FlowDecisione CorrelationScope.
• O conteúdo da atividade Receive.
• O Tipo de Destino para a 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 CorrelatesOn Defintion nas atividades de mensagens (Receive, Send, SendReplye ReceiveReply).
• Transições de máquina de estado e destinos de transições.
• Anotações e conectores nas 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 Por categoria e Classificação alfabética e a caixa de diálogo Editor de expressões na grade de propriedades.
• A porcentagem de zoom no Designer de Fluxo de Trabalho.
• O separador nas atividades Parallel e Pick.
• A InvokeDelegate atividade.
• 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 Tipo .NET.
• 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 relações de contraste entre elementos e caixas de seleção mais percetíveis usadas para elementos de foco.

Sugestão

Se você tiver um aplicativo com um designer de fluxo de trabalho rehospedado, 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 tem como alvo o .NET Framework 4.7 ou anterior, mas está sendo executado no .NET Framework 4.7.1, você pode desativar esses comportamentos de acessibilidade herdados adicionando a seguinte opção AppContext à seção <runtime> do arquivo app.config e defini-lo 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 posterior e 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 bidirecionais Unicode em URIs

Detalhes

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 todos os URIs, mesmo que estivessem presentes em sua forma codificada por porcentagem. Para melhor seguir RFC 3987, agora permitimos esses caracteres em URIs. Quando encontrados não codificados em um URI, eles são codificados em porcentagem. Quando encontrados codificados percentualmente, eles são deixados as-is.

Sugestão

Para aplicativos destinados a versões do .NET Framework a partir da 4.7.2, o suporte para caracteres bidirecionais Unicode é habilitado por padrão. Se esta alteração for indesejável, pode desativá-la adicionando o seguinte comutador AppContextSwitchOverrides à seção <runtime> do ficheiro de configuração da aplicação.

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

Para aplicativos destinados a versões anteriores do .NET Framework, mas que estão sendo executados em versões que começam com o .NET Framework 4.7.2, o suporte para caracteres bidirecionais Unicode é desabilitado por padrão. Você pode habilitá-lo adicionando a seguinte chave AppContextSwitchOverrides à secção <runtime> do ficheiro de configuração da aplicação:

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

APIs afetadas

• System.Uri

O 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 melhoria substancial de desempenho. Todos os aplicativos .NET destinados ao .NET Framework versão 4.7.2 ou superior usam a implementação nativa. Esta alteração pode resultar em algumas diferenças de comportamento, que incluem:

• As mensagens de exceção podem ser diferentes. No entanto, o tipo de exceção lançada 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.
• Existem diferenças conhecidas na análise do cabeçalho gzip (observação: apenas o GZipStream configurado para descompactação é afetado):
• Exceções ao processar cabeçalhos inválidos podem ocorrer em momentos diferentes.
• A implementação nativa impõe que os valores para 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 lance uma exceção onde 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á desativar esse recurso adicionando a opção de Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression à seção runtime do seu arquivo de app.config e definindo-a 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 reservados consistente

Detalhes

Em System.Uri, certos caracteres codificados por porcentagem que às vezes eram decodificados agora são mantidos consistentemente codificados. Isso ocorre nas propriedades e métodos que acessam os componentes path, query, fragment ou userinfo do URI. O comportamento mudará somente quando ambos os itens a seguir forem verdadeiros:

• O URI contém a forma codificada de qualquer um dos seguintes caracteres reservados: :, ', (, ), ! ou *.
• O URI contém um caractere Unicode ou codificado não reservado. Se ambos os itens acima forem verdadeiros, os caracteres reservados codificados serão deixados codificados. Em versões anteriores do .NET Framework, eles são decodificados.

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 esta alteração for indesejável, pode desativá-la adicionando o seguinte comutador AppContextSwitchOverrides à seção <runtime> do ficheiro de configuração da aplicação.

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

Para aplicativos destinados a versões anteriores do .NET Framework, mas que estão sendo executados em versões que começam com o .NET Framework 4.7.2, o novo comportamento de decodificação é desabilitado por padrão. Você pode habilitá-lo adicionando a seguinte chave AppContextSwitchOverrides à secção <runtime> do ficheiro de configuração da aplicação:

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

APIs afetadas

• System.Uri

A Resgen se recusa a carregar conteúdo da Web

Detalhes

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

Sugestão

Os utilizadores do Resgen que precisam carregar entradas binárias formatadas de locais não confiáveis podem remover a marca da Web do arquivo de entrada ou aplicar a funcionalidade de desativação. Adicione a seguinte configuração do Registro para aplicar a funcionalidade de exclusão em toda a máquina: [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 linha, se solicitado.

Detalhes

A partir do .NET Framework 4.7.2, os rastreamentos de pilha obtidos ao usar PDBs portáteis incluem informações de arquivo de origem e linha quando solicitado. Em versões anteriores ao .NET Framework 4.7.2, o arquivo de origem e as informações de linha não estariam disponíveis ao usar PDBs portáteis, mesmo se explicitamente solicitados.

Sugestão

Para aplicativos destinados ao .NET Framework 4.7.2, você pode desativar o arquivo de origem e as informações de linha ao usar PDBs portáteis se isso não for desejável, adicionando o seguinte à seção <runtime> do seu arquivo app.config:

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

Para aplicações destinadas a versões anteriores do .NET Framework, mas executadas no .NET Framework 4.7.2 ou posterior, pode-se optar por incluir as informações do ficheiro de origem e da linha ao utilizar PDBs portáteis, adicionando o seguinte à seção <runtime> do seu ficheiro app.config:

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

APIs afetadas

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

Formulários do Windows

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

Detalhes

O Windows Forms Framework está melhorando a forma como funciona com tecnologias de acessibilidade para oferecer melhor suporte aos clientes do Windows Forms. Estas incluem as seguintes alterações:

• Alterações para melhorar o ecrã 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 não essas 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 uma das seguintes maneiras:

• Ele é recompilado para direcionar o .NET Framework 4.7.2. Essas alterações de acessibilidade são habilitadas por padrão em aplicativos Windows Forms destinados ao .NET Framework 4.7.2 ou posterior.
• Ele tem como alvo o .NET Framework 4.7.1 ou versão anterior e desativa os comportamentos de acessibilidade herdados adicionando o seguinte 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. Os aplicativos destinados ao .NET Framework 4.7.2 ou posterior e 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 Alto contraste.
• Button, RadioButton e CheckBox controles com FlatStyle definidos como FlatStyle.Flat ou FlatStyle.Popup agora usam cores definidas pelo SO no tema Alto Contraste quando selecionado. Anteriormente, o texto e as cores 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 SO no tema Alto Contraste.
• Os controles ToolStripButton, ToolStripComboBoxe ToolStripDropDownButton têm uma relação de contraste de luminosidade aumentada no Modo de Alto Contraste.
• DataGridViewLinkCell usará, por padrão, cores definidas pelo sistema operacional no modo Alto Contraste para a propriedade DataGridViewLinkCell.LinkColor. NOTA: O Windows 10 alterou os valores de algumas cores de sistema de alto contraste. 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 descomentando o seguinte código:

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

Suporte melhorado do Narrador

• O Narrador agora anuncia o valor da propriedade ToolStripMenuItem.ShortcutKeys ao anunciar o texto de um ToolStripMenuItem.
• O Narrador agora indica quando um ToolStripMenuItem tem a sua propriedade Enabled definida como false.
• O Narrador 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 Narrador agora é consistente com a ordem visual dos controles na janela de diálogo de download do ClickOnce.

Suporte de Acessibilidade melhorado para o DataGridView

• As linhas de um 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 estiver definido como DataGridViewSelectionMode.FullRowSelect, o cabeçalho da coluna mudará de cor para indicar a coluna atual à medida que o usuário percorre as células na linha atual.
• A propriedade DataGridViewCell.DataGridViewCellAccessibleObject.Parent agora retorna o controle pai correto.

Indicadores visuais melhorados

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

Suporte melhorado à Grelha de Propriedades

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

• Os elementos filho de 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 por teclado melhorada

• 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 controlo válido no caso de ToolStripMenuItems aninhados

Detalhes

No .NET Framework 4.7.1 e versões anteriores, a propriedade ContextMenuStrip.SourceControl retorna incorretamente null quando o usuário abre o menu de controles ToolStripMenuItem aninhados. No .NET Framework 4.7.2 e posterior, a SourceControl propriedade está sempre definida para o controle de origem real.

Sugestão

Como aceitar ou não essas 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 uma das seguintes maneiras:

• Ele tem como alvo o .NET Framework 4.7.2. Essa alteração é habilitada por padrão em aplicativos Windows Forms destinados ao .NET Framework 4.7.2 ou posterior.
• Ele tem como alvo o .NET Framework 4.7.1 ou uma versão anterior e exclui os comportamentos de acessibilidade herdados adicionando o seguinte 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>

Os aplicativos destinados ao .NET Framework 4.7.2 ou posterior e desejam preservar o comportamento herdado podem optar pelo uso do valor de controle de origem 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 versões anteriores, a classe System.Drawing.Text.PrivateFontCollection não liberta os recursos de fonte GDI+ após o PrivateFontCollection ser eliminado para Font objetos 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 não essas 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 uma das seguintes maneiras:

• Ele é recompilado para direcionar o .NET Framework 4.7.2. Essa alteração é habilitada por padrão em aplicativos Windows Forms destinados ao .NET Framework 4.7.2 ou posterior.
• Ele tem como alvo o .NET Framework 4.7.1 ou uma versão anterior e exclui os comportamentos de acessibilidade herdados adicionando o seguinte 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>

Os aplicativos destinados ao .NET Framework 4.7.2 ou posterior e 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 dos botões para cima e para baixo do domínio no WinForm estão sincronizadas agora.

Detalhes

No .NET Framework 4.7.1 e versões anteriores, a ação DomainUpDown do controlo DomainUpDown.UpButton() é ignorada quando o texto do controlo está presente, e o desenvolvedor é obrigado a usar a ação DomainUpDown.DownButton() no controlo 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 de forma independente nesse cenário e permanecem sincronizadas.

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 uma das seguintes maneiras:

• Ele é recompilado para direcionar o .NET Framework 4.7.2. Essa alteração é habilitada por padrão em aplicativos Windows Forms destinados ao .NET Framework 4.7.2 ou posterior.
• Ele desativa o comportamento de rolagem herdado adicionando o seguinte AppContext Switch à seção <runtime> do arquivo de configuração do aplicativo e definindo-o como false, como mostra 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 em várias camadas de hospedagem WinForms/WPF

Detalhes

Considere um aplicativo WPF que hospeda um controle WinForms que, por sua vez, hospeda controles WPF. Os usuários podem não ser capazes de sair da camada WinForms se o primeiro ou ú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 escapando da camada WinForms podem não funcionar mais como esperado.

Sugestão

Um desenvolvedor que deseja utilizar essa alteração ao direcionar uma versão da estrutura abaixo do .NET 4.7.2 pode definir o seguinte conjunto de sinalizadores 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 devem optar por todas as primeiras melhorias de acessibilidade para obter as melhorias posteriores. Em outras palavras, as opções Switch.UseLegacyAccessibilityFeatures e Switch.UseLegacyAccessibilityFeatures.2 devem ser definidas. Um desenvolvedor que requer a funcionalidade anterior ao direcionar o .NET 4.7.2 ou superior pode definir o seguinte sinalizador 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 começando com o .NET Framework 4.7.2. Essa alteração afeta toda a geração de checksums de arquivos de markup durante a compilação.

Sugestão

Um desenvolvedor que tenha como alvo o .NET Framework 4.7.2 ou superior e queira 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>

Um desenvolvedor que deseja utilizar hashing SHA256 quando tiver como alvo uma versão do .NET inferior a 4.7.2 deve definir o sinalizador 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>

O manuseamento de encerramento do AppDomain em WPF pode agora chamar Dispatcher.Invoke na limpeza de eventos fracos.

Detalhes

No .NET Framework 4.7.1 e versões anteriores, o WPF possivelmente cria um System.Windows.Threading.Dispatcher na thread do finalizador do .NET durante o encerramento do AppDomain. Isso foi corrigido no .NET Framework 4.7.2 e versões posteriores, tornando a limpeza de eventos fracos sensível a threads. Devido a isso, o WPF pode chamar Dispatcher.Invoke para concluir o processo de limpeza. Em determinados aplicativos, essa alteração no tempo do finalizador pode potencialmente causar exceções durante o AppDomain ou o desligamento do processo. Isso é geralmente observado em aplicações que não encerram corretamente os dispatchers que estão em execução em threads de trabalho antes de o processo ou o AppDomain ser desligado. Tais aplicações devem ter o cuidado de gerir adequadamente o tempo de vida dos despachantes.

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 desativar a alteração na limpeza, use o seguinte sinalizador AppContext.

<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 mestre/detalhado

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 através da chave primária "OrderID". Em seu aplicativo WPF, você pode vincular um controle de lista aos detalhes de uma determinada ordem:

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

onde o DataContext é um Order. WPF obtém o valor da propriedade OrderDetails — uma coleção D de todos os itens Detail cujas propriedades OrderID correspondem ao OrderID do item mestre. A alteração de comportamento ocorre quando se altera a chave primária OrderID do item mestre. O ADO altera automaticamente a 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 é esvaziada. O item mestre não gera uma notificação de alteração para OrderDetailsde propriedade. O ListBox continua a usar a coleção D, que agora está vazia.
• Novo comportamento: A coleção D permanece inalterada. Cada um de seus itens gera uma notificação de alteração para a propriedade OrderID. A ListBox continua a usar a coleção D e apresenta os detalhes com o novo 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>

A opção assume como padrão true (comportamento antigo) para aplicativos destinados ao .NET 4.7.1 ou inferior e para false (novo comportamento) para aplicativos destinados ao .NET 4.7.2 ou superior.

WPF FocusVisual para RadioButton e CheckBox agora exibe 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, incorretos. Esses problemas ocorrem nos casos em que os controles não têm qualquer conjunto de conteúdo. Isso pode tornar a transição entre temas confusa e o foco visual 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 visa o .NET Framework 4.7.2 e deseja reverter para o 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 obrigados a aceitar todas as melhorias de acessibilidade anteriores para obter as melhorias mais recentes. Para fazer isso, certifique-se de que ambas as opções AppContext 'Switch.UseLegacyAccessibilityFeatures' e 'Switch.UseLegacyAccessibilityFeatures.2' estejam definidas como false.

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

O WPF TextBox/PasswordBox não segue as cores do sistema para a seleção de texto

Detalhes

No .NET Framework 4.7.1 e versões anteriores, o WPF System.Windows.Controls.TextBox e System.Windows.Controls.PasswordBox só podia renderizar uma seleção de texto na camada Adorner. 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 apropriadamente. Para utilizar este recurso, a versão do .NET Framework instalada deve ser 4.7.2 ou superior. Para habilitar a seleção não baseada em adornos, use o seguinte indicador AppContext.

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

Windows Workflow Foundation (WF)

Evitando recursões intermináveis para IWorkflowInstanceManagement.TransactedCancel e IWorkflowInstanceManagement.TransactedTerminate

Detalhes

Em algumas circunstâncias, ao usar APIs IWorkflowInstanceManagement.TransactedCancel ou IWorkflowInstanceManagement.TransactedTerminate para cancelar ou encerrar uma instância de serviço de fluxo de trabalho, a instância de fluxo de trabalho pode encontrar um estouro de pilha devido a recursão interminável quando o runtime do Workflow tenta persistir a instância de serviço como parte do processamento da solicitação. O problema ocorre se a instância do 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 enfileirados na instância de 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 TransactedCancel/TransactedTerminate é concluída e o controle é devolvido ao cliente. Quando a transação associada à operação TransactedCancel/TransactedTerminate tenta confirmar, ela precisa guardar o estado da instância do serviço de fluxo de trabalho. Mas, como há uma solicitação de WCF pendente para a instância, a execução do tempo do fluxo de trabalho não consegue manter a instância do serviço de fluxo de trabalho. Um loop de recursão interminável provoca o estouro da pilha. Como TransactedCancel e TransactedTerminate apenas criam um item de trabalho na memória, o facto de existir uma transação não tem qualquer efeito. Uma reversão da transação não descarta o item de trabalho. Para resolver este problema, a partir do .NET Framework 4.7.2, introduzimos um AppSetting que pode ser adicionado ao web.config/app.config do serviço de fluxo de trabalho que lhe indica ignorar transações para TransactedCancel e TransactedTerminate. Isso permite que a transação seja confirmada sem esperar que a instância do fluxo de trabalho persista. O AppSetting para esse recurso é chamado microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate. Um valor de true indica que a transação deve ser ignorada, assim evitando o estouro da pilha. O valor padrão deste 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 estiver encontrando um estouro de pilha na instância do serviço de fluxo de trabalho ao tentar cancelar ou encerrar uma instância de fluxo de trabalho, 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 está encontrando o problema, você não precisa fazer isso.