Alterações de runtime para a migração do .NET Framework 4.6.x

Esse artigo lista os problemas de compatibilidade do aplicativo introduzidos no .NET Framework 4.6 ,4.6.1 e 4.6.2 .

.NET Framework 4.6

ASP.NET

GridViews com AllowCustomPaging definido como verdadeiro pode acionar o evento PageIndexChanging ao deixar a página final do modo de exibiçã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 com System.Web.UI.WebControls.GridView.AllowCustomPaging habilitado.

Sugestão

Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework. Como solução alternativa, o aplicativo pode fazer um BindGrid explícito em qualquer Page_Load que respeite essas condições (o 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 da paginação personalizada), uma vez que esse cenário não demonstra o problema.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• GridView.AllowCustomPaging

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, objetos ConcurrentDictionary<TKey,TValue> 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-se no outro sentido (serializar com o .NET Framework 4.5.x e desserializar com o .NET Framework 4.5) funciona. Da mesma forma, todas as serializações entre versões 4. x funcionam com o .NET Framework 4.6. A possibilidade de serializar e desserializar com uma única versão do .NET Framework não é afetada.

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, deverá ser usado em vez do System.Runtime.Serialization.NetDataContractSerializer. Como alternativa, uma vez que esse problema foi resolvido no .NET Framework 4.6, ele pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

AppDomainSetup.DynamicBase não é mais randomizado por UseRandomizedStringHashAlgorithm

Detalhes

Antes do .NET Framework 4.6, o valor de DynamicBase seria randomizado entre domínios de aplicativos 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 instâncias diferentes de um aplicativo em execução e entre diferentes domínios de aplicativo. Bases dinâmicas ainda serão diferentes para diferentes aplicativos. Essa alteração remove apenas o elemento de nomenclatura aleatório para instâncias diferentes do mesmo aplicativo.

Sugestão

Lembre-se de que habilitar UseRandomizedStringHashAlgorithm não fará com que DynamicBase seja randomizado. Se for necessária uma base aleatória, ela deverá ser produzida no código do aplicativo, e não por meio dessa API.

Nome	Valor
Escopo	Microsoft Edge
Versão	4,6
Tipo	Runtime

APIs afetadas

• AppDomainSetup.DynamicBase

Chamar Attribute.GetCustomAttributes na propriedade de um indexador não vai mais gerar AmbiguousMatchException se a ambiguidade puder ser resolvida pelo tipo do índice

Detalhes

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

Sugestão

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4,6
Tipo	Runtime

APIs afetadas

• Attribute.GetCustomAttribute(MemberInfo, Type)
• Attribute.GetCustomAttribute(MemberInfo, Type, Boolean)
• Attribute.GetCustomAttributes(MemberInfo)
• Attribute.GetCustomAttributes(MemberInfo, Boolean)
• Attribute.GetCustomAttributes(MemberInfo, Type)
• Attribute.GetCustomAttributes(MemberInfo, Type, Boolean)
• CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type)
• CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type, Boolean)
• CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo)
• CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo, Boolean)
• CustomAttributeExtensions.GetCustomAttributes(MemberInfo)
• CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Boolean)
• CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type)
• CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type, Boolean)
• CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo)
• CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo, Boolean)

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

Detalhes

No .NET Framework v4.5.1, a API de criação de perfil RootReferences2(), de maneira incorreta, nunca retorna COR_PRF_GC_ROOT_HANDLE (que, em vez disso, é retornada como COR_PRF_GC_ROOT_OTHER). Esse problema foi corrigido a partir do .NET Framework 4.6.

Sugestão

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

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

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

Detalhes

EventListeners do ETW com uma máscara de palavra-chave em branco não capturam eventos corretamente dos 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 apresentarem mais esse problema.

Sugestão

Para contornar esse problema, substitua as chamadas para EnableEvents(EventSource, EventLevel) por chamadas para a sobrecarga de EnableEvents com especificação explícita da máscara "qualquer palavra-chave" a ser usada: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• EventListener.EnableEvents(EventSource, EventLevel)

O calendário persa agora usa o algoritmo solar islâmico

Detalhes

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

Sugestão

Lembre-se de que algumas datas anteriores ou posteriores podem ser um pouco diferentes quando se usa 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 armazene-as como cadeias de caracteres de data PersianCalendar (uma vez que esses valores podem ser diferentes).

Nome	Valor
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

• System.Globalization.PersianCalendar

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

Detalhes

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

• System.Reflection.Assembly
• System.Reflection.MemberInfo (e seus tipos derivados, incluindo System.Reflection.FieldInfo, System.Reflection.MethodInfo, System.Type e System.Reflection.TypeInfo)
• System.Reflection.MethodBody
• System.Reflection.Module
• System.Reflection.ParameterInfo

Chamadas a IMarshal para o retorno do objeto E_NOINTERFACE.

Sugestão

Atualize o código de marshaling para trabalhar com objetos de não reflexão.

Nome	Valor
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

• System.Reflection.Assembly
• System.Reflection.FieldInfo
• System.Reflection.MemberInfo
• System.Reflection.MethodBody
• System.Reflection.MethodInfo
• System.Reflection.Module
• System.Reflection.ParameterInfo
• System.Reflection.TypeInfo
• System.Type

TargetFrameworkName para o domínio de aplicativo padrão não será mais padronizado como nulo se não for definido

Detalhes

O System.AppDomainSetup.TargetFrameworkName era nulo anteriormente no domínio de aplicativo padrão, a menos que fosse explicitamente definido. A partir da 4.6, a propriedade System.AppDomainSetup.TargetFrameworkName para o domínio de aplicativo padrão terá um valor padrão derivado do TargetFrameworkAttribute (se um estiver presente). Os domínios de aplicativo não padrão continuarão herdando o respectivo System.AppDomainSetup.TargetFrameworkName do domínio de aplicativo padrão (que não será padronizado para nulo na 4.6), a menos que sejam explicitamente substituídos.

Sugestão

O código deve ser atualizado para não depender do TargetFrameworkName que padroniza para nulo. Se for necessário que essa propriedade continue sendo avaliada como nula, ela poderá ser explicitamente definida para esse valor.

Nome	Valor
Escopo	Microsoft Edge
Versão	4,6
Tipo	Runtime

APIs afetadas

• AppDomainSetup.TargetFrameworkName

Agora, o X509Certificate2.ToString(Boolean) não é gerado quando o .NET não pode tratar o certificado

Detalhes

No .NET Framework 4.5.2 e nas versões anteriores, esse método era gerado quando true era passado para o parâmetro verbose e havia certificados instalados que não eram compatíveis com o .NET Framework. Agora, o método será bem-sucedido e retornará uma cadeia de caracteres válida que omita as partes inacessíveis do certificado.

Sugestão

Qualquer código dependente do X509Certificate2.ToString(Boolean) deve ser atualizado para esperar que a cadeia de caracteres retornada possa excluir alguns dados do certificado (como chave pública, chave privada e extensões) em alguns casos nos quais a API teria sido gerada anteriormente.

Nome	Valor
Escopo	Microsoft Edge
Versão	4,6
Tipo	Runtime

APIs afetadas

• X509Certificate2.ToString(Boolean)

Dados

Falha ao tentar uma conexão TCP/IP com um banco de dados do SQL Server resolvida para localhost

Detalhes

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

Sugestão

Esse problema foi resolvido e o comportamento anterior restaurado no .NET Framework 4.6.2. Para se conectar a um banco de dados do SQL Server que seja resolvido para localhost, faça a atualização para o .NET Framework 4.6.2.

Nome	Valor
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Depurador

Valores nulos de união não são visíveis no depurador até uma etapa posterior

Detalhes

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

Sugestão

Colocar um tempo adicional no depurador fará com que o valor do local/campo seja atualizado corretamente. Além disso, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Rede

ContentDisposition DateTimes retorna cadeia de caracteres ligeiramente diferente

Detalhes

As representações de cadeia de caracteres de System.Net.Mime.ContentDisposition foram atualizadas, a partir da versão 4.6, para sempre representarem o componente de hora de um System.DateTime com dois dígitos. Isso está em conformidade com a RFC822 e RFC2822. Isso faz com que ToString() retorne uma cadeia de caracteres ligeiramente diferente na versão 4.6 em cenários em que um dos elementos de tempo da disposição era anterior a 10:00 AM. Observe que ContentDispositions, às vezes, são serializados por meio de conversão em cadeias de caracteres, de modo que quaisquer operações ToString(), serialização ou chamadas GetHashCode devem ser revisadas.

Sugestão

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

Nome	Valor
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

• ContentDisposition.ToString()
• ContentDisposition.GetHashCode()

Serialização

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

Detalhes

A partir do .NET Framework 4.6, a mensagem de exceção gerada se a serialização ou desserialização de System.Runtime.Serialization.DataContractSerializer ou System.Runtime.Serialization.Json.DataContractJsonSerializer falhar por causa de "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 que ele espere a nova mensagem ou, preferencialmente, altere-o para depender somente do tipo de exceção.

Nome	Valor
Escopo	Microsoft Edge
Versão	4,6
Tipo	Runtime

APIs afetadas

• DataContractJsonSerializer(Type)
• DataContractJsonSerializer(Type, IEnumerable<Type>)
• DataContractJsonSerializer(Type, DataContractJsonSerializerSettings)
• DataContractJsonSerializer(Type, String)
• DataContractJsonSerializer(Type, String, IEnumerable<Type>)
• DataContractJsonSerializer(Type, XmlDictionaryString)
• DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>)
• DataContractJsonSerializer(Type, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
• DataContractJsonSerializer(Type, String, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
• DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
• DataContractSerializer(Type)
• DataContractSerializer(Type, DataContractSerializerSettings)
• DataContractSerializer(Type, IEnumerable<Type>)
• DataContractSerializer(Type, String, String)
• DataContractSerializer(Type, String, String, IEnumerable<Type>)
• DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString)
• DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>)
• DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
• DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
• DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
• DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
• DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
• DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)

Instalação e Implantação

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

Detalhes

O controle de versão do produto foi alterado nas versões anteriores do .NET Framework, especialmente do .NET Framework 4, 4.5, 4.5.1 e 4.5.2. Veja a seguir as alterações em detalhes:

• O valor da entrada Version na chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full foi alterado para 4.6.xxxxx para o .NET Framework 4.6 e suas versões pontuais, e para 4.7.xxxxx para o .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 exibe as Propriedades do arquivo depois de clicar com o botão direito do mouse em um arquivo.
• Os atributos AssemblyFileVersionAttribute e AssemblyInformationalVersionAttribute para assemblies gerenciados têm valores de Versão 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 propriedade Environment.Version retorna a cadeia de caracteres de versão fixa 4.0.30319.42000. No .NET Framework 4, 4.5, 4.5.1 e 4.5.2, ela retorna as cadeias de caracteres de versão no formato 4.0.30319.xxxxx (por exemplo, "4.0.30319.18010"). Não é recomendável criar nova dependência de código de aplicativo na 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 detecção de itens como a versão de runtime do .NET Framework e o diretório de instalação:

• Para detectar a versão de runtime do .NET Framework, confira How to: Determine Which .NET Framework Versions Are Installed (Como determinar quais versões do .NET Framework estão instaladas).
• Para determinar o caminho de instalação do .NET Framework, use o valor da entrada InstallPath na chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full.

Importante

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

• Para determinar o caminho do diretório do Common Language Runtime do .NET Framework, chame o método RuntimeEnvironment.GetRuntimeDirectory().
• Para obter a versão do CLR, chame o método RuntimeEnvironment.GetSystemVersion(). Para o .NET Framework 4 e suas versões pontuais (o .NET Framework 4.5, 4.5.1, 4.5.2 e o .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
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

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

Detalhes

Como é de se esperar, a chave de versão definida no registro (em HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) do .NET Framework 4.6 começa com "4.6", e não "4.5". Os aplicativos que dependem dessas chaves do Registro para saber quais versões do .NET Framework estão instaladas em um computador precisam ser atualizados para compreenderem que 4.6 é uma nova versão possível, compatível com as versões 4.5.x anteriores.

Sugestão

Atualize os aplicativos que estão investigando uma instalação do .NET Framework 4.5 procurando por chaves do Registro 4.5 que também aceitam 4.6.

Nome	Valor
Escopo	Microsoft Edge
Versão	4,6
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Windows Communication Foundation (WCF)

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

Detalhes

O .NET Framework 4.6 adiciona o TLS 1.1 e o TLS 1.2 à lista padrão de protocolos SSL do WCF. Quando os computadores cliente e servidor têm o .NET Framework 4.6 ou versões posteriores instaladas, o TLS 1.2 é usado para negociação. O TLS 1.2 não é compatível com a autenticação do certificado MD5. Consequentemente, se um cliente usar um certificado MD5, o cliente WCF falhará ao se conectar ao serviço WCF.

Sugestão

Você pode contornar esse problema para que um cliente WCF possa 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 tiver sido configurada dinamicamente no código-fonte, atualize o arquivo de configuração de aplicativo para usar o TLS 1.1 ou uma versão anterior do protocolo. Isso permite que você continue usando um certificado com o algoritmo de hash MD5.

Aviso

Essa solução alternativa não é recomendada, pois um certificado com o algoritmo de hash MD5 é considerado inseguro.

O arquivo de configuração que se segue demonstra 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>

• Se a associação foi configurada dinamicamente no código-fonte, atualize a propriedade TcpTransportSecurity.SslProtocols para usar o TLS 1.1 (SslProtocols.Tls11) ou uma versão anterior do protocolo no código-fonte.

Aviso

Essa solução alternativa não é recomendada, pois um certificado com o algoritmo de hash MD5 é considerado inseguro.

Nome	Valor
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Windows Presentation Foundation (WPF)

Acessar os itens selecionados de um DataGrid do WPF em um manipulador do evento UnloadingRow do DataGrid pode gerar NullReferenceException

Detalhes

Por causa de um bug no .NET Framework 4.5, os manipuladores de eventos DataGrid que envolvem a remoção de uma linha podem gerar System.NullReferenceException se acessarem as propriedades System.Windows.Controls.Primitives.Selector.SelectedItem ou System.Windows.Controls.Primitives.MultiSelector.SelectedItems de DataGrid.

Sugestão

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

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• DataGrid.UnloadingRow
• DataGrid.UnloadingRowDetails

Chamar Items.Refresh em uma ListBox, ListView ou DataGrid do WPF com itens selecionados pode exibir itens duplicados no elemento

Detalhes

No .NET Framework 4.5, chamar ListBox.Items.Refresh do código enquanto itens estiverem selecionados em uma System.Windows.Controls.ListBox pode fazer com que os itens selecionados sejam duplicados na lista. Ocorre um problema semelhante com System.Windows.Controls.ListView e System.Windows.Controls.DataGrid. Isso foi corrigido no .NET Framework 4.6.

Sugestão

Esse problema pode ser contornado de forma programática cancelando a seleção dos itens antes de chamar System.Windows.Data.CollectionView.Refresh() e selecionando-os novamente após a conclusão da chamada. Como alternativa, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• CollectionView.Refresh()

CoerceIsSelectionBoxHighlighted

Detalhes

Determinadas sequências de ações que envolvem um System.Windows.Controls.ComboBox e 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
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

• ComboBox.IsSelectionBoxHighlighted

Problema de associação de ListBoxItem IsSelected com ObservableCollection<T>.Move

Detalhes

Chamar Move(Int32, Int32) ou MoveItem(Int32, Int32) em uma coleção associada a um System.Windows.Controls.ListBox com itens selecionados pode gerar comportamento imprevisível em seleções ou cancelamentos de seleção futuros de itens System.Windows.Controls.ListBox.

Sugestão

Chamar System.Collections.ObjectModel.Collection<T>.Remove(T) e System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) em vez de Move(Int32, Int32) é uma solução alternativa para esse problema. Como alternativa, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• ObservableCollection<T>.Move(Int32, Int32)
• ObservableCollection<T>.MoveItem(Int32, Int32)

Clicar com o botão direito do mouse em um cabeçalho de linha do DataGrid do WPF altera a seleção de DataGrid

Detalhes

Clicar com o botão direito do mouse em um cabeçalho de linha System.Windows.Controls.DataGrid enquanto várias linhas estão selecionadas altera a seleção de System.Windows.Controls.DataGrid para somente a linha em questão.

Sugestão

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• DataGrid()

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

Detalhes

Um problema foi introduzido na versão 4.5.2 que faz com que wisptis.exe seja gerado e possa congelar a entrada do mouse.

Sugestão

A correção desse problema está disponível em uma versão de serviço do .NET Framework 4.5.2 (hotfix de rollup 3026376) ou por meio da atualização para o .NET Framework 4.6.

Nome	Valor
Escopo	Principal
Versão	4.5.2
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

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

Detalhes

Ao ser executado no Windows 10, o verificador ortográfico pode não funcionar em controles habilitados por texto do WPF, pois as funcionalidades da plataforma de verificação ortográfica estão disponíveis somente para os 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) que oferece as funcionalidades de verificação ortográfica. Ao adicionar o idioma à lista de idiomas de entrada, o verificador ortográfico terá suporte.

Sugestão

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4,6
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Janelas do WPF são renderizadas sem distorção ao se estender para fora de um único monitor

Detalhes

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

Sugestão

Esse comportamento (com distorção ou não) pode ser definido explicitamente usando o elemento <EnableMultiMonitorDisplayClipping> em <appSettings> no arquivo de configuração do aplicativo ou definindo a propriedade EnableMultiMonitorDisplayClipping durante a inicialização do aplicativo.

Nome	Valor
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

.NET Framework 4.6.1

Ferramentas

Contract.Invariant e Contract.Requires<TException> não consideram String.IsNullOrEmpty puro

Detalhes

No caso de aplicativos destinados ao .NET Framework 4.6.1, se o contrato invariável de Contract.Invariant ou contrato de pré-condição de Requires chamar o método String.IsNullOrEmpty, o regravador emitirá um aviso do compilador CC1036: "Chamada detectada para o método 'System.String.IsNullOrWhiteSpace(System.String)' sem [Pure] no método.". Este é um aviso do compilador, não um erro.

Sugestão

Esse comportamento foi abordado em Problema nº 339 no GitHub. Para eliminar esse aviso, você pode baixar e compilar uma versão atualizada do código-fonte para a ferramenta de Contratos de Código no GitHub. As informações para download são encontradas no fim da página.

Nome	Valor
Escopo	Secundária
Versão	4.6.1
Tipo	Runtime

APIs afetadas

• Contract.Invariant(Boolean)
• Contract.Requires(Boolean)

Windows Presentation Foundation (WPF)

Rolagem de itens em uma lista simples de itens com diferentes alturas em pixels

Detalhes

Quando um System.Windows.Controls.ItemsControl exibe uma coleção usando virtualização (IsVirtualizing=true) e rolagem de itens (ScrollUnit=Item) e quando o controle rola para exibir um item cuja altura em pixels é diferente de seus vizinhos, o System.Windows.Controls.VirtualizingStackPanel itera em todos os itens na 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, isso ocorre na rolagem de pixels (ScrollUnit=Pixel) ao encontrar um item com uma altura de pixels diferente e na rolagem de itens de dados hierárquicos (como em um System.Windows.Controls.TreeView ou um System.Windows.Controls.ItemsControl com o agrupamento habilitado) ao encontrar um item com um número de itens descendentes diferentes de seus vizinhos. Para o caso em que há rolagem de itens e diferentes alturas em pixels, a iteração foi introduzida no .NET Framework 4.6.1 para corrigir bugs no layout de dados hierárquicos. Ela não será necessária se os dados forem simples (sem hierarquia) e, nesse caso, ela não ocorre no .NET Framework 4.6.2.

Sugestão

Se a iteração ocorrer no .NET Framework 4.6.1, mas não nas versões anteriores, ou seja, se o System.Windows.Controls.ItemsControl for uma lista plana de rolagem de item com itens de alturas em pixels diferentes, haverá duas soluções:

• Instalar o .NET Framework 4.6.2.
• Instalar o hotfix HR 1605 para o .NET Framework 4.6.1.

Nome	Valor
Escopo	Secundária
Versão	4.6.1
Tipo	Runtime

APIs afetadas

• System.Windows.Controls.VirtualizingStackPanel

ObjectDisposedException gerada pelo verificador ortográfico do WPF

Detalhes

Ocasionalmente, os aplicativos WPF falham durante o desligamento com uma System.ObjectDisposedException gerada pelo verificador ortográfico. Isso foi corrigido no WPF do .NET Framework 4.7 por meio do tratamento normal da exceção, garantindo que os aplicativos não sejam mais prejudicados. Observe que exceções de primeira chance ocasionais continuariam a ser observadas em aplicativos em execução em um depurador.

Sugestão

Atualizar para o .NET Framework 4.7

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

A Verificação Ortográfica do WPF falha de formas inesperadas

Detalhes

Isso inclui alguns problemas da Verificação Ortográfica do WPF:

• Às vezes, a Verificação Ortográfica do WPF gera System.Runtime.InteropServices.COMException
• A Verificação Ortográfica do WPF falha com UnauthorizedAccessException quando aplicativos são iniciados usando "Executar como usuário diferente"
• O Verificador Ortográfico do WPF identifica incorretamente erros ortográficos em palavras compostas, como "Hausnummer" em alemão.

Sugestão

Problema nº 1 – esse problema foi corrigido no .NET Framework 4.6.2 Problema nº 2 – a Verificação Ortográfica do WPF deixou de ter suporte quando aplicativos são iniciados usando "Executar como usuário diferente". A partir do .NET Framework 4.6.2, aplicativos iniciados dessa maneira não falharão inesperadamente, em vez disso, a Verificação Ortográfica será desabilitada silenciosamente. Problema nº 3 – esse problema foi corrigido no .NET Framework 4.6.2.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

.NET Framework 4.6.2

Dados

Falha ao tentar uma conexão TCP/IP com um banco de dados do SQL Server resolvida para localhost

Detalhes

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

Sugestão

Esse problema foi resolvido e o comportamento anterior restaurado no .NET Framework 4.6.2. Para se conectar a um banco de dados do SQL Server que seja resolvido para localhost, faça a atualização para o .NET Framework 4.6.2.

Nome	Valor
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Período de bloqueio do pool de conexões para bancos de dados SQL do Azure removido

Detalhes

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

No .NET Framework 4.6.1 e nas versões anteriores, quando um aplicativo encontra uma falha de conexão transitória ao conectar-se a um banco de dados, a tentativa de conexão não pode ser repetida rapidamente, porque o pool de conexões armazena o erro em cache e o gera novamente por um intervalo que varia de cinco segundos a um 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, muitas vezes, falham com erros transitórios que normalmente são recuperados em alguns 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 ser renderizado em alguns segundos.

Sugestão

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

• AlwaysBlock
• Auto
• NeverBlock

É possível restaurar o comportamento anterior definindo a propriedade System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod como AlwaysBlock.

Nome	Valor
Escopo	Secundária
Versão	4.6.2
Tipo	Runtime

APIs afetadas

• DbConnection.OpenAsync()
• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

Globalização

Categorias do padrão Unicode versão 8.0 agora são compatíveis

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 a categorias de caracteres Unicode no .NET Framework 4.6.2, alguns resultados poderão não corresponder aos resultados nas versões anteriores do .NET Framework. Essa alteração afeta principalmente as sílabas Cheroqui, bem como os símbolos vocálicos e as marcas de tom Tai Lue Novo.

Sugestão

Examine o código e remova ou altere a lógica que depende de categorias de caractere Unicode embutido em código.

Nome	Valor
Escopo	Secundária
Versão	4.6.2
Tipo	Runtime

APIs afetadas

• Char.GetUnicodeCategory(Char)
• CharUnicodeInfo.GetUnicodeCategory(Char)
• CharUnicodeInfo.GetUnicodeCategory(String, Int32)

Segurança

RSACng e DSACng podem ser usados novamente em cenários de confiança parcial

Detalhes

CngLightup (usado em várias APIs de criptografia de nível mais elevado, como System.Security.Cryptography.Xml.EncryptedXml) e System.Security.Cryptography.RSACng, em alguns casos, dependem da confiança total. Eles incluem P/Invokes sem declarar permissões de SecurityPermissionFlag.UnmanagedCode e caminhos de código em que System.Security.Cryptography.CngKey tem demandas de permissão de SecurityPermissionFlag.UnmanagedCode. A partir do .NET Framework 4.6.2, CngLightup foi usado para mudar para System.Security.Cryptography.RSACng sempre que possível. Como resultado, aplicativos de confiança parcial que usavam System.Security.Cryptography.Xml.EncryptedXml com êxito começaram a falhar e a lançar exceções SecurityException. Essa alteração adiciona as declarações necessárias para que todas as funções que usam CngLightup tenham as permissões necessárias.

Sugestão

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Runtime

APIs afetadas

• DSACng(CngKey)
• DSACng.Key
• DSACng.LegalKeySizes
• DSACng.CreateSignature(Byte[])
• DSACng.VerifySignature(Byte[], Byte[])
• RSACng(CngKey)
• RSACng.Key
• RSACng.Decrypt(Byte[], RSAEncryptionPadding)
• RSACng.SignHash(Byte[], HashAlgorithmName, RSASignaturePadding)

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

Detalhes

A partir do .NET Framework 4.6.2, esse método retornará False se a assinatura em si estiver incorretamente formatada. Agora, ele retornará false para qualquer falha de verificação. No .NET Framework 4.6 e 4.6.1, o método gera System.Security.Cryptography.CryptographicException se a assinatura em si está incorretamente formatada.

Sugestão

Qualquer código cuja execução dependa da identificação de System.Security.Cryptography.CryptographicException deverá ser executado se a validação falhar e o método retornar False.

Nome	Valor
Escopo	Secundária
Versão	4.6.2
Tipo	Runtime

APIs afetadas

• RSACng.VerifyHash(Byte[], Byte[], HashAlgorithmName, RSASignaturePadding)

Alterações de falha de 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 resultam em diferentes comportamentos de runtime. Por exemplo:

• Se um documento tiver vários elementos com o mesmo atributo id e uma assinatura tiver como destino um desses elementos como a raiz da assinatura, o documento agora será considerado inválido.
• Documentos que usam algoritmos de transformação XPath não canônicos nas referências agora são considerados inválidos.
• Documentos que usam algoritmos de transformação XSLT não canônicos nas referências agora são considerados inválidos.
• Nenhum programa que usar assinaturas desanexadas de recursos externos poderá fazer isso.

Sugestão

Talvez os desenvolvedores queiram revisar o uso de XmlDsigXsltTransform e XmlDsigXsltTransform, bem como dos tipos derivados de Transform, uma vez que o receptor de um documento poderá não conseguir processá-lo.

Nome	Valor
Escopo	Secundária
Versão	4.6.2
Tipo	Runtime

APIs afetadas

• System.Security.Cryptography.Xml.Transform
• System.Security.Cryptography.Xml.XmlDsigXPathTransform
• System.Security.Cryptography.Xml.XmlDsigXsltTransform

Windows Communication Foundation (WCF)

Remoção de Ssl3 de TransportDefaults do WCF

Detalhes

Ao usar NetTcp com segurança de transporte e um tipo de credencial de certificado, o 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 esteve incluído na lista de protocolos para NetTcp. Todos os clientes existentes devem ser capazes de negociar uma conexão usando, no mínimo, o TLS 1.0.

Sugestão

Se Ssl3 for exigido, use um dos seguintes mecanismos de configuração para adicioná-lo à lista de protocolos negociados.

• SslProtocols
• SslProtocols
• <transport> de <netTcpBinding>
• <sslStreamSecurity>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Runtime

APIs afetadas

• SslStreamSecurityBindingElement.SslProtocols
• TcpTransportSecurity.SslProtocols

Windows Presentation Foundation (WPF)

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

Detalhes

A partir do .NET Framework 4.6.2, alterar a propriedade System.Windows.UIElement.IsEnabled do pai de um controle System.Windows.Controls.TextBlock afetará os controles filho (como hiperlinks e botões) do controle System.Windows.Controls.TextBlock. No .NET Framework 4.6.1 e versões anteriores, os controles dentro de System.Windows.Controls.TextBlock nem sempre refletiam o estado da propriedade System.Windows.UIElement.IsEnabled do pai System.Windows.Controls.TextBlock.

Sugestão

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

Nome	Valor
Escopo	Secundária
Versão	4.6.2
Tipo	Runtime

APIs afetadas

• UIElement.IsEnabled

CoerceIsSelectionBoxHighlighted

Detalhes

Determinadas sequências de ações que envolvem um System.Windows.Controls.ComboBox e 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
Escopo	Secundária
Versão	4,6
Tipo	Runtime

APIs afetadas

• ComboBox.IsSelectionBoxHighlighted

DataGridCellsPanel.BringIndexIntoView gera ArgumentOutOfRangeException

Detalhes

ScrollIntoView(Object) será executado assincronamente quando a virtualização de coluna estiver habilitada, mas as larguras das colunas ainda não estiverem determinadas. Se as colunas forem removidas antes da operação assíncrona, um System.ArgumentOutOfRangeException poderá ocorrer.

Sugestão

Siga um destes procedimentos:

• Atualize para o .NET Framework 4.7.
• Instale o patch de manutenção mais recente para o .NET Framework 4.6.2.
• Evitar remover colunas até que a resposta assíncrona ao método ScrollIntoView(Object) seja concluída.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Runtime

APIs afetadas

• DataGrid.ScrollIntoView(Object)
• DataGrid.ScrollIntoView(Object, DataGridColumn)

Rolagem horizontal e virtualização

Detalhes

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

As operações incluem “Rolar Aqui” e “Borda Direita”, para usar os nomes do menu obtidos ao clicar com o botão direito do mouse em uma barra de rolagem horizontal. Ambas calculam um deslocamento candidato e chamam SetHorizontalOffset(Double).

Depois de rolar para o novo deslocamento, a noção de “aqui” ou de “borda direita” poderá mudar, pois um conteúdo com a virtualização removida recentemente 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, embora ele talvez não seja mais “aqui” ou na “borda direita”. Isso resulta em efeitos de "salto" de rolagem, melhor ilustrado pelo exemplo. Suponha que um System.Windows.Controls.DataGrid tenha ExtentWidth = 1000 e Width = 200. Uma rolagem para a "Borda Direita" usa o deslocamento de candidato 1000 - 200 = 800. Durante a rolagem até esse deslocamento, a virtualização de novas colunas é eliminada. Vamos supor que elas sejam muito largas, então o System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth muda para 2000. A rolagem termina com HorizontalOffset=800 e o elevador retorna para perto do meio da barra de rolagem, precisamente em 800/2000 = 40%.

A alteração é para recalcular um novo deslocamento candidato quando essa situação ocorre e tentar novamente. (A rolagem vertical já funciona assim.)

A alteração proporciona 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 ela 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 obter o valor real (e o valor de System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) após qualquer rolagem horizontal que poderia alterar System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth devido à eliminação da virtualização.

Nome	Valor
Escopo	Secundária
Versão	4.6.2
Tipo	Runtime

APIs afetadas

• System.Windows.Controls.Primitives.IScrollInfo

Items.Clear não remove duplicatas de SelectedItems

Detalhes

Suponha que um Seletor (com seleção múltipla habilitada) tenha duplicatas em sua coleção System.Windows.Controls.Primitives.MultiSelector.SelectedItems – o mesmo item é exibido mais de uma vez. A remoção desses itens da fonte de dados (por exemplo, chamando Items.Clear) falha ao removê-los de System.Windows.Controls.Primitives.MultiSelector.SelectedItems; somente 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, pois 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
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• MultiSelector.SelectedItems

Rolagem de itens em uma lista simples de itens com diferentes alturas em pixels

Detalhes

Quando um System.Windows.Controls.ItemsControl exibe uma coleção usando virtualização (IsVirtualizing=true) e rolagem de itens (ScrollUnit=Item) e quando o controle rola para exibir um item cuja altura em pixels é diferente de seus vizinhos, o System.Windows.Controls.VirtualizingStackPanel itera em todos os itens na 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, isso ocorre na rolagem de pixels (ScrollUnit=Pixel) ao encontrar um item com uma altura de pixels diferente e na rolagem de itens de dados hierárquicos (como em um System.Windows.Controls.TreeView ou um System.Windows.Controls.ItemsControl com o agrupamento habilitado) ao encontrar um item com um número de itens descendentes diferentes de seus vizinhos. Para o caso em que há rolagem de itens e diferentes alturas em pixels, a iteração foi introduzida no .NET Framework 4.6.1 para corrigir bugs no layout de dados hierárquicos. Ela não será necessária se os dados forem simples (sem hierarquia) e, nesse caso, ela não ocorre no .NET Framework 4.6.2.

Sugestão

Se a iteração ocorrer no .NET Framework 4.6.1, mas não nas versões anteriores, ou seja, se o System.Windows.Controls.ItemsControl for uma lista plana de rolagem de item com itens de alturas em pixels diferentes, haverá duas soluções:

• Instalar o .NET Framework 4.6.2.
• Instalar o hotfix HR 1605 para o .NET Framework 4.6.1.

Nome	Valor
Escopo	Secundária
Versão	4.6.1
Tipo	Runtime

APIs afetadas

• System.Windows.Controls.VirtualizingStackPanel

Tela de fundo RibbonGroup é definida como transparente em builds localizados

Detalhes

A tela de fundo System.Windows.Controls.Ribbon.RibbonGroup em builds localizados sempre foi pintada com um pincel Transparente, o que resultava em uma experiência de interface do usuário ruim. Isso foi corrigido no WPF do .NET Framework 4.7 por meio da atualização dos recursos localizados para System.Windows.Controls.Ribbon.RibbonGroup, que, por sua vez, garante que o pincel correto seja selecionado.

Sugestão

Atualizar para o .NET Framework 4.7

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

A Verificação Ortográfica do WPF falha de formas inesperadas

Detalhes

Isso inclui alguns problemas da Verificação Ortográfica do WPF:

• Às vezes, a Verificação Ortográfica do WPF gera System.Runtime.InteropServices.COMException
• A Verificação Ortográfica do WPF falha com UnauthorizedAccessException quando aplicativos são iniciados usando "Executar como usuário diferente"
• O Verificador Ortográfico do WPF identifica incorretamente erros ortográficos em palavras compostas, como "Hausnummer" em alemão.

Sugestão

Problema nº 1 – esse problema foi corrigido no .NET Framework 4.6.2 Problema nº 2 – a Verificação Ortográfica do WPF deixou de ter suporte quando aplicativos são iniciados usando "Executar como usuário diferente". A partir do .NET Framework 4.6.2, aplicativos iniciados dessa maneira não falharão inesperadamente, em vez disso, a Verificação Ortográfica será desabilitada silenciosamente. Problema nº 3 – esse problema foi corrigido no .NET Framework 4.6.2.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.