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.ArgumentNullException
arquivo .
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.ArgumentNullException
arquivo .
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
- 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 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
- System.Net.Security.SslStream
- System.Net.WebRequest
- System.Net.HttpWebRequest
- System.Net.FtpWebRequest
- System.Net.Mail.SmtpClient
- System.Net.Http
Windows Communication Foundation (WCF)
A serialização de caracteres de controle com DataContractJsonSerializer agora é compatível com ECMAScript V6 e V8
Detalhes
No .NET Framework 4.6.2 e versões anteriores, o System.Runtime.Serialization.Json.DataContractJsonSerializer não serializou alguns caracteres de controle especiais, como \b, \f e \t, de 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
- 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 à <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 comofalse
, 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
- 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 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 comofalse
, 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:
Os ToolStripSplitButton controles e ComboBox suportam o padrão Expandir/Recolher.
O ToolStripMenuItem controle tem um valor ControlType.MenuItemde propriedade ControlType .
O ToolStripItem controle suporta a NameProperty propriedade e opadrão Expand/Collapse.
O ToolStripDropDownItem controle suporta AccessibleEvents a indicação de StateChange e NameChange quando a lista suspensa é expandida ou recolhida.
O ToolStripDropDownButton controle tem um valor de propriedade ControlType de ControlType.MenuItem.
O DataGridViewCheckBoxCell controle suporta o TogglePattern.
Os NumericUpDown controles e DomainUpDown suportam a NameProperty propriedade e têm um ControlType de ControlType.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 é exibida quando o usuário insere um valor incorreto no PropertyGrid controle suporta o padrão Expandir/Recolher, notificações de alteração de estado e nome e uma propriedade ControlType com um valor de ControlType.MenuItem.
O painel de mensagens exibido quando o botão Detalhes da caixa de diálogo de erro é expandido agora está acessível pelo teclado e permite que o Narrador anuncie o conteúdo da mensagem de erro.
As AccessibleRole linhas no controle foram alteradas PropertyGrid de "Row" para "Cell". A célula mapeia para UIA ControlType "DataItem", o que lhe permite suportar atalhos de teclado apropriados e anúncios do Narrador.
As PropertyGrid linhas de controle que representam itens de cabeçalho quando o PropertyGrid controle tem uma PropertySort propriedade definida para PropertySort.Categorized ter um valor de propriedade ControlType de ControlType.Button.
As PropertyGrid linhas de controle que representam itens de cabeçalho quando o PropertyGrid controle tem uma PropertySort propriedade definida para dar suporte ao PropertySort.Categorizedpadrã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 da propriedade atual PropertySort .
PropertyGrid controles exibidos no modo Alto Contraste e com uma PropertySort propriedade definida como PropertySort.Categorized agora exibirão o plano de fundo dos cabeçalhos de categoria em uma cor altamente contrastante.
PropertyGrid diferencia melhor entre os itens da Barra de Ferramentas com foco e os itens da Barra de Ferramentas que indicam o PropertySort valor atual da propriedade. 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.
PropertyGrid controlar os itens da Barra de Ferramentas que indicam o valor atual da propriedade suportam o PropertySortTogglePattern.
Suporte melhorado do Narrador para distinguir o alinhamento selecionado no Seletor de Alinhamento.
Quando um controle vazio PropertyGrid é 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 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
- 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 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 comofalse
, 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
- 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 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 comofalse
, 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 comofalse
, 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
- As linhas em 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 DataGridViewCell.DataGridViewCellAccessibleObject.Parent propriedade agora retorna o controle pai correto.
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
Navegação por teclado melhoradafalse
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.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 comofalse
, 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 comofalse
, 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 comofalse
, 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 Order
arquivo . 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 novoOrderID
. 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 ofollowParent
argumento definido comotrue
.
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 |