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.1 e 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 P:System.Web.HttpRuntime.AppDomainAppPath valor que inclui caracteres nulos. No .NET Framework 4.6.1 e versões anteriores, o tempo de execução lança um T:System.ArgumentNullExceptionarquivo .

Sugestão

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

  • Manipule se o T:System.NullReferenceException 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.ArgumentNullExceptionarquivo .
Nome Valor
Âmbito Edge
Versão 4.6.2
Type Redirecionamento

APIs afetadas

Acelerar 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 predefinido é 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 desativar o novo comportamento.

<appSettings>
    <add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
Nome Valor
Âmbito Edge
Versão 4.7
Type Redirecionamento

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 ServicePointManager.SecurityProtocol propriedade é 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 operacional Windows, consulte Protocolos em TLS/SSL (SSP Schannel).

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

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 ServicePointManager.SecurityProtocol valor da propriedade. Se essa alteração for indesejável, você poderá 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 <runtime> seção e a Switch.System.Net.DontEnableSystemDefaultTlsVersions opção de exclusão:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
Nome Valor
Âmbito Menor
Versão 4.7
Type Redirecionamento

APIs afetadas

SslStream suporta alertas TLS

Detalhes

Após um handshake TLS com falha, uma System.IO.IOException exceção interna System.ComponentModel.Win32Exception será lançada pela primeira operação de leitura/gravação de E/S. O System.ComponentModel.Win32Exception.NativeErrorCode código 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: Seçã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

Aplicativos que chamam APIs de E/S de rede, como Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) devem manipular 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"
    
Nome Valor
Âmbito Edge
Versão 4.7
Type Redirecionamento

APIs afetadas

Segurança

CspParameters.ParentWindowHandle agora espera o valor HWND

Detalhes

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

cspParameters.ParentWindowHandle = form.Handle;

Em versões anteriores do .NET Framework, esperava-se que o valor representasse System.IntPtr um local na memória onde o valor HWND residia. 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

Os aplicativos destinados ao .NET Framework 4.7 ou superior que desejam registrar um relacionamento de janela pai são incentivados a usar o formulário 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 continha o valor form.Handle podem optar por não receber a alteração de comportamento definindo a opção Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle AppContext como true:

  • Definindo programaticamente compatíveis, comuta o AppContext, conforme explicado aqui.
  • Adicionando a seguinte linha à <runtime> seção 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.

Nome Valor
Âmbito Menor
Versão 4.7
Type Redirecionamento

APIs afetadas

SslStream suporta alertas TLS

Detalhes

Após um handshake TLS com falha, uma System.IO.IOException exceção interna System.ComponentModel.Win32Exception será lançada pela primeira operação de leitura/gravação de E/S. O System.ComponentModel.Win32Exception.NativeErrorCode código 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: Seçã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

Aplicativos que chamam APIs de E/S de rede, como Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) devem manipular 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"
    
Nome Valor
Âmbito Edge
Versão 4.7
Type Redirecionamento

APIs afetadas

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 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 à <runtime> seção do arquivo app.config ou web.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>
Nome Valor
Âmbito Edge
Versão 4.7
Type Redirecionamento

APIs afetadas

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 à <runtime> seção do arquivo app.config ou web.config:

<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
Nome Valor
Âmbito Edge
Versão 4.7
Type Redirecionamento

Windows Presentation Foundation (WPF)

Chamadas para System.Windows.Input.PenContext.Disable em sistemas habilitados para toque podem lançar um ArgumentException

Detalhes

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

Nome Valor
Âmbito Edge
Versão 4.6.1
Type Redirecionamento

NullReferenceException no código de tratamento de exceção de ImageSourceConverter.ConvertFrom

Detalhes

Um erro no código de tratamento de exceção para ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) fez com que um incorreto System.NullReferenceException 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 ser lançados System.NullReferenceException para fins de compatibilidade. Os desenvolvedores que visam o .NET Framework 4.7 e superior devem ver as exceções corretas.

Sugestão

Os desenvolvedores que desejam reverter para obter System.NullReferenceException ao direcionar o .NET Framework 4.7 ou posterior podem adicionar/mesclar o seguinte ao arquivo App.config de seu aplicativo:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>
Nome Valor
Âmbito Edge
Versão 4.7
Type Redirecionamento

APIs afetadas

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 para colunas pode exceder a largura da Grade. 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 * para alocar, a alocação total será muito 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 ao alocar para *-colunas A, B e C (nessa ordem), onde a parte proporcional de B viola sua restrição min (ou max). 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 estão incorretos em 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 *-que recebem 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.

Nota

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

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.

Nome Valor
Âmbito Menor
Versão 4.7
Type Redirecionamento

Pilha de toque baseada em ponteiro WPF

Detalhes

Essa alteração adiciona a capacidade de habilitar uma pilha de toque/caneta WPF baseada em WM_POINTER opcional. 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 tinta 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 comportar-se de forma diferente
  • Arrastar/soltar não mostrará o feedback apropriado para a entrada por toque
  • 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 essa pilha podem adicionar/mesclar o seguinte ao arquivo App.config de seu 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 superior.

Nome Valor
Âmbito Edge
Versão 4.7
Type Redirecionamento

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 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 causava problemas em sistemas habilitados para FIPS. Começando com o .NET Framework 4.7, o algoritmo é SHA1. Se o seu código tiver persistido essas somas de verificação, elas 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 AppContext opção "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>
Nome Valor
Âmbito Menor
Versão 4.7
Type Redirecionamento

.NET Framework 4.7.1

ASP.NET

ASP.NET Melhorias de acessibilidade no .NET Framework 4.7.1

Detalhes

Começando com o .NET Framework 4.7.1, ASP.NET melhorou como ASP.NET Web Controls funcionam com tecnologia de acessibilidade no Visual Studio para oferecer melhor suporte ASP.NET clientes. 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 Pager 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 oferece suporte aos novos recursos de acessibilidade com a seguinte opção AppContext por padrão.
  • Desative os comportamentos de acessibilidade herdados adicionando a Switch.UseLegacyAccessibilityFeatures opção AppContext à <runtime> seção 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 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.

Nome Valor
Âmbito Menor
Versão 4.7.1
Type Redirecionamento

Principal

Exceções de thread em segundo plano SerialPort

Detalhes

Os threads em segundo plano criados com SerialPort fluxos não encerram mais o processo quando as 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 SerialPort fluxo.
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 à <runtime> seção do seu app.config arquivo:

<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 à <runtime> seção do seu app.config arquivo:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false" />
</runtime>
Nome Valor
Âmbito Menor
Versão 4.7.1
Type Redirecionamento

APIs afetadas

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 do ServiceBase.Run.

Começando com aplicativos destinados ao .NET Framework 4.7.1, o tempo de execução propaga exceções para ServiceBase.Run serviços que não são iniciados.

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 AppContextSwitchOverrides elemento à runtime seção 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 AppContextSwitchOverrides elemento à runtime seção do arquivo de configuração do aplicativo:

<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=false" />
Nome Valor
Âmbito Menor
Versão 4.7.1
Type Redirecionamento

APIs afetadas

Segurança

Algoritmos SignedXML e SignedXMS padrão alterados para SHA256

Detalhes

No .NET Framework 4.7 e anteriores, SignedXML e SignedCMS padrão para SHA1 para 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 de tempo de execução do arquivo de configuração do aplicativo:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />
Nome Valor
Âmbito Menor
Versão 4.7.1
Type Redirecionamento

APIs afetadas

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 SignedXml.GetPublicKey método foi alterado (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 interno certificate.GetAnyPublicKey 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 de tempo de execução do arquivo de configuração do seu aplicativo:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Nome Valor
Âmbito Edge
Versão 4.6.2
Type Redirecionamento

APIs afetadas

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, você pode fazer o seguinte para o arquivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false"/>
</runtime>
Nome Valor
Âmbito Edge
Versão 4.7.1
Type Redirecionamento

Windows Forms

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 da propriedade. As melhorias no navegador de propriedades incluem:
  • Melhor navegação pelo teclado através das várias janelas de seleção suspensas.
  • Redução de paradas de tabulação desnecessárias.
  • Melhor 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 recusar 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:

  • Ele é recompilado para direcionar 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 à <runtime> seção 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 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.

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

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

  • Os Button controles e CheckBox com sua FlatStyle propriedade definida como FlatStyle.System, que é o estilo padrão, agora usam cores definidas pelo sistema operacional 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 Buttoncontroles , CheckBox, RadioButton, Label, LinkLabel, e GroupBox com sua Enabled propriedade definida como false usaram 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 FlatStyle propriedade 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 certos temas de Alto Contraste.
  • ToolStripMenuItem controles com sua Enabled propriedade definida como false agora usam a cor "Texto desativado" definida pelo sistema operacional.
  • ToolStripMenuItem Os controles com sua Checked propriedade 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 era contrastante o 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 ComboBox controle tem sua DropDownStyle propriedade 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 ao Narrador

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

  • O LinkLabel controle mudou a maneira como notifica o Narrador do texto de no controle. Anteriormente, o Narrador anunciou este texto duas vezes e leu 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 DataGridViewCell tipos de controle agora relatam corretamente o status somente leitura para o Narrador e outras tecnologias assistenciais.

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

  • O Narrador agora é capaz de ler ToolStripMenuItem controles com uma ToolStripItem.Enabled propriedade definida como false. Anteriormente, o Narrador não conseguia se concentrar em itens de menu desativados para ler o conteúdo.

Nome Valor
Âmbito Principal
Versão 4.8
Type Redirecionamento

APIs afetadas

Windows Presentation Foundation (WPF)

Melhorias de acessibilidade no WPF

Detalhes

Melhorias no Alto Contraste

  • O foco para o Expander controle agora está visível. Em versões anteriores do .NET Framework, não era.
  • O texto e CheckBoxRadioButton os controles quando são selecionados agora são mais fáceis de ver do que em versões anteriores do .NET Framework.
  • A borda de um desabilitado ComboBox agora é da mesma cor do texto desabilitado. 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 faziam.
  • O botão suspenso agora fica visível quando o estilo de um ComboBox controle é definido como ToolBar.ComboBoxStyleKey. Em versões anteriores do .NET Framework, não era.
  • A seta indicadora de classificação em um DataGrid controle agora usa 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 opção agora está visível. Em versões anteriores do .NET Framework, não era.
  • A DataGrid coluna da caixa de seleção do controle agora usa as cores esperadas para o feedback do foco do teclado. Em versões anteriores do .NET Framework, isso não acontecia.
  • os visuais de foco do teclado agora estão visíveis e ComboBoxListBox os controles. Em versões anteriores do .NET Framework, não era.

Melhorias na interação do leitor de tela

  • Expander Os controles agora são anunciados corretamente como grupos (expandir/recolher) pelos leitores de tela.
  • DataGridCell Os controles agora são anunciados corretamente como célula de grade de dados (localizada) pelos leitores de tela.
  • Os leitores de tela agora anunciarão o nome de um arquivo ComboBox.
  • PasswordBox Os 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 de automação da interface do usuário 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 usuário sobre a alteração feita na interface do usuário.

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:

  • Destino .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 a seguinte opção AppContext na<runtime> seção do arquivo de configuração do aplicativo e definindo-a como false, como mostra o exemplo a seguir.

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

Nome Valor
Âmbito Principal
Versão 4.7.1
Type Redirecionamento

APIs afetadas

Evento Seletor SelectionChanged e propriedade SelectedValue

Detalhes

A partir do .NET Framework 4.7.1, um Selector sempre atualiza o valor de sua SelectedValue propriedade antes de gerar o SelectionChanged evento, 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 SelectedValue propriedade.

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 à <runtime> seção 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 à <runtime> seção do arquivo .configuration do aplicativo:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
Nome Valor
Âmbito Menor
Versão 4.7.1
Type Redirecionamento

APIs afetadas

TabControl SelectionChanged evento e SelectedContent propriedade

Detalhes

A partir do .NET Framework 4.7.1, um TabControl atualiza o valor de sua SelectedContent propriedade antes de gerar o SelectionChanged evento, 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 à <runtime> seção 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 à <runtime> seção do arquivo .configuration do aplicativo:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
Nome Valor
Âmbito Menor
Versão 4.7.1
Type Redirecionamento

APIs afetadas

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>
Nome Valor
Âmbito Edge
Versão 4.7.1
Type Redirecionamento

APIs afetadas

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 inicializar para definir dados de correlação para a InitializeCorrelation atividade
  • A janela de definição de conteúdo para o Receive, Send, SendReplye ReceiveReply atividades
  • 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 estiverem focados.
  • 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, como quando:
  • Adicionar linhas a grades de dados usadas pelo Designer de Fluxo de Trabalho e designers de atividades.
  • Tabulação pelos campos no ReceiveReply e SendReply atividades.
  • 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.
  • O FlowSwitch<T>, FlowDecision, e CorrelationScope atividades.
  • O conteúdo da Receive atividade.
  • O Tipo de Destino para a InvokeMethod atividade.
  • A caixa de combinação Exceção e a seção Finalmente na TryCatch atividade.
  • 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 em FlowDecision atividades.
  • 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 em Parallel e Pick atividades.
  • 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.
  • Trilha 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 à <runtime> seção 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 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.

Nome Valor
Âmbito Menor
Versão 4.7.1
Type Redirecionamento

.NET Framework 4.7.2

Principal

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 o 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 como estão.

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 essa alteração for indesejável, você poderá desativá-la adicionando a seguinte opção AppContextSwitchOverrides à <runtime> seção 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 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 opção AppContextSwitchOverrides à <runtime> seção do arquivo de configuração do aplicativo::

<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=false" />
</runtime>
Nome Valor
Âmbito Menor
Versão 4.7.2
Type Redirecionamento

APIs afetadas

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 foi alterada para usar APIs nativas do T:System.IO.Compression.DeflateStream 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 para analisar o cabeçalho gzip (nota: apenas GZipStream o conjunto para descompressão é afetado):
  • Exceções ao analisar cabeçalhos inválidos podem ser lançadas 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 Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression opção à runtime seção do arquivo 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>
Nome Valor
Âmbito Menor
Versão 4.7.2
Type Redirecionamento

APIs afetadas

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

Detalhes

No System.Uri, certos caracteres codificados por porcentagem que às vezes eram decodificados agora são consistentemente deixados 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 essa alteração for indesejável, você poderá desativá-la adicionando a seguinte opção AppContextSwitchOverrides à <runtime> seção 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 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 opção AppContextSwitchOverrides à <runtime> seção do arquivo de configuração do aplicativo:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=false" />
</runtime>
Nome Valor
Âmbito Menor
Versão 4.7.2
Type Redirecionamento

APIs afetadas

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 usuários 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 peculiaridade de desativação. Adicione a seguinte configuração do Registro para aplicar a peculiaridade de exclusão em toda a máquina: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\SDK] "AllowProcessOfUntrustedResourceFiles"="true"

Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento

Os rastreamentos de pilha obtidos ao usar PDBs portáteis agora incluem informações de linha, 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 à <runtime> seção do seu app.config arquivo:

<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 aceitar o arquivo de origem e as informações de linha ao usar PDBs portáteis adicionando o seguinte à <runtime> seção do seu app.config arquivo:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=false" />
</runtime>
Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento

APIs afetadas

Windows Forms

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 a seguinte opção AppContext à <runtime> seção do arquivo de configuração do aplicativo e definindo-a como false, como mostra o exemplo a seguir.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
  </startup>
  <runtime>
    <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
  </runtime>
</configuration>

Observe que para aceitar os recursos de acessibilidade adicionados no .NET Framework 4.7.2, você também deve optar pelos recursos de acessibilidade do .NET Framework 4.7.1. Os aplicativos destinados 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 agora usa cores definidas pelo ToolStripDropDownButton SO no tema Alto Contraste.
  • Buttone RadioButton controles com FlatStyle cores definidas ou FlatStyle.FlatFlatStyle.Popup agora usadas pelo SO no tema Alto Contraste quando CheckBox 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 Enabled propriedade definida para false agora usarão cores definidas pelo sistema operacional no tema Alto contraste.
  • Os ToolStripButtoncontroles , ToolStripComboBox, e ToolStripDropDownButton têm uma relação de contraste de luminosidade aumentada no Modo de Alto Contraste.
  • DataGridViewLinkCell usará, por padrão, cores definidas pelo SO no modo Alto Contraste para a DataGridViewLinkCell.LinkColor propriedade. 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 ao Narrador

  • O Narrador agora anuncia o ToolStripMenuItem.ShortcutKeys valor da propriedade ao anunciar o texto de um ToolStripMenuItemarquivo .
  • O Narrador agora indica quando a ToolStripMenuItem tem sua Enabled propriedade definida como false.
  • O Narrador agora fornece comentários sobre o estado de uma caixa de seleção quando a ListView.CheckBoxes propriedade 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 aprimorado à acessibilidade DataGridView

Pistas visuais melhoradas

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

Suporte melhorado à rede de propriedades

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

  • Os PropertyGrid elementos filho de controle agora retornam um false para a IsEnabledProperty propriedade 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 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 TabStop propriedade definida como true.

Nome Valor
Âmbito Principal
Versão 4.7.2
Type Redirecionamento

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

Detalhes

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

Sugestão

Como aceitar ou recusar 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 a seguinte opção AppContext à <runtime> seção do arquivo app.config e definindo-a como false, como mostra o exemplo a seguir.
<runtime>
  <AppContextSwitchOverrides value="Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue=false"/>
</runtime>

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

Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento

APIs afetadas

O método PrivateFontCollection.AddFontFile libera recursos de fonte

Detalhes

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

Sugestão

Como aceitar ou recusar essas alterações Para que um aplicativo se beneficie dessas alterações, ele 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 a seguinte opção AppContext à <runtime> seção do arquivo app.config e definindo-a como false, como mostra o exemplo a seguir.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Drawing.Text.DoNotRemoveGdiFontsResourcesFromFontCollection=false"/>
</runtime>

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

Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento

APIs afetadas

As ações de botão para cima e para baixo do Domínio do WinForm estão sincronizadas agora

Detalhes

No .NET Framework 4.7.1 e versões anteriores, a DomainUpDown ação do DomainUpDown.UpButton() controle é ignorada quando o texto do controle está presente, e o desenvolvedor é obrigado a usar DomainUpDown.DownButton() a ação no controle antes de usar DomainUpDown.UpButton() a ação. A partir do .NET Framework 4.7.2, as DomainUpDown.UpButton() ações e DomainUpDown.DownButton() funcionam de forma independente neste 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 a seguinte opção AppContext à<runtime> seção do arquivo de configuração do aplicativo e definindo-a como false, como mostra o exemplo a seguir.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling=false"/>
</runtime>
Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento

APIs afetadas

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 Switch.UseLegacyAccessibilityFeatures opções e as Switch.UseLegacyAccessibilityFeatures.2 opções devem ser definidasUm 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>
Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento

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 soma de verificação para arquivos de marcação 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 ao direcionar uma versão da estrutura abaixo do .NET 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>
Nome Valor
Âmbito Transparente
Versão 4.7.2
Type Redirecionamento

WPF AppDomain Shutdown Handling pode agora chamar Dispatcher.Invoke na limpeza de eventos fracos

Detalhes

No .NET Framework 4.7.1 e versões anteriores, o WPF potencialmente cria um System.Windows.Threading.Dispatcher thread no finalizador do .NET durante o desligamento 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 é visto em aplicativos que não desligam corretamente os dispatchers em execução em threads de trabalho antes do processo ou do desligamento do AppDomain. 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>
Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento

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 Orderarquivo . WPF obtém o valor da OrderDetails propriedade - uma coleção D de todos os Detail itens cuja OrderID correspondência com o OrderID do item mestre. A alteração de comportamento surge quando você altera a chave OrderID primária 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 está limpa. O item mestre não gera uma notificação de alteração para a propriedade OrderDetails. O ListBox continua a usar a coleção D, que agora está vazia.
  • Novo comportamento: A coleção D permanece inalterada. Cada um de seus itens gera uma notificação de alteração para a OrderID propriedade. O ListBox continua a usar a coleção D e exibe 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 DataRowView.CreateChildView(DataRelation, Boolean) ADO com o followParent argumento 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 (comportamento antigo) para true aplicativos destinados ao .NET 4.7.1 ou inferior e para (novo comportamento) para aplicativos destinados ao false .NET 4.7.2 ou superior.

Nome Valor
Âmbito Menor
Versão 4.7.2
Type Redirecionamento

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, WPF System.Windows.Controls.CheckBox e System.Windows.Controls.RadioButton têm inconsistentes e, em temas clássicos e de alto contraste, visuais de foco 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 destinado ao .NET Framework 4.7.2 que deseja reverter para o comportamento no .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>
Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento

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

Detalhes

No .NET Framework 4.7.1 e versões anteriores, 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 esse 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 sinalizador AppContext.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Text.UseAdornerForTextboxSelectionRendering=false"/>
</runtime>
</configuration>
Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento

Windows Workflow Foundation (WF)

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

Detalhes

Em algumas circunstâncias, ao usar IWorkflowInstanceManagement.TransactedCancel APIs OR 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 Workflow tempo de execução 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 TransactedCancel operações e TransactedTerminate criam itens de trabalho que são enfileirados para a instância de serviço de fluxo de trabalho. Esses itens de trabalho não são executados como parte do processamento da TransactedCancel/TransactedTerminate solicitação. 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 TransactedCancel/TransactedTerminate operação é concluída e o controle é devolvido ao cliente. Quando a transação associada TransactedCancel/TransactedTerminate à operação tenta confirmar, ela precisa persistir o estado da instância do serviço de fluxo de trabalho. Mas como há uma solicitação pendente WCF para a instância, o tempo de execução do fluxo de trabalho não pode persistir a instância do serviço de fluxo de trabalho, e um loop de recursão interminável leva ao estouro da pilha. Porque TransactedCancel e TransactedTerminate apenas criar um item de trabalho na memória, o fato de que uma transação existe não tem qualquer efeito. Uma reversão da transação não descarta o item de trabalho. Para resolver esse problema, a partir do .NET Framework 4.7.2, introduzimos um AppSetting que pode ser adicionado ao web.config/app.config serviço de fluxo de trabalho que diz a ele para 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 indica que a transação deve ser ignorada, evitando assim o estouro da true 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 IWorkflowInstanceManagement cliente 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 à <appSettings> seção do arquivo web.config/app.config do 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.

Nome Valor
Âmbito Edge
Versão 4.7.2
Type Redirecionamento