Redirecionar alterações para migração para o .NET Framework 4.6.x

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

.NET Framework 4.6

ASP.NET

HtmlTextWriter não renderiza o elemento <br/> corretamente

Detalhes

A partir do .NET Framework 4.6, chamar RenderBeginTag(String) e RenderEndTag() com um elemento <BR /> vai inserir corretamente apenas um <BR /> (em vez de dois)

Sugestão

Se um aplicativo depender da marca <BR /> extra, RenderBeginTag(String) deverá ser chamado uma segunda vez. Observe que essa alteração de comportamento afeta apenas aplicativos destinados ao .NET Framework 4.6 ou versões posteriores, de modo que outra opção é destinar a uma versão anterior do .NET Framework a fim de obter o comportamento antigo.

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

APIs afetadas

• HtmlTextWriter.RenderBeginTag(String)
• HtmlTextWriter.RenderBeginTag(HtmlTextWriterTag)

ClickOnce

Os aplicativos publicados com ClickOnce que usam um certificado de autenticação de código SHA-256 podem falhar no Windows 2003

Detalhes

O executável é assinado com SHA256. Antes, ele era assinado com SHA1, independentemente se o certificado de assinatura de código era SHA-1 ou SHA-256. Isso se aplica a:

• Todos os aplicativos compilados com o Visual Studio 2012 ou posterior.
• Os aplicativos compilados com o Visual Studio 2010 ou anteriores em sistemas com o .NET Framework 4.5. Além disso, se o .NET Framework 4.5 ou posterior estiver presente, o manifesto do ClickOnce também será assinado com certificados SHA-256 para SHA-256, independentemente da versão do .NET Framework na qual ele foi compilado.

Sugestão

A mudança na assinatura do executável do ClickOnce afeta apenas os sistemas Windows Server 2003; eles exigem a instalação do KB 938397. A alteração na assinatura do manifesto com SHA-256, mesmo quando um aplicativo destina-se ao .NET Framework 4.0 ou versões anteriores, introduz uma dependência de runtime no .NET Framework 4.5 ou uma versão posterior.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Redirecionando

ClickOnce é compatível com SHA-256 em aplicativos destinados ao 4.0

Detalhes

Anteriormente, um aplicativo ClickOnce com um certificado assinado com SHA-256 exigia a presença do .NET Framework 4.5 ou posterior, mesmo se o aplicativo fosse direcionado ao 4.0. Agora, os aplicativos ClickOnce direcionados ao .NET Framework 4.0 podem ser executados no .NET Framework 4.0, mesmo quando assinados com SHA-256.

Sugestão

Essa alteração elimina essa dependência e permite que certificados SHA-256 sejam usados para assinar aplicativos ClickOnce destinados ao .NET Framework 4 e versões anteriores.

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

Núcleo

Fluxo CurrentCulture e CurrentUICulture atravessam tarefas

Detalhes

A partir do .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture são armazenados no System.Threading.ExecutionContext do thread, que atravessa operações assíncronas. Isso significa que as alterações em System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture serão refletidas em tarefas que posteriormente serão executadas de forma assíncrona. Isso é diferente do comportamento das versões anteriores do .NET Framework (que redefiniria System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture em todas as tarefas assíncronas).

Sugestão

Aplicativos afetados por essa alteração podem contorná-la definindo explicitamente o System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture desejado como a primeira operação em uma Tarefa assíncrona. Como alternativa, o comportamento antigo (de não atravessar System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) pode ser aceito definindo a seguinte opção de compatibilidade:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Esse problema foi corrigido pelo WPF no .NET Framework 4.6.2. Ele também foi corrigido no .NET Framework 4.6 e 4.6.1 por meio de KB 3139549. Os aplicativos direcionados ao .NET Framework 4.6 ou posterior terão o comportamento correto automaticamente nos aplicativos WPF – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture. Isso seria preservado entre as operações de Dispatcher.

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

APIs afetadas

• CultureInfo.CurrentCulture
• Thread.CurrentCulture
• CultureInfo.CurrentUICulture
• Thread.CurrentUICulture

Nomes de evento ETW não podem ser diferentes apenas por um sufixo "Start" ou "Stop"

Detalhes

No .NET Framework 4.6 e 4.6.1, o runtime gera uma ArgumentException quando dois nomes de evento de Rastreamento de Eventos para Windows (ETW) diferem somente por um sufixo "Start" ou "Stop" (como quando um evento é denominado LogUser e outro, LogUserStart). Nesse caso, o runtime não pode construir a origem do evento, que não pode emitir nenhum log.

Sugestão

Para evitar a exceção, certifique-se de que nomes de dois eventos não difiram somente por um sufixo "Start" ou "Stop". Esse requisito foi removido a partir do .NET Framework 4.6.2. O runtime pode resolver a ambiguidade de nomes de evento que diferem somente pelos sufixos "Start" e "Stop".

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

Entity Framework

A compilação de um edmx do Entity Framework com o Visual Studio 2013 pode falhar com o erro MSB4062 se estiver usando as tarefas EntityDeploySplit ou EntityClean

Detalhes

As ferramentas do MSBuild 12.0 (incluídas no Visual Studio 2013) alteraram os locais do arquivo MSBuild, fazendo com que arquivos de destino do Entity Framework sejam inválidos. O resultado é que as tarefas EntityDeploySplit e EntityClean falham porque não conseguem localizar Microsoft.Data.Entity.Build.Tasks.dll. Observe que essa interrupção se deve a uma alteração no conjunto de ferramentas (MSBuild/VS), e não por uma mudança no .NET Framework. Ela ocorrerá apenas no upgrade das ferramentas do desenvolvedor, não simplesmente no upgrade do .NET Framework.

Sugestão

Os arquivos de destino do Entity Framework foram corrigidos para trabalhar com o novo layout do MSBuild a partir do .NET Framework 4.6. O upgrade para essa versão do Framework corrigirá esse problema. Como alternativa, esta solução alternativa pode ser usada para aplicar patches diretamente aos arquivos de destino.

Nome	Valor
Escopo	Principal
Versão	4.5.1
Tipo	Redirecionando

JIT

IL ret não é permitido em uma região try

Detalhes

Ao contrário do compilador Just-In-Time JIT64, o RyuJIT (usado no .NET Framework 4.6) não permite que uma instrução IL ret em uma região try. Retornar de uma região try não é permitido pela especificação ECMA-335, e nenhum compilador gerenciado conhecido gera tal IL. No entanto, o compilador JIT64 executará essa IL se ela for gerada usando emissão de reflexo.

Sugestão

Se um aplicativo estiver gerando uma IL que inclua um opcode ret em uma região try, o aplicativo poderá ser direcionado ao .NET Framework 4.5 para usar o JIT antigo e evitar essa interrupção. Como alternativa, a IL gerada pode ser atualizado para retornar após a região try.

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

Novo compilador JIT de 64 bits no .NET Framework 4.6

Detalhes

A partir do .NET Framework 4.6, um novo compilador JIT de 64 bits é usado para compilação Just-In-Time. Em alguns casos, será gerada uma exceção inesperada ou um comportamento diferente será observado se um aplicativo for executado usando o compilador de 32 bits ou o compilador JIT de 64 bits antigo. Essa alteração não afeta o compilador JIT de 32 bits. Os diferenças conhecidas incluem o seguinte:

• Sob certas condições, uma operação de conversão unboxing pode gerar uma NullReferenceException em compilações de Versão com a otimização ativada.
• Em alguns casos, a execução do código de produção em um corpo de método grande pode gerar uma StackOverflowException.
• Em certas condições, as estruturas passadas para um método são tratadas como tipos de referência em vez de tipos de valor em de builds de Versão. Um das manifestações desse problema é que os itens individuais em uma coleção aparecem em uma ordem inesperada.
• Sob determinadas condições, a comparação de valores UInt16 com seu conjunto de bits alto será incorreta se a otimização estiver habilitada.
• Sob certas condições, especialmente ao inicializar uma matriz de valores, a inicialização da memória pela instrução IL OpCodes.Initblk pode inicializar a memória com um valor incorreto. Isso pode resultar em uma saída incorreta ou uma exceção sem tratamento.
• Sob certas condições raras, um teste de bits condicional poderá retornar o valor Boolean incorreto ou gerar uma exceção se as otimizações do compilador estiverem habilitadas.
• Sob certas condições, se uma instrução if for usada para testar uma condição antes de entrar em um bloco try e na saída do bloco try, e a mesma condição for avaliada no bloco catch ou finally, o novo compilador JIT de 64 bits removerá a condição if do bloco catch ou finally ao otimizar o código. Como resultado, o código dentro da instrução if no bloco catch ou finally será executado incondicionalmente.

Sugestão

Mitigação dos problemas conhecidos
Se você encontrar os problemas listados acima, solucione-os seguindo um destes procedimentos:

• Atualizar para o .NET Framework 4.6.2. O novo compilador de 64 bits incluído com o .NET Framework 4.6.2 resolve cada um desses problemas conhecidos.

• Verifique se a sua versão do Windows está atualizada executando o Windows Update. Atualizações de serviço para o .NET Framework 4.6 e 4.6.1 resolvem cada um desses problemas, exceto a NullReferenceException em uma operação de conversão unboxing.

• Compilar com o compilador JIT de 64 bits mais antigo. Veja a seção Mitigação de outros problemas para saber mais sobre como fazer isso. Mitigação de outros problemas
  Se você encontrar qualquer outra diferença de comportamento entre o código compilado com o compilador de 64 bits mais antigo e o novo compilador JIT de 64 bits, ou entre as versões de depuração e de versão de seu aplicativo, ambas compiladas com o novo compilador JIT de 64 bits, faça o seguinte para compilar seu aplicativo com o compilador JIT de 64 bits mais antigo:

• Para cada aplicativo, você poderá adicionar o elemento < ao arquivo de configuração de aplicativo. Veja a seguir como desabilitar a compilação com o novo compilador JIT de 64 bits e usar, em vez disso, o compilador JIT de 64 bits herdado.

  <?xml version ="1.0"?>
  <configuration>
    <runtime>
     <useLegacyJit enabled="1" />
    </runtime>
  </configuration>
  

• Adicione a cada usuário um valor REG_DWORD denominado useLegacyJit para a chave HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework do Registro. Um valor 1 habilita o compilador JIT de 64 bits herdado; um valor 0 o desabilita e habilita o novo compilador JIT de 64 bits.

• Adicione a cada máquina um valor REG_DWORD denominado useLegacyJit para a chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework do Registro. Um valor de 1 habilita o compilador JIT de 64 bits herdado; um valor de 0 o desabilita e habilita o novo compilador JIT de 64 bits. Avise-nos sobre o problema relatando um bug no Microsoft Connect.

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

Rede

Validação dos certificados de EKU do OID

Detalhes

A partir do .NET Framework 4.6, as classes SslStream ou ServicePointManager executarão a validação do EKU (uso avançado de chave) do OID (identificador de objeto). Uma extensão de EKU (uso avançado de chave) é uma coleção de OIDs (identificadores de objeto) que indicam os aplicativos que usam a chave. A validação do EKU do OID usa retornos de chamada de certificado remoto para garantir que o certificado remoto tenha o OID correto para a finalidade pretendida.

Sugestão

Se você não quiser essa alteração, desabilite a validação do EKU do OID adicionando a seguinte opção a <AppContextSwitchOverrides> no ` do arquivo de configuração do aplicativo:

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

Importante

Essa configuração é fornecida apenas para compatibilidade com versões anteriores. Caso contrário, seu uso não é recomendado.

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

APIs afetadas

• System.Net.Security.SslStream
• System.Net.ServicePointManager
• System.Net.Http.HttpClient
• System.Net.Mail.SmtpClient
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest

Somente os protocolos Tls 1.0, 1.1 e 1.2 são compatíveis com System.Net.ServicePointManager e System.Net.Security.SslStream

Detalhes

A partir do .NET Framework 4.6, as classes ServicePointManager e SslStream têm permissão para usar somente um dos três protocolos a seguir: Tls1.0, Tls1.1 ou Tls1.2. Não há suporte para o protocolo SSL 3.0 e a criptografia RC4.

Sugestão

A mitigação recomendada é fazer upgrade do aplicativo do lado do servidor para Tls1.0, Tls1.1 ou Tls1.2. Se não for viável ou se os aplicativos cliente estiverem desfeitos, a classe System.AppContext poderá ser usada para recusar esse recurso de duas maneiras:

• Configurar de forma programática as opções de compatibilidade na instância System.AppContext, conforme explicado aqui.
• Adicionando a seguinte linha na seção <runtime> do arquivo app.config:

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

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

APIs afetadas

• SecurityProtocolType.Ssl3
• SslProtocols.None
• SslProtocols.Ssl2
• SslProtocols.Ssl3

TLS 1.x por padrão passa o sinalizador SCH_SEND_AUX_RECORD para a API do SCHANNEL subjacente

Detalhes

Ao usar TLS 1.x, o .NET Framework depende da API de SCHANNEL do Windows subjacente. A partir do .NET Framework 4.6, o sinalizador SCH_SEND_AUX_RECORD é passado por padrão para SCHANNEL. Isso faz com que SCHANNEL divida os dados a serem criptografados em dois registros separados, o primeiro como um byte único e o segundo como n-1 bytes. Em casos raros, isso interrompe a comunicação entre clientes e servidores existentes que supõem que os dados residem em um único registro.

Sugestão

Se essa alteração interromper a comunicação com um servidor existente, você poderá desabilitá-la enviando o sinalizador SCH_SEND_AUX_RECORD, e restaurar o comportamento anterior de não dividir dados em registros separados adicionando a seguinte opção ao elemento <AppContextSwitchOverrides> na seção <runtime> do arquivo de configuração de aplicativo:

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

Importante

Essa configuração é fornecida apenas para compatibilidade com versões anteriores. Caso contrário, seu uso não é recomendado.

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

APIs afetadas

• System.Net.Security.SslStream
• System.Net.ServicePointManager
• System.Net.Http.HttpClient
• System.Net.Mail.SmtpClient
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest

Windows Communication Foundation (WCF)

Chamada para CreateDefaultAuthorizationContext com um argumento nulo foi alterada

Detalhes

A implementação de System.IdentityModel.Policy.AuthorizationContext retornado por uma chamada a System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) com um argumento authorizationPolicies nulo mudou sua implementação no .NET Framework 4.6.

Sugestão

Em casos raros, os aplicativos WCF que usam a autenticação personalizada podem ver diferenças de comportamento. Nesses casos, o comportamento anterior pode ser restaurado de uma destas duas maneiras:

• Recompile o aplicativo para se destinar a uma versão anterior ao .NET Framework 4.6. Para serviços hospedados pelo IIS, use o elemento <httpRuntime targetFramework="x.x"> para direcionar a uma versão anterior do .NET Framework.

• Adicione a seguinte linha à seção <appSettings> de seu arquivo app.config:

  <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
  

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

APIs afetadas

• AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>)

Windows Forms

Icon.ToBitmap converte com êxito ícones com quadros PNG em objetos Bitmap

Detalhes

Começando com os aplicativos direcionados ao .NET Framework 4.6, o método Icon.ToBitmap converte com êxito ícones com quadros PNG em objetos Bitmap.

Nos aplicativos que têm como destino o .NET Framework 4.5.2 e versões anteriores, o método Icon.ToBitmap gera uma exceção ArgumentOutOfRangeException se o objeto Ícone tiver quadros PNG.

Essa alteração afeta os aplicativos que são recompilados para serem direcionados ao .NET Framework 4.6 e que implementam um tratamento especial para a ArgumentOutOfRangeException, que será gerada quando um objeto Ícone tiver quadros PNG. Ao executar no .NET Framework 4.6, a conversão é bem-sucedida, uma ArgumentOutOfRangeException não é mais gerada e, portanto, o manipulador de exceção não é invocado.

Sugestão

Se esse comportamento for indesejável, será possível reter o comportamento anterior adicionando o seguinte elemento à seção <runtime> do arquivo app.config:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

Se o arquivo app.config já contiver o elemento AppContextSwitchOverrides, o novo valor deverá ser mesclado ao atributo de valor, da seguinte forma:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />

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

APIs afetadas

• Icon.ToBitmap()

Windows Presentation Foundation (WPF)

CurrentCulture não é preservada entre operações do Dispatcher do WPF

Detalhes

A partir do .NET Framework 4.6, alterações em System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture feitas em um System.Windows.Threading.Dispatcher serão perdidas ao final dessa operação do dispatcher. Da mesma forma, alterações em System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture feitas fora de uma operação de Dispatcher podem não ser refletidas quando a operação é executada. Em termos práticos, isso significa que alterações em System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture podem não fluir entre retornos de chamada de UI do WPF e outro código em um aplicativo do WPF. Isso ocorre devido a uma alteração em System.Threading.ExecutionContext que faz com que System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture sejam armazenados no contexto de execução começando com aplicativos destinados ao .NET Framework 4.6. As operações de dispatcher do WPF armazenam o contexto de execução usado para começar a operação e restaurar o contexto anterior quando a operação é concluída. Como System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture agora fazem parte desse contexto, alterações nelas em uma operação de dispatcher não são persistidas fora da operação.

Sugestão

Os aplicativos afetados por essa alteração poderão contornar esse problema ao armazenar o System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture desejado em um campo e verificar em todos os corpos da operação de Dispatcher (incluindo manipuladores de retorno de chamada do evento de interface do usuário) se o System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture corretos foram definidos. Como alternativa, como a alteração de ExecutionContext subjacente a essa alteração do WPF afeta apenas aplicativos destinados ao .NET Framework 4.6 ou mais recente, essa interrupção poderá ser evitada destinando-os ao .NET Framework 4.5.2. Aplicativos destinados ao .NET Framework 4.6 ou posterior também podem contornar esse problema definindo a seguinte opção de compatibilidade:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Esse problema foi corrigido pelo WPF no .NET Framework 4.6.2. Ele também foi corrigido no .NET Framework 4.6 e 4.6.1 por meio de KB 3139549. Os aplicativos direcionados ao .NET Framework 4.6 ou posterior terão o comportamento correto automaticamente nos aplicativos WPF – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture. Isso seria preservado entre as operações de Dispatcher.

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

Arredondamento de layout do WPF foi alterado

Detalhes

A maneira como as margens são arredondadas, bem como as bordas e a tela de fundo dentro delas, foi alterada. Como resultado dessa alteração:

• A largura ou altura dos elementos pode aumentar ou reduzir em um pixel no máximo.
• O posicionamento de um objeto pode ser movido até um pixel, no máximo.
• Os elementos centralizados podem estar vertical ou horizontalmente fora do centro em, no máximo, um pixel. Por padrão, esse novo layout é habilitado somente para aplicativos que se destinam ao .NET Framework 4.6.

Sugestão

Uma vez que essa modificação tende a eliminar a distorção da direita ou da parte inferior dos controles do WPF em DPIs altos, os aplicativos que de destinam a versões anteriores do .NET Framework, mas estão sendo executados no .NET Framework 4.6, podem aderir a esse novo comportamento adicionando a seguinte linha à seção <runtime> do arquivo app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

Os aplicativos que são direcionados ao .NET Framework 4.6, mas querem que os controles do WPF sejam renderizados usando o algoritmo de layout anterior podem fazer isso adicionando a seguinte linha à seção <runtime> do arquivo app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />

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

XML, XSLT

XmlWriter é gerado com pares alternativos inválidos

Detalhes

Em aplicativos direcionados ao NET Framework 4.5.2 ou versões anteriores, escrever um par alternativo inválido usando o tratamento de fallback de exceção nem sempre gera uma exceção. Em aplicativos destinados ao .NET Framework 4.6, tentar escrever um par alternativo inválido gera System.ArgumentException.

Sugestão

Se necessário, essa interrupção pode ser evitada destinando ao .NET Framework 4.5.2 ou versões anteriores. Como alternativa, os pares alternativos inválidos podem ser pré-processados em um xml válido antes serem escritos.

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

APIs afetadas

• XmlWriter.WriteAttributeString(String, String)
• XmlWriter.WriteAttributeString(String, String, String)
• XmlWriter.WriteAttributeString(String, String, String, String)
• XmlWriter.WriteAttributeStringAsync(String, String, String, String)
• XmlWriter.WriteCData(String)
• XmlWriter.WriteCDataAsync(String)
• XmlWriter.WriteChars(Char[], Int32, Int32)
• XmlWriter.WriteCharsAsync(Char[], Int32, Int32)
• XmlWriter.WriteComment(String)
• XmlWriter.WriteCommentAsync(String)
• XmlWriter.WriteEntityRef(String)
• XmlWriter.WriteEntityRefAsync(String)
• XmlWriter.WriteRaw(Char[], Int32, Int32)
• XmlWriter.WriteProcessingInstruction(String, String)
• XmlWriter.WriteProcessingInstructionAsync(String, String)
• XmlWriter.WriteRaw(String)
• XmlWriter.WriteRawAsync(Char[], Int32, Int32)
• XmlWriter.WriteRawAsync(String)
• XmlWriter.WriteString(String)
• XmlWriter.WriteStringAsync(String)
• XmlWriter.WriteSurrogateCharEntity(Char, Char)
• XmlWriter.WriteSurrogateCharEntityAsync(Char, Char)
• XmlWriter.WriteValue(String)

A validação do Esquema XSD agora detecta corretamente as violações de restrições exclusivas se chaves compostas forem usadas e uma chave estiver vazia

Detalhes

As versões do .NET Framework anteriores a 4.6 tinham um bug que fazia com que a validação de XSD não detectasse restrições exclusivas em chaves compostas se uma das chaves estivesse vazia. No .NET Framework 4.6, esse problema foi corrigido. Isso resultará na validação mais correta, mas também pode resultar na não validação de algum XML que anteriormente seria validado.

Sugestão

Se for necessária uma validação menos rigorosa do .NET Framework 4.0, o aplicativo de validação poderá ser destinado à versão 4.5 (ou anterior) do .NET Framework. No entanto, ao redirecionar para o .NET Framework 4.6, será necessário fazer uma revisão de código para garantir que não seja esperado que chaves compostas duplicadas (conforme é descrito na descrição desse problema) sejam validadas.

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

.NET Framework 4.6.1

Núcleo

Alteração no caractere separador de caminho na propriedade FullName de objetos ZipArchiveEntry

Detalhes

Em aplicativos destinados ao .NET Framework 4.6.1 e versões posteriores, o caractere separador de caminho foi alterado de barra invertida ("\") para barra ("/") na propriedade FullName dos objetos ZipArchiveEntry criados pelas sobrecargas do método CreateFromDirectory. A alteração traz a implementação do .NET em conformidade com a seção 4.4.17.1 da Especificação de formato de arquivo .ZIP e permite que arquivamentos .ZIP sejam descompactados em sistemas não Windows.
A descompactação de um arquivo zip criado por um aplicativo direcionado a uma versão anterior do .NET Framework em sistemas operacionais não Windows, como o Macintosh, falha na preservação da estrutura de diretório. Por exemplo, no Macintosh, ela cria um conjunto de arquivos cujo nome de arquivo concatena o caminho do diretório com qualquer caractere de barra invertida ("\") e o nome do arquivo. Consequentemente, a estrutura do diretório de arquivos descompactados não é preservada.

Sugestão

O impacto dessa alteração em arquivos .ZIP descompactados no sistema operacional Windows pelas APIs no namespace System.IO do .NET Framework deve ser mínimo, pois essas APIs conseguem lidar perfeitamente com a barra ("/") ou a barra invertida ("\") como caractere separador de caminho.
Se essa alteração não for desejada, você poderá recusá-la adicionando uma definição de configuração à seção <runtime> do arquivo de configuração de aplicativo. O exemplo a seguir mostra a seção <runtime> e a opção de recusa Switch.System.IO.Compression.ZipFile.UseBackslash:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

Além disso, os aplicativos direcionados a versões anteriores do .NET Framework, mas executados no .NET Framework 4.6.1 e nas versões posteriores, podem aceitar esse comportamento adicionando uma definição de configuração à seção <runtime> do arquivo de configuração de aplicativo. Veja a seguir a seção <runtime> e a opção de aceitação Switch.System.IO.Compression.ZipFile.UseBackslash.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.1
Tipo	Redirecionando

APIs afetadas

• ZipFile.CreateFromDirectory(String, String)
• ZipFile.CreateFromDirectory(String, String, CompressionLevel, Boolean)
• ZipFile.CreateFromDirectory(String, String, CompressionLevel, Boolean, Encoding)

Windows Communication Foundation (WCF)

Associação do WCF com o modo de segurança TransportWithMessageCredential

Detalhes

A partir do .NET Framework 4.6.1, a associação do WCF que usa o modo de segurança TransportWithMessageCredential poderá ser configurada para receber mensagens com cabeçalhos "to" não assinados para chaves de segurança assimétricas. Por padrão, os cabeçalhos "to" não assinados continuarão sendo rejeitados no NET Framework 4.6.1. Eles só serão aceitos se o aplicativo aceitar esse novo modo de operação usando a opção de configuração Switch.System.ServiceModel.AllowUnsignedToHeader.

Sugestão

Como esse é um recurso de aceitação, ele não deve afetar o comportamento dos aplicativos existentes.
Para controlar se o novo comportamento está sendo usado ou não, use a seguinte configuração:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>

Nome	Valor
Escopo	Transparente
Versão	4.6.1
Tipo	Redirecionando

APIs afetadas

• BasicHttpSecurityMode.TransportWithMessageCredential
• BasicHttpsSecurityMode.TransportWithMessageCredential
• SecurityMode.TransportWithMessageCredential
• WSFederationHttpSecurityMode.TransportWithMessageCredential

X509CertificateClaimSet.FindClaims considera todos os claimTypes

Detalhes

Em aplicativos destinados ao .NET Framework 4.6.1, se um conjunto de declarações X509 for inicializado de um certificado que tenha várias entradas DNS em seu campo SAN, o método System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) tentará corresponder o argumento claimType a todas as entradas DNS. Em aplicativos destinados a versões anteriores do .NET Framework, o método System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) tenta corresponder o argumento claimType somente com a última entrada DNS.

Sugestão

Essa alteração afeta apenas aplicativos destinados ao .NET Framework 4.6.1. Essa alteração pode ser desabilitada (ou habilitada se destinada a versões anteriores a 4.6.1) com a opção de compatibilidade DisableMultipleDNSEntries.

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

APIs afetadas

• X509CertificateClaimSet.FindClaims(String, String)

Windows Forms

Application.FilterMessage não é mais gerada para implementações de reentrância de IMessageFilter.PreFilterMessage

Detalhes

Antes do .NET Framework 4.6.1, a chamada a uma FilterMessage(Message) com uma PreFilterMessage(Message) que chamava System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) ou System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (ao chamar DoEvents() também) causava uma System.IndexOutOfRangeException.

A partir dos aplicativos direcionados ao .NET Framework 4.6.1, essa exceção não é mais gerada e os filtros reentrantes, conforme descrito acima, podem ser utilizados.

Sugestão

Lembre-se de que FilterMessage(Message) não será mais gerado para o comportamento PreFilterMessage(Message) reentrante descrito acima. Isso afeta somente os aplicativos destinados ao .NET Framework 4.6.1. Os aplicativos destinados ao .NET Framework 4.6.1 podem recusar essa alteração (ou os aplicativos de Frameworks mais antigos podem aceitar) usando a opção de compatibilidade DontSupportReentrantFilterMessage.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.1
Tipo	Redirecionando

APIs afetadas

• Application.FilterMessage(Message)

Windows Presentation Foundation (WPF)

Chamadas para System.Windows.Input.PenContext.Disable em sistemas habilitados para toque podem gerar ArgumentException

Detalhes

Em algumas circunstâncias, chamadas para o método interno System.Windows.Intput.PenContext.Disable em sistemas habilitados para toque podem gerar uma T:System.ArgumentException sem tratamento devido à reentrância.

Sugestão

Esse problema foi resolvido no .NET Framework 4.7. Para evitar a exceção, atualize para uma versão do .NET Framework a partir de 4.7.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.1
Tipo	Redirecionando

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath gera NullReferenceException

Detalhes

No .NET Framework 4.6.2, o runtime gera T:System.NullReferenceException ao recuperar um valor P:System.Web.HttpRuntime.AppDomainAppPath que inclui caracteres nulos. No .NET Framework 4.6.1 e versões anteriores, o runtime gera T:System.ArgumentNullException.

Sugestão

Você pode fazer o seguinte para responder a essa alteração:

• Identifique o T:System.NullReferenceException se o aplicativo estiver sendo executado no .NET Framework 4.6.2.
• Atualize para o .NET Framework 4.7, que restaura o comportamento anterior e gera T:System.ArgumentNullException.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Redirecionando

APIs afetadas

• HttpRuntime.AppDomainAppPath

Núcleo

Descriptografador AesCryptoServiceProvider fornece uma transformação reutilizável

Detalhes

Começando com aplicativos destinados ao .NET Framework 4.6.2, o descriptografador AesCryptoServiceProvider fornece uma transformação reutilizável. Após uma chamada para System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32), a transformação é reinicializada e pode ser reutilizada. Para aplicativos destinados a versões anteriores do .NET Framework, tentar reutilizar o descriptografador chamando System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) após uma chamada para System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) gera um CryptographicException ou produz dados corrompidos.

Sugestão

O impacto dessa alteração deve ser mínimo, uma vez que se trata do comportamento esperado. Aplicativos que dependem do comportamento anterior podem optar por não usá-lo adicionando a seguinte definição de configuração à seção <runtime> do arquivo de configuração do aplicativo:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

Além disso, aplicativos destinados a uma versão anterior do .NET Framework, mas em execução em uma versão do .NET Framework a partir do .NET Framework 4.6.2 podem aceitá-lo adicionando a seguinte definição de configuração à seção <runtime> do arquivo de configuração do aplicativo:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>

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

APIs afetadas

• AesCryptoServiceProvider.CreateDecryptor()

Chamadas para construtores ClaimsIdentity

Detalhes

A partir do .NET Framework 4.6.2, haverá uma alteração na maneira como os construtores ClaimsIdentity com um parâmetro System.Security.Principal.IIdentity configuram a propriedade System.Security.Claims.ClaimsIdentity.Actor. Se o argumento System.Security.Principal.IIdentity for um objeto ClaimsIdentity e a propriedade System.Security.Claims.ClaimsIdentity.Actor desse objeto ClaimsIdentity não for null, a propriedade System.Security.Claims.ClaimsIdentity.Actor será anexada usando o método Clone(). No Framework 4.6.1 e versões anteriores, a propriedade System.Security.Claims.ClaimsIdentity.Actor é anexada como uma referência existente. Por causa desta alteração, a partir do .NET Framework 4.6.2, a propriedade System.Security.Claims.ClaimsIdentity.Actor do novo objeto ClaimsIdentity não será igual à propriedade System.Security.Claims.ClaimsIdentity.Actor do argumento System.Security.Principal.IIdentity do construtor. No .NET Framework 4.6.1 e nas versões anteriores, ele é igual.

Sugestão

Se esse comportamento for indesejável, restaure o comportamento anterior definindo a opção Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity no arquivo de configuração do aplicativo como true. Isso exige que você adicione o seguinte à seção <runtime> do arquivo web.config:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Redirecionando

APIs afetadas

• ClaimsIdentity(IIdentity)
• ClaimsIdentity(IIdentity, IEnumerable<Claim>)
• ClaimsIdentity(IIdentity, IEnumerable<Claim>, String, String, String)

Alterações na normalização de caminho

Detalhes

A partir de aplicativos destinados ao .NET Framework 4.6.2, a maneira como o runtime normaliza caminhos foi alterada. Normalizar um caminho envolve modificar a cadeia de caracteres que identifica um arquivo ou caminho para que ela corresponda a um caminho válido no sistema operacional de destino. Normalmente, a normalização envolve:

• Padronização de separadores de diretório e componente.
• Aplicação do diretório atual a um caminho relativo.
• Avaliação do diretório relativo (.) ou do diretório pai (..) em um caminho.
• Remoção de determinados caracteres. A partir dos aplicativos destinados ao .NET Framework 4.6.2, as seguintes alterações na normalização do caminho são habilitadas por padrão:
  • O runtime atende à função GetFullPathName do sistema operacional para normalizar caminhos.
• A normalização não envolve mais a remoção do fim dos segmentos do diretório (como um espaço no fim do nome de um diretório).
• Suporte à sintaxe do caminho do dispositivo em confiança total, incluindo \\.\ e, para APIs de E/S de arquivo em mscorlib.dll, \\?\.
• O runtime não valida caminhos de sintaxe do dispositivo.
• Há suporte ao uso da sintaxe de dispositivo para acessar fluxos de dados alternados. Essas alterações devem melhorar o desempenho e ao mesmo tempo permitir que os métodos acessem caminhos anteriormente inacessíveis. Os aplicativos direcionados ao .NET Framework 4.6.1 e versões anteriores, mas que são executados no .NET Framework 4.6.2 ou posteriores, não são afetados por essa alteração.

Sugestão

Aplicativos destinados ao .NET Framework 4.6.2 ou posteriores podem recusar essa alteração e usar a normalização herdada adicionando o seguinte à seção <runtime> do arquivo de configuração de aplicativo:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

Aplicativos destinados ao .NET Framework 4.6.1 ou anteriores, mas que são executados no .NET Framework 4.6.2 ou posteriores podem habilitar as alterações na normalização de caminho adicionando a seguinte linha à seção <runtime> do arquivo de configuração de aplicativo:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>

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

Fluxo CurrentCulture e CurrentUICulture atravessam tarefas

Detalhes

A partir do .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture são armazenados no System.Threading.ExecutionContext do thread, que atravessa operações assíncronas. Isso significa que as alterações em System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture serão refletidas em tarefas que posteriormente serão executadas de forma assíncrona. Isso é diferente do comportamento das versões anteriores do .NET Framework (que redefiniria System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture em todas as tarefas assíncronas).

Sugestão

Aplicativos afetados por essa alteração podem contorná-la definindo explicitamente o System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture desejado como a primeira operação em uma Tarefa assíncrona. Como alternativa, o comportamento antigo (de não atravessar System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) pode ser aceito definindo a seguinte opção de compatibilidade:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Esse problema foi corrigido pelo WPF no .NET Framework 4.6.2. Ele também foi corrigido no .NET Framework 4.6 e 4.6.1 por meio de KB 3139549. Os aplicativos direcionados ao .NET Framework 4.6 ou posterior terão o comportamento correto automaticamente nos aplicativos WPF – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture. Isso seria preservado entre as operações de Dispatcher.

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

APIs afetadas

• CultureInfo.CurrentCulture
• Thread.CurrentCulture
• CultureInfo.CurrentUICulture
• Thread.CurrentUICulture

Nomes de evento ETW não podem ser diferentes apenas por um sufixo "Start" ou "Stop"

Detalhes

No .NET Framework 4.6 e 4.6.1, o runtime gera uma ArgumentException quando dois nomes de evento de Rastreamento de Eventos para Windows (ETW) diferem somente por um sufixo "Start" ou "Stop" (como quando um evento é denominado LogUser e outro, LogUserStart). Nesse caso, o runtime não pode construir a origem do evento, que não pode emitir nenhum log.

Sugestão

Para evitar a exceção, certifique-se de que nomes de dois eventos não difiram somente por um sufixo "Start" ou "Stop". Esse requisito foi removido a partir do .NET Framework 4.6.2. O runtime pode resolver a ambiguidade de nomes de evento que diferem somente pelos sufixos "Start" e "Stop".

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

Suporte a caminho longo

Detalhes

A partir dos aplicativos destinados ao .NET Framework 4.6.2, caminhos longos (de até 32K caracteres) têm suporte e a limitação de 260 caracteres (ou MAX_PATH) para o tamanho dos caminhos foi removida. Para aplicativos recompilados para serem destinados ao .NET Framework 4.6.2, os caminhos de código que lançavam um System.IO.PathTooLongException porque um caminho ultrapassava 260 caracteres agora lançam um System.IO.PathTooLongException apenas sob as seguintes condições:

• O tamanho do caminho é superior a MaxValue (32.767) caracteres.
• O sistema operacional retorna COR_E_PATHTOOLONG ou seu equivalente. Para aplicativos destinados ao .NET Framework 4.6.1 e versões anteriores, a runtime gera automaticamente um System.IO.PathTooLongException sempre que um caminho ultrapassa 260 caracteres.

Sugestão

Para aplicativos destinados ao .NET Framework 4.6.2, é possível recusar o suporte para caminhos longos se ele não for desejável adicionando o seguinte à seção <runtime> do arquivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

Para aplicativos destinados a versões anteriores do .NET Framework mas executados no .NET Framework 4.6.2 ou posterior, é possível aceitar o suporte para caminhos longos adicionando o seguinte à seção <runtime> do arquivo app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>

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

Verificações de dois-pontos em caminhos estão mais rigorosas

Detalhes

No .NET Framework 4.6.2, uma série de alterações foram feitas para dar suporte aos caminhos incompatíveis anteriormente (em termos de comprimento e formato). As verificações de sintaxe correta (dois-pontos) do separador de unidades foram aperfeiçoadas, o que teve como efeito colateral o bloqueio de alguns caminhos de URI em algumas APIs de Caminho selecionadas em que eles costumavam ser aceitos.

Sugestão

Ao passar um URI para as APIs afetadas, modifique a cadeia de caracteres para um caminho correto antes.

• Remova o esquema das URLs manualmente (por exemplo, remova file:// das URLs).

• Transmita o URI para a classe Uri e use LocalPath.

Como alternativa, é possível recusar a normalização do novo caminho definindo a opção AppContext Switch.System.IO.UseLegacyPathHandling como true.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Redirecionando

APIs afetadas

• Path.GetDirectoryName(String)
• Path.GetPathRoot(String)

Segurança

Agora, RSACng carrega corretamente as chaves RSA de tamanho não padrão

Detalhes

Nas versões do .NET Framework anteriores a 4.6.2, os clientes com tamanhos de chave não padrão para certificados RSA não conseguiam acessá-las por meio dos métodos de extensão System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) e System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2). Uma System.Security.Cryptography.CryptographicException com a mensagem “O tamanho de chave solicitado não é compatível” é gerada. Esse problema foi corrigido no .NET Framework 4.6.2. Da mesma forma, ImportParameters(RSAParameters) e ImportParameters(RSAParameters) agora funcionam com tamanhos de chave não padrão sem gerar um System.Security.Cryptography.CryptographicException.

Sugestão

Se houver qualquer lógica de tratamento de exceções dependente do comportamento anterior, em que um System.Security.Cryptography.CryptographicException é gerado quando tamanhos de chave não padrão são usados, considere remover essa lógica.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Redirecionando

APIs afetadas

• RSA.ImportParameters(RSAParameters)
• RSACng.ImportParameters(RSAParameters)
• RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2)
• RSACertificateExtensions.GetRSAPublicKey(X509Certificate2)

SignedXml.GetPublicKey retorna RSACng em net462 (ou lightup) sem redirecionar a alteração

Detalhes

A partir do .NET Framework 4.6.2, o tipo concreto de objeto retornado pelo método SignedXml.GetPublicKey foi alterado (sem um quirk) de uma implementação de CryptoServiceProvider para uma implementação de Cng. Isso ocorreu porque a implementação foi alterada: do uso de certificate.PublicKey.Key para o uso do certificate.GetAnyPublicKey interno, que encaminha para RSACertificateExtensions.GetRSAPublicKey.

Sugestão

Começando com aplicativos em execução no .NET Framework 4.7.1, é possível usar a implementação de CryptoServiceProvider usada por padrão no .NET Framework 4.6.1 e versões anteriores adicionando a seguinte opção de configuração à seção runtime do arquivo de configuração do aplicativo:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Redirecionando

APIs afetadas

• SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm)

Windows Communication Foundation (WCF)

Uso de serviços Reentrantes pode resultar em deadlock

Detalhes

Um deadlock pode resultar em um serviço Reentrante, o que restringe as instâncias do serviço para um thread de execução de cada vez. Os serviços que podem apresentar esse problema terão o ServiceBehaviorAttribute a seguir no código:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Sugestão

Para solucionar esse problema, você pode fazer o seguinte:

• Defina o modo de simultaneidade do serviço como ConcurrencyMode.Single ou ConcurrencyMode.Multiple. Por exemplo:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

• Instalar a atualização mais recente do .NET Framework 4.6.2 ou atualizar para uma versão posterior do .NET Framework. Isso desabilita o fluxo do ExecutionContext em OperationContext.Current. Esse comportamento é configurável; é equivalente a adicionar a seguinte configuração de aplicativo ao arquivo de configuração:

<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

O valor de Switch.System.ServiceModel.DisableOperationContextAsyncFlow nunca deve ser definido como false para serviços Reentrant.

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

APIs afetadas

• System.ServiceModel.ServiceBehaviorAttribute
• ConcurrencyMode.Reentrant

OperationContext.Current pode retornar nulo quando chamado usando cláusula

Detalhes

OperationContext.Current poderá retornar null e um NullReferenceException poderá ocorrer quando todas as seguintes condições forem verdadeiras:

• Você recupera o valor da propriedade OperationContext.Current em um método que retorna um Task ou Task<TResult>.
• Você cria uma instância do objeto OperationContextScope em uma cláusula using.
• Você recupera o valor da propriedade OperationContext.Current dentro de using statement. Por exemplo:

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

Sugestão

Para solucionar esse problema, você pode fazer o seguinte:

• Modifique o código da seguinte maneira para criar uma instância de um novo objeto não nullCurrent:

  OperationContext ocx = OperationContext.Current;
  using (new OperationContextScope(OperationContext.Current))
  {
      OperationContext.Current = new OperationContext(ocx.Channel);
  
      // ...
  }
  

• Instalar a atualização mais recente do .NET Framework 4.6.2 ou atualizar para uma versão posterior do .NET Framework. Isso desabilita o fluxo do ExecutionContext em OperationContext.Current e restaura o comportamento de aplicativos do WCF no .NET Framework 4.6.1 e em versões anteriores. Esse comportamento é configurável; é equivalente a adicionar a seguinte configuração de aplicativo ao arquivo de configuração:

  <appSettings>
    <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
  </appSettings>
  

  Se essa alteração for indesejável e seu aplicativo depender do fluxo do contexto de execução entre contextos de operação, você poderá habilitar o fluxo da seguinte maneira:

  <appSettings>
    <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
  </appSettings>
  

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Redirecionando

APIs afetadas

• OperationContext.Current

Segurança de transporte do WCF é compatível com certificados armazenados usando CNG

Detalhes

Começando com os aplicativos destinados ao .NET Framework 4.6.2, a segurança de transporte do WCF é compatível com certificados armazenados usando a CNG (Biblioteca de Criptografia do Windows). Esse suporte é limitado a certificados com uma chave pública que tenha um expoente não superior a 32 bits de comprimento. Quando o aplicativo é destinado ao .NET Framework 4.6.2, esse recurso é ativado por padrão. Em versões anteriores do .NET Framework, a tentativa de usar os certificados X509 com um provedor de armazenamento de chaves CSG gera uma exceção.

Sugestão

Os aplicativos destinados ao .NET Framework 4.6.1 e versões anteriores, mas que são executados no .NET Framework 4.6.2, podem habilitar a compatibilidade com os certificados CNG adicionando a seguinte linha à seção <runtime> do arquivo app.config ou web.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

Isso também pode ser feito de modo programático com o seguinte código:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Observe que, por causa dessa alteração, qualquer código de tratamento de exceção que dependa da tentativa de iniciar a comunicação segura com um certificado CNG para falhar não será mais executado.

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

Windows Forms

Implementação incorreta de MemberDescriptor.Equals

Detalhes

A implementação original do método MemberDescriptor.Equals compara duas propriedades de cadeia de caracteres diferentes dos objetos que estão sendo comparados: o nome da categoria e a cadeia de caracteres de descrição. A correção é para comparar o Category do primeiro objeto com o Category de um segundo objeto, e o Description do primeiro com o Description do segunda.

Sugestão

Se seu aplicativo depende do MemberDescriptor.Equals e, às vezes, retorna false quando os descritores são equivalentes, e você está direcionado ao .NET Framework 4.6.2 ou posterior, há várias opções:

• Fazer alterações no código para comparar os campos Category e Description manualmente além de chamar o método MemberDescriptor.Equals.
• Recuse essa alteração adicionando o seguinte valor ao arquivo app.config:

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

Se seu aplicativo for direcionado ao NET Framework 4.6.1 ou anterior e executado no .NET Framework 4.6.2 ou posterior e você quiser que essa alteração seja habilitada, defina a opção de compatibilidade como false adicionando o seguinte valor ao arquivo app.config:

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

Nome	Valor
Escopo	Microsoft Edge
Versão	4.6.2
Tipo	Redirecionando

APIs afetadas

• MemberDescriptor.Equals(Object)

Windows Presentation Foundation (WPF)

CurrentCulture não é preservada entre operações do Dispatcher do WPF

Detalhes

A partir do .NET Framework 4.6, alterações em System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture feitas em um System.Windows.Threading.Dispatcher serão perdidas ao final dessa operação do dispatcher. Da mesma forma, alterações em System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture feitas fora de uma operação de Dispatcher podem não ser refletidas quando a operação é executada. Em termos práticos, isso significa que alterações em System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture podem não fluir entre retornos de chamada de UI do WPF e outro código em um aplicativo do WPF. Isso ocorre devido a uma alteração em System.Threading.ExecutionContext que faz com que System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture sejam armazenados no contexto de execução começando com aplicativos destinados ao .NET Framework 4.6. As operações de dispatcher do WPF armazenam o contexto de execução usado para começar a operação e restaurar o contexto anterior quando a operação é concluída. Como System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture agora fazem parte desse contexto, alterações nelas em uma operação de dispatcher não são persistidas fora da operação.

Sugestão

Os aplicativos afetados por essa alteração poderão contornar esse problema ao armazenar o System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture desejado em um campo e verificar em todos os corpos da operação de Dispatcher (incluindo manipuladores de retorno de chamada do evento de interface do usuário) se o System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture corretos foram definidos. Como alternativa, como a alteração de ExecutionContext subjacente a essa alteração do WPF afeta apenas aplicativos destinados ao .NET Framework 4.6 ou mais recente, essa interrupção poderá ser evitada destinando-os ao .NET Framework 4.5.2. Aplicativos destinados ao .NET Framework 4.6 ou posterior também podem contornar esse problema definindo a seguinte opção de compatibilidade:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Esse problema foi corrigido pelo WPF no .NET Framework 4.6.2. Ele também foi corrigido no .NET Framework 4.6 e 4.6.1 por meio de KB 3139549. Os aplicativos direcionados ao .NET Framework 4.6 ou posterior terão o comportamento correto automaticamente nos aplicativos WPF – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture. Isso seria preservado entre as operações de Dispatcher.

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