Partilhar via

Alterações de tempo de execução para migração para o .NET Framework 4.6.x

Este artigo lista os problemas de compatibilidade de aplicativos que foram introduzidos no .NET Framework 4.6, 4.6.1 e 4.6.2.

.NET Framework 4.6

ASP.NET

GridViews com AllowCustomPaging definido como true podem disparar o evento PageIndexChanging ao sair da última página da visualização.

Detalhes

Um bug no .NET Framework 4.5 faz com que System.Web.UI.WebControls.GridView.PageIndexChanging às vezes não seja acionado para System.Web.UI.WebControls.GridViews que habilitaram System.Web.UI.WebControls.GridView.AllowCustomPaging.

Sugestão

Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido atualizando para essa versão do .NET Framework. Como solução alternativa, a aplicação pode fazer uma ligação explícita BindGrid a qualquer Page_Load que satisfaça estas condições (System.Web.UI.WebControls.GridView está na última página e LastSystem.Web.UI.WebControls.GridView.PageSize é diferente de System.Web.UI.WebControls.GridView.PageSize). Como alternativa, o aplicativo pode ser modificado para permitir a paginação (em vez de paginação personalizada), pois esse cenário não demonstra o problema.

Nome Valor
Âmbito de aplicação Menor
Versão 4,5
Tipo Tempo de execução

APIs afetadas

Núcleo

Um ConcurrentDictionary serializado no .NET Framework 4.5 com NetDataContractSerializer não pode ser desserializado pelo .NET Framework 4.5.1 ou 4.5.2

Detalhes

Devido a alterações internas no tipo, ConcurrentDictionary<TKey,TValue> os objetos que são serializados com o .NET Framework 4.5 usando o System.Runtime.Serialization.NetDataContractSerializer não podem ser desserializados no .NET Framework 4.5.1 ou no .NET Framework 4.5.2.Observe que mover na outra direção (serializar com o .NET Framework 4.5.x e desserializar com o .NET Framework 4.5) funciona. Da mesma forma, toda a serialização entre versões 4.x funciona com o .NET Framework 4.6.Serializar e desserializar com uma única versão do .NET Framework não é afetado.

Sugestão

Se for necessário serializar e desserializar um System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> entre o .NET Framework 4.5 e o .NET Framework 4.5.1/4.5.2, um serializador diferente como o System.Runtime.Serialization.DataContractSerializer deve ser usado em vez do System.Runtime.Serialization.NetDataContractSerializer. Como alternativa, como esse problema é resolvido no .NET Framework 4.6, ele pode ser resolvido atualizando para essa versão do .NET Framework.

Nome Valor
Âmbito de aplicação Menor
Versão 4.5.1
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

AppDomainSetup.DynamicBase não é mais aleatorizado pelo UseRandomizedStringHashAlgorithm

Detalhes

Antes do .NET Framework 4.6, o valor de DynamicBase seria randomizado entre domínios de aplicativo ou entre processos, se UseRandomizedStringHashAlgorithm estivesse habilitado no arquivo de configuração do aplicativo. A partir do .NET Framework 4.6, DynamicBase retornará um resultado estável entre diferentes instâncias de um aplicativo em execução e entre diferentes domínios de aplicativo. As bases dinâmicas ainda serão diferentes para diferentes aplicativos; Essa alteração remove apenas o elemento de nomenclatura aleatória para instâncias diferentes do mesmo aplicativo.

Sugestão

Esteja ciente de que a habilitação UseRandomizedStringHashAlgorithm não resultará em DynamicBase ser aleatorizado. Se uma base aleatória for necessária, ela deverá ser produzida no código do seu aplicativo e não por meio dessa API.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Chamar Attribute.GetCustomAttributes em uma propriedade de indexador não lança mais AmbiguousMatchException se a ambiguidade puder ser resolvida pelo tipo de índice

Detalhes

Antes do .NET Framework 4.6, ao chamar GetCustomAttribute(s) numa propriedade de indexador que diferia de outra propriedade apenas pelo tipo do índice, resultaria num System.Reflection.AmbiguousMatchException. A partir do .NET Framework 4.6, os atributos da propriedade serão retornados corretamente.

Sugestão

Lembre-se de que GetCustomAttribute(s) funcionará(ão) com mais freqüência agora. Se um aplicativo dependia anteriormente de System.Reflection.AmbiguousMatchException, a reflexão agora deve ser usada para procurar explicitamente vários indexadores.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6
Tipo Tempo de execução

APIs afetadas

COR_PRF_GC_ROOT_HANDLEs não estão sendo enumerados por criadores de perfil

Detalhes

No .NET Framework v4.5.1, a API RootReferences2() de criação de perfil está incorretamente nunca retornando COR_PRF_GC_ROOT_HANDLE (eles são retornados como COR_PRF_GC_ROOT_OTHER em vez disso). Esse problema é corrigido a partir do .NET Framework 4.6.

Sugestão

Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido atualizando para essa versão do .NET Framework.

Nome Valor
Âmbito de aplicação Menor
Versão 4.5.1
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

ETW EventListeners não capturam eventos de provedores com palavras-chave explícitas (como o provedor TPL)

Detalhes

ETW EventListeners com uma máscara de palavra-chave em branco não capturam corretamente eventos de provedores com palavras-chave explícitas. No .NET Framework 4.5, o provedor TPL começou a fornecer palavras-chave explícitas e disparou esse problema. No .NET Framework 4.6, EventListeners foram atualizados para não ter mais esse problema.

Sugestão

Para contornar este problema, substitua as chamadas para EnableEvents(EventSource, EventLevel) por chamadas para a sobrecarga EnableEvents que especifica explicitamente a máscara "quaisquer palavras-chave" a usar: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).

Como alternativa, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido atualizando para essa versão do .NET Framework.

Nome Valor
Âmbito de aplicação Borda
Versão 4,5
Tipo Tempo de execução

APIs afetadas

O calendário persa agora usa o algoritmo solar Hijri

Detalhes

Começando com o .NET Framework 4.6, a System.Globalization.PersianCalendar classe usa o algoritmo solar Hijri. A conversão de datas entre o System.Globalization.PersianCalendar e outros calendários pode produzir um resultado ligeiramente diferente começando com o .NET Framework 4.6 para datas anteriores a 1800 ou posteriores a 2023 (gregoriano). Além disso, PersianCalendar.MinSupportedDateTime é agora March 22, 0622 em vez de March 21, 0622.

Sugestão

Esteja ciente de que algumas datas iniciais ou tardias podem ser ligeiramente diferentes ao usar o PersianCalendar no .NET Framework 4.6. Além disso, ao serializar datas entre processos que podem ser executados em diferentes versões do .NET Framework, não as armazene como cadeias de caracteres de data PersianCalendar (pois esses valores podem ser diferentes).

Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Os objetos de reflexão não podem mais ser passados do código gerenciado para clientes DCOM fora do processo

Detalhes

Os objetos de reflexão não podem mais ser passados do código gerenciado para clientes DCOM fora do processo. Os seguintes tipos são afetados:

Chamadas para IMarshal do objeto retornam E_NOINTERFACE.

Sugestão

Atualize o código de marshalling para funcionar com objetos sem utilizar reflexão.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

TargetFrameworkName para o domínio padrão da aplicação não é mais definido como null se não estiver configurado.

Detalhes

O System.AppDomainSetup.TargetFrameworkName foi anteriormente nulo no domínio do aplicativo padrão, a menos que tenha sido definido explicitamente. A partir da versão 4.6, a System.AppDomainSetup.TargetFrameworkName propriedade para o domínio do aplicativo padrão terá um valor padrão derivado do TargetFrameworkAttribute (se houver um). Os domínios de aplicativo não padrão continuarão a herdar o seu System.AppDomainSetup.TargetFrameworkName do domínio de aplicativo padrão (que não terá um valor padrão de nulo na versão 4.6), a menos que seja explicitamente substituído.

Sugestão

O código deve ser atualizado para não depender de que TargetFrameworkName seja definido como null por padrão. Se for necessário que essa propriedade continue a ser avaliada como null, ela poderá ser explicitamente definida como esse valor.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6
Tipo Tempo de execução

APIs afetadas

X509Certificate2.ToString(Boolean) não lança agora quando o .NET não pode manipular o certificado

Detalhes

No .NET Framework 4.5.2 e versões anteriores, esse método seria lançado se true fosse passado para o parâmetro verbose e houvesse certificados instalados que não eram suportados pelo .NET Framework. Agora, o método terá êxito e retornará uma cadeia de caracteres válida que omite as partes inacessíveis do certificado.

Sugestão

Qualquer código dependente de X509Certificate2.ToString(Boolean) deve ser atualizado para esperar que a cadeia de caracteres retornada possa excluir alguns dados de certificado (como chave pública, chave privada e extensões) em alguns casos em que a API anteriormente teria lançado uma exceção.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Dados

A tentativa de estabelecer uma conexão TCP/IP com uma base de dados do SQL Server que resulta em localhost falha.

Detalhes

No .NET Framework 4.6 e 4.6.1, a tentativa de uma conexão TCP/IP com um banco de dados do SQL Server que se resolve para localhost falha com o erro: "Ocorreu um erro relacionado à rede ou à instância específica durante o estabelecimento de uma conexão com o SQL Server. O servidor não foi encontrado ou não estava acessível. Verifique se o nome da instância está correto e se o SQL Server está configurado para permitir conexões remotas. (provedor: Interfaces de rede SQL, erro: 26 - Erro ao localizar servidor/instância especificada)"

Sugestão

Esse problema foi resolvido e o comportamento anterior restaurado no .NET Framework 4.6.2. Para se ligar a um banco de dados do SQL Server que resolve para localhost, atualize para o .NET Framework 4.6.2.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

Depurador de código

Valores coalescer nulos não são visíveis no depurador até uma etapa depois

Detalhes

Um bug no .NET Framework 4.5 faz com que os valores definidos por meio de uma operação de coalescência nula não fiquem visíveis no depurador imediatamente após a operação de atribuição ser executada quando executada na versão de 64 bits do Framework.

Sugestão

Passar mais uma vez pelo depurador fará com que o valor da variável local/campo seja atualizado corretamente. Além disso, esse problema foi corrigido no .NET Framework 4.6; a atualização para essa versão do quadro deve resolver o problema.

Nome Valor
Âmbito de aplicação Borda
Versão 4,5
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

Ligação em rede

ContentDisposition DateTimes retorna uma cadeia de caracteres ligeiramente diferente

Detalhes

As representações em forma de texto de System.Net.Mime.ContentDisposition foram atualizadas na versão 4.6 para representar sempre o componente de hora de System.DateTime com dois dígitos. Isto é para cumprir com RFC822 e RFC2822. Isso faz com que ToString() retorne um texto ligeiramente diferente na versão 4.6 em situações onde um dos elementos temporais da configuração fosse anterior às 10h00. Observe que ContentDispositions por vezes são serializados através da conversão em cadeias de caracteres, portanto, quaisquer operações, serialização ou chamadas para GetHashCode devem ser revisadas.

Sugestão

Não espere que as representações de cadeia de caracteres de ContentDispositions de diferentes versões do .NET Framework sejam comparadas corretamente entre si. Converta as cadeias de caracteres de volta para ContentDispositions, se possível, antes de realizar uma comparação.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Serialização

A mensagem de exceção foi alterada devido a uma falha na serialização de DataContract no caso de um tipo desconhecido

Detalhes

A partir do .NET Framework 4.6, a mensagem de exceção fornecida se um System.Runtime.Serialization.DataContractSerializer ou System.Runtime.Serialization.Json.DataContractJsonSerializer falhar ao serializar ou desserializar devido a 'tipos conhecidos' ausentes foi esclarecida.

Sugestão

Os aplicativos não devem depender de mensagens de exceção específicas. Se um aplicativo depender dessa mensagem, atualize-o para esperar a nova mensagem ou (de preferência) altere-o para depender apenas do tipo de exceção.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Configuração e implantação

Alterações de versão do produto no .NET Framework 4.6 e versões posteriores

Detalhes

O controle de versão do produto foi alterado em relação às versões anteriores do .NET Framework e, particularmente, do .NET Framework 4, 4.5, 4.5.1 e 4.5.2. Seguem-se as alterações detalhadas:

  • O valor da Version entrada na HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full chave foi alterado para 4.6.xxxxx no .NET Framework 4.6 e nas suas atualizações pontuais e para 4.7.xxxxx no .NET Framework 4.7 e 4.7.1. No .NET Framework 4.5, 4.5.1 e 4.5.2, ele tinha o formato 4.5.xxxxx.
  • O controle de versão de arquivo e produto para arquivos do .NET Framework foi alterado do esquema de controle de versão anterior de 4.0.30319.x para 4.6.X.0 para o .NET Framework 4.6 e suas versões pontuais, e para 4.7.X.0 para o .NET Framework 4.7 e 4.7.1. Você pode ver esses novos valores quando visualiza as Propriedades do arquivo depois de clicar com o botão direito do mouse em um arquivo.
  • Os AssemblyFileVersionAttribute e AssemblyInformationalVersionAttribute atributos para assemblies geridos têm valores Version no formato 4.6.X.0 para o .NET Framework 4.6 e suas versões pontuais, e 4.7.X.0 para o .NET Framework 4.7 e 4.7.1.
  • No .NET Framework 4.6, 4.6.1, 4.6.2, 4.7 e 4.7.1, a Environment.Version propriedade retorna a cadeia de caracteres 4.0.30319.42000de versão fixa . No .NET Framework 4, 4.5, 4.5.1 e 4.5.2, ele retorna cadeias de caracteres de versão no formato 4.0.30319.xxxxx (por exemplo, "4.0.30319.18010"). Observe que não recomendamos que o código do aplicativo tenha qualquer nova dependência da propriedade Environment.Version.

Para obter mais informações, consulte Como determinar quais versões do .NET Framework estão instaladas.

Sugestão

Em geral, os aplicativos devem depender das técnicas recomendadas para detetar coisas como a versão de tempo de execução do .NET Framework e o diretório de instalação:

Importante

O nome da subchave é NET Framework Setup, não .NET Framework Setup.

  • Para determinar o caminho do diretório para o Common Language Runtime do .NET Framework, chame o RuntimeEnvironment.GetRuntimeDirectory() método.
  • Para obter a versão CLR, chame o RuntimeEnvironment.GetSystemVersion() método. Para o .NET Framework 4 e suas versões pontuais (o .NET Framework 4.5, 4.5.1, 4.5.2 e .NET Framework 4.6, 4.6.1, 4.6.2, 4.7 e 4.7.1), ele retorna a cadeia de caracteres v4.0.30319.
Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

O .NET Framework 4.6 não usa uma versão 4.5.x.x ao se registrar no registro

Detalhes

Como seria de esperar, a chave de versão definida no registo (at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) para o .NET Framework 4.6 começa com '4.6', não com '4.5'. Os aplicativos que dependem dessas chaves do Registro para saber quais versões do .NET Framework estão instaladas em uma máquina devem ser atualizados para entender que a 4.6 é uma nova versão possível e compatível com versões anteriores da 4.5.x.

Sugestão

Atualize os aplicativos que investigam uma instalação do .NET Framework 4.5 procurando chaves do Registro 4.5 para também aceitar a versão 4.6.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

Windows Communication Foundation (WCF)

Serviços WCF que usam NETTCP com segurança SSL e autenticação de certificado MD5

Detalhes

O .NET Framework 4.6 adiciona TLS 1.1 e TLS 1.2 à lista de protocolos padrão SSL do WCF. Quando as máquinas cliente e servidor têm o .NET Framework 4.6 ou posterior instalado, o TLS 1.2 é usado para negociação. TLS 1.2 não suporta autenticação de certificado MD5. Como resultado, se um cliente usa um certificado MD5, o cliente WCF não conseguirá se conectar ao serviço WCF.

Sugestão

Você pode contornar esse problema para que um cliente WCF pode se conectar a um servidor WCF seguindo um destes procedimentos:

  • Atualize o certificado para não usar o algoritmo MD5. Esta é a solução recomendada.
  • Se a associação não estiver configurada dinamicamente no código-fonte, atualize o arquivo de configuração do aplicativo para usar o TLS 1.1 ou uma versão anterior do protocolo. Isso permite que você continue a usar um certificado com o algoritmo de hash MD5.

Advertência

Esta solução alternativa não é recomendada, uma vez que um certificado com o algoritmo de hash MD5 é considerado inseguro.

O seguinte arquivo de configuração faz isso:

<configuration>
  <system.serviceModel>
    <bindings>
      <netTcpBinding>
        <binding>
          <security mode= "None/Transport/Message/TransportWithMessageCredential" >
            <transport clientCredentialType="None/Windows/Certificate"
                       protectionLevel="None/Sign/EncryptAndSign"
                       sslProtocols="Ssl3/Tls1/Tls11">
            </transport>
          </security>
        </binding>
      </netTcpBinding>
    </bindings>
  </system.ServiceModel>
</configuration>

Advertência

Esta solução alternativa não é recomendada, uma vez que um certificado com o algoritmo de hash MD5 é considerado inseguro.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

Windows Presentation Foundation (WPF)

Aceder aos itens selecionados de um WPF DataGrid a partir de um manipulador do evento UnloadingRow do DataGrid pode causar uma NullReferenceException

Detalhes

Devido a um bug no .NET Framework 4.5, manipuladores de eventos para eventos de DataGrid que envolvem a remoção de uma linha podem fazer com que um System.NullReferenceException seja lançado se acessarem as propriedades DataGrid ou System.Windows.Controls.Primitives.Selector.SelectedItem do System.Windows.Controls.Primitives.MultiSelector.SelectedItems.

Sugestão

Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido atualizando para essa versão do .NET Framework.

Nome Valor
Âmbito de aplicação Menor
Versão 4,5
Tipo Tempo de execução

APIs afetadas

Chamar Items.Refresh em um WPF ListBox, ListView ou DataGrid com itens selecionados pode fazer com que itens duplicados apareçam no elemento

Detalhes

No .NET Framework 4.5, chamar ListBox.Items.Refresh do código enquanto há itens selecionados em um System.Windows.Controls.ListBox pode resultar na duplicação dos itens selecionados na lista. Um problema semelhante ocorre com System.Windows.Controls.ListView e System.Windows.Controls.DataGrid. Isso é corrigido no .NET Framework 4.6.

Sugestão

Esse problema pode ser resolvido desmarcando programaticamente itens antes System.Windows.Data.CollectionView.Refresh() de ser chamado e, em seguida, reselecionando-os depois que a chamada é concluída. Como alternativa, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido atualizando para essa versão do .NET Framework.

Valor
Âmbito de aplicação Menor
Versão 4,5
Tipo Tempo de execução

APIs afetadas

CoerceIsSelectionBoxRealçado

Detalhes

Certas sequências de ações envolvendo um System.Windows.Controls.ComboBox e a sua fonte de dados podem resultar em um System.NullReferenceException.

Sugestão

Se possível, atualize para o .NET Framework 4.6.2.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

ListBoxItem IsSelected problema de ligação com ObservableCollection<T>.Move

Detalhes

Chamar Move(Int32, Int32) ou MoveItem(Int32, Int32) em uma coleção vinculada a um System.Windows.Controls.ListBox com itens selecionados pode levar a um comportamento errático com seleção ou desseleção futura de System.Windows.Controls.ListBox itens.

Sugestão

Ligar System.Collections.ObjectModel.Collection<T>.Remove(T) e System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) em vez de Move(Int32, Int32) vai contornar esse problema. Como alternativa, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido atualizando para essa versão do .NET Framework.

Nome Valor
Âmbito de aplicação Menor
Versão 4,5
Tipo Tempo de execução

APIs afetadas

Clicar com o botão direito do mouse num cabeçalho de linha do DataGrid WPF modifica a seleção do DataGrid.

Detalhes

Clicar com o botão direito do mouse num cabeçalho de linha System.Windows.Controls.DataGrid enquanto várias linhas estão selecionadas faz com que a seleção de System.Windows.Controls.DataGrid seja alterada para apenas essa linha.

Sugestão

Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido atualizando para essa versão do .NET Framework.

Nome Valor
Âmbito de aplicação Borda
Versão 4,5
Tipo Tempo de execução

APIs afetadas

WPF gera um processo de wisptis.exe que pode congelar o mouse

Detalhes

Foi introduzido um problema na versão 4.5.2 que causa wisptis.exe a ser gerado, o que pode congelar a entrada do rato.

Sugestão

Uma correção para esse problema está disponível em uma versão de serviço do .NET Framework 4.5.2 (pacote cumulativo de hotfix 3026376) ou atualizando para o .NET Framework 4.6

Nome Valor
Âmbito de aplicação Maior
Versão 4.5.2
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

A verificação ortográfica do WPF em controles habilitados para texto não funcionará no Windows 10 para idiomas que não estejam na lista de idiomas de entrada do sistema operacional

Detalhes

Ao executar no Windows 10, o verificador ortográfico pode não funcionar para controles habilitados para texto WPF porque os recursos de verificação ortográfica da plataforma estão disponíveis apenas para idiomas presentes na lista de idiomas de entrada. No Windows 10, quando um idioma é adicionado à lista de teclados disponíveis, o Windows baixa e instala automaticamente um pacote FOD (Recurso sob Demanda) correspondente que fornece recursos de verificação ortográfica. Ao adicionar o idioma à lista de idiomas de entrada, o verificador ortográfico será suportado.

Sugestão

Lembre-se de que o idioma ou texto a ser verificado ortograficamente deve ser adicionado como um idioma de entrada para que a verificação ortográfica funcione no Windows 10.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

As janelas do WPF são renderizadas sem recorte ao se estender para fora de um único monitor

Detalhes

No .NET Framework 4.6 em execução no Windows 8 e superior, toda a janela é renderizada sem recorte quando se estende para fora de uma única exibição em um cenário de vários monitores. Isso é diferente das versões anteriores do .NET Framework que cortavam janelas do WPF que se estendiam além de uma única exibição.

Sugestão

Esse comportamento (cortar ou não) pode ser explicitamente definido usando o elemento <EnableMultiMonitorDisplayClipping> no <appSettings> no ficheiro de configuração de uma aplicação ou definindo a propriedade EnableMultiMonitorDisplayClipping na inicialização da aplicação.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

.NET Framework 4.6.1

Ferramentas

Contract.Invariant ou Contract.Requires<TException> não tratam String.IsNullOrEmpty como uma operação pura.

Detalhes

Para aplicações destinadas ao .NET Framework 4.6.1, se o contrato invariante para Contract.Invariant ou o contrato de pré-condição para Requires chamar o método String.IsNullOrEmpty, o regravador emitirá um aviso do compilador CC1036: "Chamada detetada para o método 'System.String.IsNullOrWhiteSpace(System.String)' sem [Pure] no método." Este é um aviso do compilador, em vez de um erro do compilador.

Sugestão

Esse comportamento foi abordado no problema #339 do GitHub. Para eliminar esse aviso, você pode baixar e compilar uma versão atualizada do código-fonte para a ferramenta Contratos de código do GitHub. As informações de download encontram-se na parte inferior da página.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6.1
Tipo Tempo de execução

APIs afetadas

Windows Presentation Foundation (WPF)

Deslizar itens em uma lista plana com itens de diferentes alturas em pixels

Detalhes

Quando um System.Windows.Controls.ItemsControl exibe uma coleção com virtualização (IsVirtualizing=true) e rolagem de itens (ScrollUnit=Item), o controlo rola para apresentar um item cuja altura em pixels difere dos seus vizinhos, e então o System.Windows.Controls.VirtualizingStackPanel percorre todos os itens da coleção. A interface do usuário não responde durante essa iteração. A iteração ocorre em outras circunstâncias, mesmo em versões anteriores do .NET Framework. Por exemplo, ocorre quando o deslocamento de pixels (ScrollUnit=Pixel) se depara com um item de altura de pixel diferente. Além disso, quando ocorre a rolagem de itens em dados hierárquicos (como um System.Windows.Controls.TreeView ou um System.Windows.Controls.ItemsControl com agrupamento habilitado) ao encontrar um item com um número de descendentes diferente comparado com os seus vizinhos. No caso de rolagem de itens e altura de pixel diferente, a iteração foi introduzida no .NET Framework 4.6.1 para corrigir bugs no layout de dados hierárquicos. Não é necessário se os dados forem simples (sem hierarquia) e o .NET Framework 4.6.2 não o fizer nesse caso.

Sugestão

Se a iteração ocorrer no .NET Framework 4.6.1, mas não em versões anteriores - ou seja, se o System.Windows.Controls.ItemsControl estiver a fazer scroll numa lista plana cujos itens têm altura de pixel variável - existem duas soluções:

  • Instale o .NET Framework 4.6.2.
  • Instale o hotfix HR 1605 para .NET Framework 4.6.1.
Nome Valor
Âmbito de aplicação Menor
Versão 4.6.1
Tipo Tempo de execução

APIs afetadas

ObjectDisposedException lançada pelo corretor ortográfico do WPF

Detalhes

Aplicativos WPF ocasionalmente falham durante o desligamento do aplicativo com um System.ObjectDisposedException lançado pelo corretor ortográfico. Isso é corrigido no .NET Framework 4.7 WPF manipulando a exceção normalmente e, portanto, garantindo que os aplicativos não sejam mais afetados negativamente. Deve-se notar que exceções ocasionais de primeira oportunidade continuariam a ser observadas em aplicações executadas num depurador.

Sugestão

Atualizar para o .NET Framework 4.7

Nome Valor
Âmbito de aplicação Borda
Versão 4.6.1
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

A verificação ortográfica do WPF falha de maneiras inesperadas

Detalhes

Isso inclui uma série de problemas do Corretor Ortográfico do WPF:

  • WPF Verificador Ortográfico às vezes gera System.Runtime.InteropServices.COMException
  • WPF Corretor ortográfico falha com UnauthorizedAccessException quando as aplicações são iniciadas usando 'executar como um utilizador diferente'
  • O Corretor Ortográfico do WPF identifica incorretamente erros ortográficos em palavras compostas como 'Hausnummer' em alemão.

Sugestão

Problema #1 - Isso foi corrigido no .NET Framework 4.6.2 Problema #2 - O Corretor Ortográfico do WPF não é mais suportado quando os aplicativos são iniciados usando 'executar como usuário diferente'. A partir do .NET Framework 4.6.2, os aplicativos iniciados dessa maneira não falharão mais inesperadamente - em vez disso, o Corretor Ortográfico será desativado silenciosamente. Problema #3 - Isso foi corrigido no .NET Framework 4.6.2.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6.1
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

.NET Framework 4.6.2

Dados

A tentativa de estabelecer uma conexão TCP/IP com uma base de dados do SQL Server que resulta em localhost falha.

Detalhes

No .NET Framework 4.6 e 4.6.1, a tentativa de uma conexão TCP/IP com um banco de dados do SQL Server que se resolve para localhost falha com o erro: "Ocorreu um erro relacionado à rede ou à instância específica durante o estabelecimento de uma conexão com o SQL Server. O servidor não foi encontrado ou não estava acessível. Verifique se o nome da instância está correto e se o SQL Server está configurado para permitir conexões remotas. (provedor: Interfaces de rede SQL, erro: 26 - Erro ao localizar servidor/instância especificada)"

Sugestão

Esse problema foi resolvido e o comportamento anterior restaurado no .NET Framework 4.6.2. Para se ligar a um banco de dados do SQL Server que resolve para localhost, atualize para o .NET Framework 4.6.2.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

O período de bloqueio do pool de conexões para bancos de dados SQL do Azure foi removido

Detalhes

A partir do .NET Framework 4.6.2, para solicitações de abertura de conexão para bancos de dados SQL conhecidos do Azure (*.database.windows.net, *.database.chinacloudapi.cn, *.database.usgovcloudapi.net, *.database.cloudapi.de), o período de bloqueio do pool de conexões é removido e os erros de abertura de conexão não são armazenados em cache. As tentativas de repetir solicitações de abertura de conexão ocorrerão quase imediatamente após erros de conexão transitórios. Essa alteração permite que a tentativa de abertura de conexão seja repetida imediatamente para bancos de dados SQL do Azure, melhorando assim o desempenho de aplicativos habilitados para nuvem. Para todas as outras tentativas de conexão, o período de bloqueio do pool de conexões continua a ser aplicado.

No .NET Framework 4.6.1 e versões anteriores, quando um aplicativo encontra uma falha de conexão transitória ao se conectar a um banco de dados, a tentativa de conexão não pode ser repetida rapidamente, porque o pool de conexões armazena em cache o erro e o relança por 5 segundos a 1 minuto. Para obter mais informações, consulte Pool de conexões do SQL Server (ADO.NET). Esse comportamento é problemático para conexões com bancos de dados SQL do Azure, que geralmente falham com erros transitórios que normalmente são recuperados em poucos segundos. O recurso de bloqueio do pool de conexões significa que o aplicativo não pode se conectar ao banco de dados por um período extenso, mesmo que o banco de dados esteja disponível e o aplicativo precise renderizar em poucos segundos.

Sugestão

Se esse comportamento for indesejável, você pode configurar o período de bloqueio do pool de conexões definindo a propriedade introduzida System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod no .NET Framework 4.6.2. O valor da propriedade é um membro da System.Data.SqlClient.PoolBlockingPeriod enumeração que pode tomar qualquer um dos três valores:

Você pode restaurar o comportamento anterior definindo a System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod propriedade como AlwaysBlock.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

Globalização

Categorias padrão Unicode versão 8.0 agora suportadas

Detalhes

No .NET Framework 4.6.2, os dados Unicode foram atualizados do Unicode Standard versão 6.3 para a versão 8.0. Ao solicitar categorias de caracteres Unicode no .NET Framework 4.6.2, alguns resultados podem não corresponder aos resultados em versões anteriores do .NET Framework. Esta mudança afeta principalmente as sílabas de Cherokee e os sinais e marcas de tom das vogais New Tai Lue.

Sugestão

Revise o código e remova / altere a lógica que depende de categorias de caracteres Unicode codificadas.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

Segurança

RSACng e DSACng são novamente utilizáveis em cenários de Confiança Parcial

Detalhes

CngLightup (usado em várias APIs de criptografia de nível superior, como System.Security.Cryptography.Xml.EncryptedXml) e System.Security.Cryptography.RSACng , em alguns casos, dependem de confiança total. Estes incluem P/Invokes sem declarar SecurityPermissionFlag.UnmanagedCode permissões e caminhos de código onde System.Security.Cryptography.CngKey exige permissões para SecurityPermissionFlag.UnmanagedCode. Começando com o .NET Framework 4.6.2, o CngLightup foi usado para alternar para System.Security.Cryptography.RSACng sempre que possível. Como resultado, as aplicações de confiança parcial que usaram System.Security.Cryptography.Xml.EncryptedXml com sucesso começaram a falhar e a lançar exceções SecurityException. Esta alteração adiciona as asserções necessárias para que todas as funções que utilizam o CngLightup disponham das permissões requeridas.

Sugestão

Se essa alteração no .NET Framework 4.6.2 tiver afetado negativamente seus aplicativos de confiança parcial, atualize para o .NET Framework 4.7.1.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

RSACng.VerifyHash agora retorna False para qualquer falha de verificação

Detalhes

Começando com o .NET Framework 4.6.2, esse método retorna False se a assinatura em si estiver mal formatada. Ele agora retorna false para qualquer falha de verificação. No .NET Framework 4.6 e 4.6.1, o método lança um System.Security.Cryptography.CryptographicException se a assinatura em si está mal formatada.

Sugestão

Qualquer código cuja execução dependa da manipulação de System.Security.Cryptography.CryptographicException, em vez disso, deve ser executado se a validação falhar e o método retornar False.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

Alterações importantes em SignedXml e EncryptedXml

Detalhes

No .NET Framework 4.6.2, as correções de segurança em System.Security.Cryptography.Xml.SignedXml e System.Security.Cryptography.Xml.EncryptedXml levam a diferentes comportamentos em tempo de execução. Por exemplo:

  • Se um documento tiver vários elementos com o mesmo id atributo e uma assinatura tiver como alvo um desses elementos como a raiz da assinatura, o documento será considerado inválido.
  • Documentos que usam algoritmos de transformação XPath não canônicos em referências agora são considerados inválidos.
  • Documentos que usam algoritmos de transformação XSLT não canônicos em referências agora são considerados inválidos.
  • Qualquer programa que faça uso de assinaturas separadas de recursos externos não poderá fazê-lo.

Sugestão

Os desenvolvedores podem querer rever o uso de XmlDsigXsltTransform e XmlDsigXsltTransform, bem como os tipos derivados de Transform, uma vez que um recetor de documento pode não ser capaz de processá-lo.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

Windows Communication Foundation (WCF)

Remover o protocolo Ssl3 dos padrões de transporte do WCF

Detalhes

Ao usar NetTcp com segurança de transporte e um tipo de credencial de certificado, o protocolo SSL 3 não é mais um protocolo padrão usado para negociar uma conexão segura. Na maioria dos casos, não deve haver impacto nos aplicativos existentes, pois o TLS 1.0 sempre foi incluído na lista de protocolos para NetTcp. Todos os clientes existentes devem ser capazes de negociar uma conexão usando pelo menos TLS1.0.

Sugestão

Se Ssl3 for necessário, use um dos seguintes mecanismos de configuração para adicionar Ssl3 à lista de protocolos negociados.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

Windows Presentation Foundation (WPF)

Alterar a propriedade IsEnabled do pai de um controle TextBlock afeta todos os controles filho

Detalhes

A partir do .NET Framework 4.6.2, alterar a propriedade System.Windows.UIElement.IsEnabled do progenitor de um controlo System.Windows.Controls.TextBlock afeta quaisquer controlos filho (como hiperlinks e botões) do controlo System.Windows.Controls.TextBlock. No .NET Framework 4.6.1 e nas versões anteriores, os controlos dentro de um System.Windows.Controls.TextBlock nem sempre refletiam o estado da propriedade System.Windows.UIElement.IsEnabled do progenitor System.Windows.Controls.TextBlock.

Sugestão

Nenhum. Essa alteração está em conformidade com o comportamento esperado para controles dentro de um System.Windows.Controls.TextBlock controle.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

CoerceIsSelectionBoxRealçado

Detalhes

Certas sequências de ações envolvendo um System.Windows.Controls.ComboBox e a sua fonte de dados podem resultar em um System.NullReferenceException.

Sugestão

Se possível, atualize para o .NET Framework 4.6.2.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6
Tipo Tempo de execução

APIs afetadas

DataGridCellsPanel.BringIndexIntoView lança ArgumentOutOfRangeException

Detalhes

ScrollIntoView(Object) funcionará de forma assíncrona quando a virtualização de colunas estiver ativada, mas as larguras das colunas ainda não tiverem sido determinadas. Se as colunas forem removidas antes que o trabalho assíncrono aconteça, pode ocorrer um System.ArgumentOutOfRangeException .

Sugestão

Qualquer um dos seguintes:

  • Atualize para o .NET Framework 4.7.
  • Instale o patch de manutenção mais recente para o .NET Framework 4.6.2.
  • Evite remover colunas até que a resposta assíncrona a ScrollIntoView(Object) tenha sido concluída.
Nome Valor
Âmbito de aplicação Borda
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

Rolagem horizontal e virtualização

Detalhes

Essa alteração se aplica a um System.Windows.Controls.ItemsControl que faz sua própria virtualização na direção ortogonal para a direção de rolagem principal (o exemplo principal é System.Windows.Controls.DataGrid com EnableColumnVirtualization="True"). O resultado de certas operações de rolagem horizontal foi alterado para produzir resultados mais intuitivos e mais análogos aos resultados de operações verticais comparáveis.

As operações incluem "Scroll Here" e "Right Edge", para usar os nomes do menu obtido clicando com o botão direito do mouse em uma barra de rolagem horizontal. Ambos calculam um deslocamento candidato e chamam SetHorizontalOffset(Double).

Depois de rolar para o novo deslocamento, a noção de "aqui" ou "borda direita" pode ter mudado porque o conteúdo não virtual recém-adicionado alterou o valor de System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth.

Antes do .NET Framework 4.6.2, a operação de rolagem simplesmente usa o deslocamento candidato, mesmo que ele não esteja mais "aqui" ou na "borda direita". Isso resulta em efeitos, como "o polegar da barra de rolagem saltando", como ilustrado no exemplo. Suponha que um System.Windows.Controls.DataGrid tem ExtentWidth=1000 e Width=200. Um scroll até "Borda Direita" utiliza um deslocamento candidato de 1000 - 200 = 800. Ao rolar para esse deslocamento, novas colunas são desvirtualizadas; Vamos supor que elas são muito amplas, fazendo com que o System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth mude para 2000. A rolagem termina com HorizontalOffset=800, e o botão deslizante "retorna" para perto do meio da barra de rolagem - precisamente em 800/2000 = 40%.

A mudança é recalcular um novo deslocamento candidato quando essa situação ocorrer e tentar novamente. (É assim que a rolagem vertical já funciona.)

A alteração produz uma experiência mais previsível e intuitiva para o usuário final, mas também pode afetar qualquer aplicativo que dependa do valor exato de System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset após uma rolagem horizontal, seja invocada pelo usuário final ou por uma chamada explícita para SetHorizontalOffset(Double).

Sugestão

Um aplicativo que usa um valor previsto para System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset deve ser alterado para buscar o valor real (e o valor de System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) após qualquer rolagem horizontal que possa alterar System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth devido à desvirtualização.

Nome Valor
Âmbito de aplicação Menor
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

Items.Clear não remove duplicados de SelectedItems

Detalhes

Suponha que um Seletor (com a seleção múltipla habilitada) tenha duplicatas em sua System.Windows.Controls.Primitives.MultiSelector.SelectedItems coleção - o mesmo item aparece mais de uma vez. A remoção desses itens da fonte de dados (por exemplo, chamando Items.Clear) não consegue removê-los do System.Windows.Controls.Primitives.MultiSelector.SelectedItems; apenas a primeira instância é removida. Além disso, o uso subsequente de System.Windows.Controls.Primitives.MultiSelector.SelectedItems (por exemplo, SelectedItems.Clear()) pode encontrar problemas como System.ArgumentException, porque System.Windows.Controls.Primitives.MultiSelector.SelectedItems contém itens que não estão mais na fonte de dados.

Sugestão

Atualize, se possível, para o .NET Framework 4.6.2.

Nome Valor
Âmbito de aplicação Menor
Versão 4,5
Tipo Tempo de execução

APIs afetadas

Deslizar itens em uma lista plana com itens de diferentes alturas em pixels

Detalhes

Quando um System.Windows.Controls.ItemsControl exibe uma coleção com virtualização (IsVirtualizing=true) e rolagem de itens (ScrollUnit=Item), o controlo rola para apresentar um item cuja altura em pixels difere dos seus vizinhos, e então o System.Windows.Controls.VirtualizingStackPanel percorre todos os itens da coleção. A interface do usuário não responde durante essa iteração. A iteração ocorre em outras circunstâncias, mesmo em versões anteriores do .NET Framework. Por exemplo, ocorre quando o deslocamento de pixels (ScrollUnit=Pixel) se depara com um item de altura de pixel diferente. Além disso, quando ocorre a rolagem de itens em dados hierárquicos (como um System.Windows.Controls.TreeView ou um System.Windows.Controls.ItemsControl com agrupamento habilitado) ao encontrar um item com um número de descendentes diferente comparado com os seus vizinhos. No caso de rolagem de itens e altura de pixel diferente, a iteração foi introduzida no .NET Framework 4.6.1 para corrigir bugs no layout de dados hierárquicos. Não é necessário se os dados forem simples (sem hierarquia) e o .NET Framework 4.6.2 não o fizer nesse caso.

Sugestão

Se a iteração ocorrer no .NET Framework 4.6.1, mas não em versões anteriores - ou seja, se o System.Windows.Controls.ItemsControl estiver a fazer scroll numa lista plana cujos itens têm altura de pixel variável - existem duas soluções:

  • Instale o .NET Framework 4.6.2.
  • Instale o hotfix HR 1605 para .NET Framework 4.6.1.
Nome Valor
Âmbito de aplicação Menor
Versão 4.6.1
Tipo Tempo de execução

APIs afetadas

O plano de fundo do RibbonGroup é definido como transparente em compilações localizadas

Detalhes

System.Windows.Controls.Ribbon.RibbonGroup o plano de fundo em compilações localizadas sempre foi pintado com pincel transparente, resultando em uma experiência de interface do usuário ruim. Foi corrigido na atualização do WPF do .NET Framework 4.7 ao atualizar os recursos localizados para System.Windows.Controls.Ribbon.RibbonGroup, o que, por sua vez, garante que o pincel correto seja selecionado.

Sugestão

Atualizar para o .NET Framework 4.7

Nome Valor
Âmbito de aplicação Borda
Versão 4.6.2
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

A verificação ortográfica do WPF falha de maneiras inesperadas

Detalhes

Isso inclui uma série de problemas do Corretor Ortográfico do WPF:

  • WPF Verificador Ortográfico às vezes gera System.Runtime.InteropServices.COMException
  • WPF Corretor ortográfico falha com UnauthorizedAccessException quando as aplicações são iniciadas usando 'executar como um utilizador diferente'
  • O Corretor Ortográfico do WPF identifica incorretamente erros ortográficos em palavras compostas como 'Hausnummer' em alemão.

Sugestão

Problema #1 - Isso foi corrigido no .NET Framework 4.6.2 Problema #2 - O Corretor Ortográfico do WPF não é mais suportado quando os aplicativos são iniciados usando 'executar como usuário diferente'. A partir do .NET Framework 4.6.2, os aplicativos iniciados dessa maneira não falharão mais inesperadamente - em vez disso, o Corretor Ortográfico será desativado silenciosamente. Problema #3 - Isso foi corrigido no .NET Framework 4.6.2.

Nome Valor
Âmbito de aplicação Borda
Versão 4.6.1
Tipo Tempo de execução

APIs afetadas

Não detetável através da análise API.

  • Last updated on