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

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

.NET framework 4.6

ASP.NET

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

Detalhes

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

Sugestão

Se um aplicativo dependia da tag extra <BR /> , RenderBeginTag(String) deveria ser chamado uma segunda vez. Observe que essa alteração de comportamento afeta apenas os aplicativos destinados ao .NET Framework 4.6 ou posterior, portanto, outra opção é direcionar uma versão anterior do .NET Framework para obter o comportamento antigo.

Nome	Valor
Âmbito	Edge
Versão	4.6
Type	Redirecionamento

APIs afetadas

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

ClickOnce

Aplicativos publicados com ClickOnce que usam um certificado de assinatura de código SHA-256 podem falhar no Windows 2003

Detalhes

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

• Todos os aplicativos criados com o Visual Studio 2012 ou posterior.
• Aplicativos criados com o Visual Studio 2010 ou anterior em sistemas com o .NET Framework 4.5 presente. Além disso, se o .NET Framework 4.5 ou posterior estiver presente, o manifesto ClickOnce também é assinado com SHA-256 para certificados SHA-256, independentemente da versão do .NET Framework em relação à qual ele foi compilado.

Sugestão

A alteração na assinatura do executável ClickOnce afeta apenas os sistemas Windows Server 2003; eles exigem que o KB 938397 seja instalado. A alteração na assinatura do manifesto com SHA-256 mesmo quando um aplicativo tem como alvo o .NET Framework 4.0 ou versões anteriores introduz uma dependência de tempo de execução no .NET Framework 4.5 ou uma versão posterior.

Nome	Valor
Âmbito	Edge
Versão	4,5
Type	Redirecionamento

ClickOnce suporta SHA-256 em aplicativos direcionados para 4.0

Detalhes

Anteriormente, um aplicativo ClickOnce com um certificado assinado com SHA-256 exigia que o .NET Framework 4.5 ou posterior estivesse presente, mesmo que o aplicativo tivesse como destino o 4.0. Agora, os aplicativos ClickOnce direcionados ao .NET Framework 4.0 podem ser executados no .NET Framework 4.0, mesmo se assinados com SHA-256.

Sugestão

Essa alteração remove 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
Âmbito	Menor
Versão	4.6
Type	Redirecionamento

Principal

CurrentCulture e CurrentUICulture fluem entre tarefas

Detalhes

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

Sugestão

Os aplicativos afetados por essa alteração podem contorná-la definindo explicitamente a operação desejada System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture como a primeira operação em uma Tarefa assíncrona. Como alternativa, o comportamento antigo (de não fluir 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 Frameworks 4.6, 4.6.1 através de KB 3139549. Os aplicativos destinados ao .NET Framework 4.6 ou posterior obterão automaticamente o comportamento correto em aplicativos WPF - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) seriam preservados nas operações do Dispatcher.

Nome	Valor
Âmbito	Menor
Versão	4.6
Type	Redirecionamento

APIs afetadas

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

Os nomes de eventos ETW não podem diferir apenas por um sufixo "Start" ou "Stop"

Detalhes

No .NET Framework 4.6 e 4.6.1, o tempo de execução lança um ArgumentException quando dois nomes de eventos de Rastreamento de Eventos para Windows (ETW) diferem apenas por um sufixo "Start" ou "Stop" (como quando um evento é nomeado LogUser e outro é nomeado LogUserStart). Nesse caso, o tempo de execução não pode construir a fonte do evento, que não pode emitir nenhum log.

Sugestão

Para evitar a exceção, certifique-se de que não há dois nomes de evento diferentes apenas por um sufixo "Start" ou "Stop". Este requisito é removido a partir do .NET Framework 4.6.2; o tempo de execução pode desambiguar nomes de eventos que diferem apenas pelo sufixo "Start" e "Stop".

Nome	Valor
Âmbito	Edge
Versão	4.6
Type	Redirecionamento

Entity Framework

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

Detalhes

As ferramentas do MSBuild 12.0 (incluídas no Visual Studio 2013) alteraram os locais dos arquivos do MSBuild, fazendo com que os arquivos de destino mais antigos do Entity Framework fossem inválidos. O resultado é que EntityDeploySplit e EntityClean as tarefas falham porque não conseguem encontrar Microsoft.Data.Entity.Build.Tasks.dll. Observe que essa quebra é devido a uma alteração de conjunto de ferramentas (MSBuild/VS), não devido a uma alteração do .NET Framework. Isso só ocorrerá ao atualizar ferramentas de desenvolvedor, não quando simplesmente atualizar o .NET Framework.

Sugestão

Os arquivos de destino do Entity Framework são corrigidos para funcionar com o novo layout do MSBuild a partir do .NET Framework 4.6. A atualização para essa versão do Framework corrigirá esse problema. Como alternativa, essa solução alternativa pode ser usada para corrigir os arquivos de destino diretamente.

Nome	Valor
Âmbito	Principal
Versão	4.5.1
Type	Redirecionamento

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 uma instrução ret IL em uma região try. O retorno 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á tal IL se ele for gerado usando a emissão de reflexão.

Sugestão

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

Nome	Valor
Âmbito	Edge
Versão	4.6
Type	Redirecionamento

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, uma exceção inesperada é lançada ou um comportamento diferente é observado do que se um aplicativo for executado usando o compilador de 32 bits ou o compilador JIT de 64 bits mais antigo. Essa alteração não afeta o compilador JIT de 32 bits. As diferenças conhecidas incluem o seguinte:

• Sob certas condições, uma operação de unboxing pode lançar compilações NullReferenceException 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 lançar um StackOverflowExceptionarquivo .
• Sob certas condições, as estruturas passadas para um método são tratadas como tipos de referência em vez de como tipos de valor em compilações de versão. Uma das manifestações dessa questão é que os itens individuais de uma coleção aparecem em uma ordem inesperada.
• Sob certas condições, a comparação de valores com seu conjunto de UInt16 bits altos é incorreta se a otimização estiver ativada.
• Sob certas condições, particularmente ao inicializar valores de matriz, a inicialização da memória pela instrução IL pode inicializar a OpCodes.Initblk memória com um valor incorreto. Isso pode resultar em uma exceção não tratada ou saída incorreta.
• Sob certas condições raras, um teste de bit condicional pode retornar o valor incorreto Boolean ou lançar uma exceção se as otimizações do compilador estiverem habilitadas.
• Sob certas condições, se uma if instrução é usada para testar uma condição antes de entrar em um try bloco e na saída do try bloco, e a mesma condição é avaliada no catch bloco oufinally, o novo compilador JIT de 64 bits remove a condição do catch bloco ou finally quando otimiza o if código. Como resultado, o código dentro da if instrução no catch bloco ou finally é executado incondicionalmente.

Sugestão

Atenuação de problemas conhecidos
Se você encontrar os problemas listados acima, poderá resolvê-los seguindo um destes procedimentos:

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

• Certifique-se de que a sua versão do Windows está atualizada executando o Windows Update. As atualizações de serviço para o .NET Framework 4.6 e 4.6.1 abordam cada um desses problemas, exceto o NullReferenceException em uma operação de unboxing.

• Compile com o compilador JIT de 64 bits mais antigo. Consulte a seção Mitigação de outros problemas para obter mais informações sobre como fazer isso. Atenuação de outros problemas
  Se você encontrar qualquer outra diferença no comportamento entre o código compilado com o compilador JIT de 64 bits mais antigo e o novo compilador JIT de 64 bits, ou entre as versões de depuração e lançamento do seu aplicativo que são compiladas com o novo compilador JIT de 64 bits, você pode fazer o seguinte para compilar seu aplicativo com o compilador JIT de 64 bits mais antigo:

• Por aplicativo, você pode adicionar o < elemento ao arquivo de configuração do aplicativo. O seguinte desativa a compilação com o novo compilador JIT de 64 bits e, em vez disso, usa o compilador JIT herdado de 64 bits.

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

• Por usuário, você pode adicionar um REG_DWORD valor nomeado useLegacyJit à HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework chave do Registro. Um valor de 1 habilita o compilador JIT herdado de 64 bits; um valor de 0 o desativa e habilita o novo compilador JIT de 64 bits.

• Por máquina, você pode adicionar um REG_DWORD valor nomeado useLegacyJit à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework chave do Registro. Um valor de 1 habilita o compilador JIT de 64 bits herdado, um valor de desabilita-o e habilita o novo compilador JIT de 0 64 bits. Você também pode nos informar sobre o problema relatando um bug no Microsoft Connect.

Nome	Valor
Âmbito	Edge
Versão	4.6
Type	Redirecionamento

Rede

Validação do certificado EKU OID

Detalhes

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

Sugestão

Se essa alteração for indesejável, você poderá desabilitar a validação EKU OID do certificado adicionando a seguinte opção ao <AppContextSwitchOverrides> no ` arquivo de configuração do seu 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, a sua utilização não é recomendada.

Nome	Valor
Âmbito	Menor
Versão	4.6
Type	Redirecionamento

APIs afetadas

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

Apenas os protocolos Tls 1.0, 1.1 e 1.2 suportados em System.Net.ServicePointManager e System.Net.Security.SslStream

Detalhes

A partir do .NET Framework 4.6, as ServicePointManager classes e SslStream só podem usar um dos três protocolos a seguir: Tls1.0, Tls1.1 ou Tls1.2. O protocolo SSL3.0 e a cifra RC4 não são suportados.

Sugestão

A mitigação recomendada é atualizar o aplicativo do lado do servidor para Tls1.0, Tls1.1 ou Tls1.2. Se isso não for viável ou se os aplicativos cliente forem quebrados, a System.AppContext classe pode ser usada para desativar esse recurso de duas maneiras:

• Ao configurar programaticamente compatíveis, os interruptores do , conforme explicado System.AppContextaqui.
• Adicionando a seguinte linha à <runtime> seção do arquivo app.config:

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

Nome	Valor
Âmbito	Menor
Versão	4.6
Type	Redirecionamento

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 SCHANNEL subjacente

Detalhes

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

Sugestão

Se essa alteração interromper a comunicação com um servidor existente, você poderá desabilitar o envio do sinalizador SCH_SEND_AUX_RECORD e restaurar o comportamento anterior de não dividir dados em registros separados adicionando a seguinte opção ao <AppContextSwitchOverrides> elemento na <runtime> seção do arquivo de configuração do 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, a sua utilização não é recomendada.

Nome	Valor
Âmbito	Edge
Versão	4.6
Type	Redirecionamento

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)

Chamar CreateDefaultAuthorizationContext com um argumento nulo foi alterado

Detalhes

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

Sugestão

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

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

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

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

Nome	Valor
Âmbito	Menor
Versão	4.6
Type	Redirecionamento

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 destinados ao .NET Framework 4.6, o Icon.ToBitmap método converte com êxito ícones com quadros PNG em objetos Bitmap.

Em aplicativos destinados ao .NET Framework 4.5.2 e versões anteriores, o Icon.ToBitmap método lança uma ArgumentOutOfRangeException exceção se o objeto Icon tiver quadros PNG.

Essa alteração afeta os aplicativos que são recompilados para direcionar o .NET Framework 4.6 e que implementam manipulação especial para o ArgumentOutOfRangeException que é lançado quando um objeto Icon tem quadros PNG. Quando executado sob o .NET Framework 4.6, a conversão é bem-sucedida, um ArgumentOutOfRangeException não é mais lançado e, portanto, o manipulador de exceção não é mais invocado.

Sugestão

Se esse comportamento for indesejável, você pode manter o comportamento anterior adicionando o seguinte elemento à <runtime> seção do seu arquivo app.config:

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

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

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

Nome	Valor
Âmbito	Menor
Versão	4.6
Type	Redirecionamento

APIs afetadas

• Icon.ToBitmap()

Windows Presentation Foundation (WPF)

CurrentCulture não é preservado nas operações do WPF Dispatcher

Detalhes

A partir do .NET Framework 4.6, as alterações feitas System.Globalization.CultureInfo.CurrentUICulture ou System.Globalization.CultureInfo.CurrentCulture feitas em um System.Windows.Threading.Dispatcher serão perdidas no final dessa operação do dispatcher. Da mesma forma, as alterações feitas System.Globalization.CultureInfo.CurrentUICulture ou System.Globalization.CultureInfo.CurrentCulture feitas fora de uma operação do Dispatcher podem não ser refletidas quando essa operação é executada. Em termos práticos, isso significa que System.Globalization.CultureInfo.CurrentCulture as alterações podem System.Globalization.CultureInfo.CurrentUICulture não fluir entre retornos de chamada da interface do usuário do WPF e outros códigos em um aplicativo WPF. Isso ocorre devido a uma alteração nas System.Threading.ExecutionContext causas System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture a ser armazenada no contexto de execução, começando com aplicativos destinados ao .NET Framework 4.6. As operações do dispatcher do WPF armazenam o contexto de execução usado para iniciar a operação e restaurar o contexto anterior quando a operação for concluída. Como System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture agora fazem parte desse contexto, as alterações neles dentro de uma operação de dispatcher não são persistentes fora da operação.

Sugestão

Os aplicativos afetados por essa alteração podem contornar isso armazenando o desejado System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture em um campo e verificando em todos os corpos de operação do Dispatcher (incluindo manipuladores de retorno de chamada de eventos da interface do usuário) que estão corretos System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture definidos. Como alternativa, como a alteração ExecutionContext subjacente a essa alteração do WPF afeta apenas os aplicativos destinados ao .NET Framework 4.6 ou mais recente, essa interrupção pode ser evitada direcionando o .NET Framework 4.5.2.Apps que visam o .NET Framework 4.6 ou posterior também podem contornar isso 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 Frameworks 4.6, 4.6.1 através de KB 3139549. Os aplicativos destinados ao .NET Framework 4.6 ou posterior obterão automaticamente o comportamento correto em aplicativos WPF - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) seriam preservados nas operações do Dispatcher.

Nome	Valor
Âmbito	Menor
Versão	4.6
Type	Redirecionamento

O arredondamento de margens do layout do WPF foi alterado

Detalhes

A forma como as margens são arredondadas e as bordas e o fundo dentro delas mudou. Como resultado desta alteração:

• A largura ou altura dos elementos pode crescer ou diminuir em no máximo um pixel.
• O posicionamento de um objeto pode se mover por no máximo um pixel.
• Os elementos centralizados podem estar vertical ou horizontalmente fora do centro por, no máximo, um pixel. Por padrão, esse novo layout é habilitado apenas para aplicativos destinados ao .NET Framework 4.6.

Sugestão

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

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

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

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

Nome	Valor
Âmbito	Menor
Versão	4.6
Type	Redirecionamento

XML, XSLT

XmlWriter lança em pares substitutos inválidos

Detalhes

Para aplicativos destinados ao .NET Framework 4.5.2 ou versões anteriores, escrever um par substituto inválido usando a manipulação de fallback de exceção nem sempre gera uma exceção. Para aplicativos destinados ao .NET Framework 4.6, a tentativa de escrever um par substituto inválido gera um System.ArgumentExceptionarquivo .

Sugestão

Se necessário, essa interrupção pode ser evitada visando o .NET Framework 4.5.2 ou anterior. Como alternativa, pares substitutos inválidos podem ser pré-processados em xml válido antes de escrevê-los.

Nome	Valor
Âmbito	Edge
Versão	4.6
Type	Redirecionamento

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 deteta corretamente violações de restrições exclusivas se chaves compostas forem usadas e uma chave estiver vazia

Detalhes

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

Sugestão

Se for necessária uma validação mais flexível do .NET Framework 4.0, o aplicativo de validação poderá ter como destino a versão 4.5 (ou anterior) do .NET Framework. No entanto, ao redirecionar para o .NET Framework 4.6, a revisão de código deve ser feita para garantir que chaves compostas duplicadas (conforme descrito na descrição deste problema) não sejam validadas.

Nome	Valor
Âmbito	Edge
Versão	4.6
Type	Redirecionamento

.NET Framework 4.6.1

Principal

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

Detalhes

Para aplicativos destinados ao .NET Framework 4.6.1 e versões posteriores, o caractere separador de caminho foi alterado de uma barra invertida ("\") para uma barra ("/") na FullName propriedade de ZipArchiveEntry objetos criados por sobrecargas do CreateFromDirectory método. A alteração coloca 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 arquivos .ZIP sejam descompactados em sistemas que não sejam Windows.
A descompactação de um arquivo zip criado por um aplicativo destinado a uma versão anterior do .NET Framework em sistemas operacionais que não sejam Windows, como o Macintosh, não consegue preservar a estrutura de diretórios. Por exemplo, no Macintosh, ele cria um conjunto de arquivos cujo nome de arquivo concatena o caminho do diretório, juntamente com quaisquer caracteres de barra invertida ("\") e o nome do arquivo. Como resultado, a estrutura de diretórios de arquivos descompactados não é preservada.

Sugestão

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

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

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

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

Nome	Valor
Âmbito	Edge
Versão	4.6.1
Type	Redirecionamento

APIs afetadas

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

Windows Communication Foundation (WCF)

Vinculação WCF com o modo de segurança TransportWithMessageCredential

Detalhes

A partir do .NET Framework 4.6.1, a associação WCF que usa o modo de segurança TransportWithMessageCredential pode ser configurada para receber mensagens com cabeçalhos "para" não assinados para chaves de segurança assimétricas. Por padrão, cabeçalhos "para" não assinados continuarão a ser rejeitados no .NET Framework 4.6.1. Eles só serão aceitos se um aplicativo optar por 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 é usado ou não, use a seguinte definição de configuração:

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

Nome	Valor
Âmbito	Transparente
Versão	4.6.1
Type	Redirecionamento

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 a partir de um certificado que tenha várias entradas DNS em seu campo SAN, o método tentará System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) corresponder o argumento claimType com todas as entradas DNS. Para aplicativos destinados a versões anteriores do .NET Framework, o System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) método tenta corresponder ao argumento claimType somente com a última entrada DNS.

Sugestão

Essa alteração afeta apenas os aplicativos destinados ao .NET Framework 4.6.1. Esta alteração pode ser desativada (ou ativada se o direcionamento for anterior à 4.6.1) com a opção de compatibilidade DisableMultipleDNSEntries .

Nome	Valor
Âmbito	Menor
Versão	4.6.1
Type	Redirecionamento

APIs afetadas

• X509CertificateClaimSet.FindClaims(String, String)

Windows Forms

Application.FilterMessage não é mais lançado para implementações de reentrada de IMessageFilter.PreFilterMessage

Detalhes

Antes do .NET Framework 4.6.1, chamar com um PreFilterMessage(Message) que chamava System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) ou System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (enquanto também chamavaDoEvents()) causava um System.IndexOutOfRangeExceptionFilterMessage(Message) arquivo .

A partir dos aplicativos destinados ao .NET Framework 4.6.1, essa exceção não é mais lançada, e os filtros de reentrada descritos acima podem ser usados.

Sugestão

Esteja ciente de que FilterMessage(Message) não irá mais jogar para o comportamento de reentrada PreFilterMessage(Message) descrito acima. Isso afeta apenas os aplicativos destinados ao .NET Framework 4.6.1.Os aplicativos destinados ao .NET Framework 4.6.1 podem optar por não receber essa alteração (ou os aplicativos destinados a Frameworks mais antigos podem optar por participar) usando a opção de compatibilidade DontSupportReentrantFilterMessage .

Nome	Valor
Âmbito	Edge
Versão	4.6.1
Type	Redirecionamento

APIs afetadas

• Application.FilterMessage(Message)

Windows Presentation Foundation (WPF)

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

Detalhes

Em algumas circunstâncias, chamadas para o método interno System.Windows.Intput.PenContext.Disable em sistemas habilitados para toque podem lançar um não tratado T:System.ArgumentException devido à reentrância.

Sugestão

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

Nome	Valor
Âmbito	Edge
Versão	4.6.1
Type	Redirecionamento

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath lança uma NullReferenceException

Detalhes

No .NET Framework 4.6.2, o tempo de execução lança um T:System.NullReferenceException ao recuperar um P:System.Web.HttpRuntime.AppDomainAppPath valor que inclui caracteres nulos. No .NET Framework 4.6.1 e versões anteriores, o tempo de execução lança um T:System.ArgumentNullExceptionarquivo .

Sugestão

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

• Manipule se o T:System.NullReferenceException aplicativo estiver sendo executado no .NET Framework 4.6.2.
• Atualize para o .NET Framework 4.7, que restaura o comportamento anterior e lança um T:System.ArgumentNullExceptionarquivo .

Nome	Valor
Âmbito	Edge
Versão	4.6.2
Type	Redirecionamento

APIs afetadas

• HttpRuntime.AppDomainAppPath

Principal

O desencriptador AesCryptoServiceProvider fornece uma transformação reutilizável

Detalhes

Começando com aplicativos destinados ao .NET Framework 4.6.2, o AesCryptoServiceProvider desencriptador 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 desencriptador chamando System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) após uma chamada para System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) lançar um CryptographicException ou produz dados corrompidos.

Sugestão

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

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

Além disso, os aplicativos destinados a uma versão anterior do .NET Framework, mas estão sendo executados em uma versão do .NET Framework começando com o .NET Framework 4.6.2, podem optar por ele adicionando a seguinte definição de configuração à <runtime> seção do arquivo de configuração do aplicativo:

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

Nome	Valor
Âmbito	Menor
Versão	4.6.2
Type	Redirecionamento

APIs afetadas

• AesCryptoServiceProvider.CreateDecryptor()

Chamadas para ClaimsIdentity construtores

Detalhes

A partir do .NET Framework 4.6.2, há uma alteração na forma como ClaimsIdentity os construtores com um System.Security.Principal.IIdentity parâmetro definem a System.Security.Claims.ClaimsIdentity.Actor propriedade. Se o System.Security.Principal.IIdentity argumento for um ClaimsIdentity objeto e a System.Security.Claims.ClaimsIdentity.Actor propriedade desse ClaimsIdentity objeto não nullfor , a System.Security.Claims.ClaimsIdentity.Actor propriedade será anexada usando o Clone() método. No Framework 4.6.1 e versões anteriores, a propriedade é anexada System.Security.Claims.ClaimsIdentity.Actor como uma referência existente. Devido a essa alteração, começando com o .NET Framework 4.6.2, a System.Security.Claims.ClaimsIdentity.Actor propriedade do novo ClaimsIdentity objeto não é igual à System.Security.Claims.ClaimsIdentity.Actor propriedade do argumento do construtor System.Security.Principal.IIdentity . No .NET Framework 4.6.1 e versões anteriores, é igual.

Sugestão

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

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

Nome	Valor
Âmbito	Edge
Versão	4.6.2
Type	Redirecionamento

APIs afetadas

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

Alterações na normalização do caminho

Detalhes

Começando com aplicativos destinados ao .NET Framework 4.6.2, a maneira como o tempo de execução normaliza caminhos foi alterada. Normalizar um caminho envolve modificar a cadeia de caracteres que identifica um caminho ou arquivo para que ele esteja em conformidade com um caminho válido no sistema operacional de destino. A normalização normalmente envolve:

• Canonicalização de separadores de componentes e diretórios.
• Aplicação do diretório atual a um caminho relativo.
• Avaliando o diretório relativo (.) ou o diretório pai (..) em um caminho.
• Corte de caracteres especificados. A partir de aplicativos destinados ao .NET Framework 4.6.2, as seguintes alterações na normalização de caminho são habilitadas por padrão:
  • O tempo de execução adia para a função GetFullPathName do sistema operacional para normalizar caminhos.
• A normalização não envolve mais cortar o final dos segmentos de diretório (como um espaço no final de um nome de diretório).
• Suporte para sintaxe de caminho de dispositivo em confiança total, incluindo \\.\ e, para APIs de E/S de arquivo em mscorlib.dll, \\?\.
• O tempo de execução não valida caminhos de sintaxe do dispositivo.
• O uso da sintaxe do dispositivo para acessar fluxos de dados alternativos é suportado. Essas alterações melhoram o desempenho enquanto permitem que os métodos acessem caminhos anteriormente inacessíveis. Os aplicativos destinados ao .NET Framework 4.6.1 e versões anteriores, mas que estão sendo executados no .NET Framework 4.6.2 ou posterior, não são afetados por essa alteração.

Sugestão

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

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

Os aplicativos destinados ao .NET Framework 4.6.1 ou anterior, mas em execução no .NET Framework 4.6.2 ou posterior, podem habilitar as alterações na normalização de caminho adicionando a seguinte linha à <runtime> seção do arquivo .configuration do aplicativo:

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

Nome	Valor
Âmbito	Menor
Versão	4.6.2
Type	Redirecionamento

CurrentCulture e CurrentUICulture fluem entre tarefas

Detalhes

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

Sugestão

Os aplicativos afetados por essa alteração podem contorná-la definindo explicitamente a operação desejada System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture como a primeira operação em uma Tarefa assíncrona. Como alternativa, o comportamento antigo (de não fluir 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 Frameworks 4.6, 4.6.1 através de KB 3139549. Os aplicativos destinados ao .NET Framework 4.6 ou posterior obterão automaticamente o comportamento correto em aplicativos WPF - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) seriam preservados nas operações do Dispatcher.

Nome	Valor
Âmbito	Menor
Versão	4.6
Type	Redirecionamento

APIs afetadas

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

Os nomes de eventos ETW não podem diferir apenas por um sufixo "Start" ou "Stop"

Detalhes

No .NET Framework 4.6 e 4.6.1, o tempo de execução lança um ArgumentException quando dois nomes de eventos de Rastreamento de Eventos para Windows (ETW) diferem apenas por um sufixo "Start" ou "Stop" (como quando um evento é nomeado LogUser e outro é nomeado LogUserStart). Nesse caso, o tempo de execução não pode construir a fonte do evento, que não pode emitir nenhum log.

Sugestão

Para evitar a exceção, certifique-se de que não há dois nomes de evento diferentes apenas por um sufixo "Start" ou "Stop". Este requisito é removido a partir do .NET Framework 4.6.2; o tempo de execução pode desambiguar nomes de eventos que diferem apenas pelo sufixo "Start" e "Stop".

Nome	Valor
Âmbito	Edge
Versão	4.6
Type	Redirecionamento

Suporte de longo caminho

Detalhes

A partir de aplicativos destinados ao .NET Framework 4.6.2, há suporte para caminhos longos (de até 32 mil caracteres) e a limitação de 260 caracteres (ou MAX_PATH) nos comprimentos de caminho foi removida. Para aplicativos que são recompilados para direcionar o .NET Framework 4.6.2, os caminhos de código que anteriormente lançavam um System.IO.PathTooLongException porque um caminho excedia 260 caracteres agora lançarão um System.IO.PathTooLongException somente nas seguintes condições:

• O comprimento do caminho é maior que 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, o tempo de execução lança automaticamente um System.IO.PathTooLongException sempre que um caminho excede 260 caracteres.

Sugestão

Para aplicativos destinados ao .NET Framework 4.6.2, você pode desativar o <runtime> suporte de caminho longo se não for desejável, adicionando o seguinte à seção do seu app.config arquivo:

<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, você pode optar pelo suporte a caminhos longos adicionando o seguinte à <runtime> seção do seu app.config arquivo:

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

Nome	Valor
Âmbito	Menor
Versão	4.6.2
Type	Redirecionamento

As verificações de dois pontos de caminho são mais rigorosas

Detalhes

No .NET Framework 4.6.2, várias alterações foram feitas para oferecer suporte a caminhos sem suporte anteriormente (tanto em comprimento quanto em formato). As verificações da sintaxe adequada do separador de unidade (dois pontos) foram tornadas mais corretas, o que teve o efeito colateral de bloquear alguns caminhos de URI em algumas APIs de caminho selecionadas onde eles eram tolerados anteriormente.

Sugestão

Se passar um URI para APIs afetadas, modifique a cadeia de caracteres para ser um caminho legal primeiro.

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

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

Como alternativa, você pode desativar a normalização do novo caminho definindo a Switch.System.IO.UseLegacyPathHandling opção AppContext como true.

Nome	Valor
Âmbito	Edge
Versão	4.6.2
Type	Redirecionamento

APIs afetadas

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

Segurança

O RSACng agora carrega corretamente chaves RSA de tamanho de chave não padrão

Detalhes

Nas versões do .NET Framework anteriores à 4.6.2, os clientes com tamanhos de chave não padrão para certificados RSA não conseguem acessar essas chaves por meio dos System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) métodos e System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) extensão. A System.Security.Cryptography.CryptographicException com a mensagem "O tamanho da chave solicitado não é suportado" é lançada. No .NET Framework 4.6.2, esse problema foi corrigido. Da mesma forma, ImportParameters(RSAParameters) e ImportParameters(RSAParameters) agora trabalhar com tamanhos de chave não padrão sem lançar um System.Security.Cryptography.CryptographicException.

Sugestão

Se houver alguma lógica de tratamento de exceção que dependa do comportamento anterior em que a é lançada quando tamanhos System.Security.Cryptography.CryptographicException de chave não padrão são usados, considere remover a lógica.

Nome	Valor
Âmbito	Edge
Versão	4.6.2
Type	Redirecionamento

APIs afetadas

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

SignedXml.GetPublicKey retorna RSACng no net462 (ou lightup) sem alterar o redirecionamento

Detalhes

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

Sugestão

Começando com aplicativos executados no .NET Framework 4.7.1, você pode usar a implementação CryptoServiceProvider usada por padrão no .NET Framework 4.6.1 e versões anteriores adicionando a seguinte opção de configuração à seção de tempo de execução do arquivo de configuração do seu aplicativo:

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

Nome	Valor
Âmbito	Edge
Versão	4.6.2
Type	Redirecionamento

APIs afetadas

• SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm)

Windows Communication Foundation (WCF)

Pode ocorrer um impasse ao usar os serviços do Reentrante

Detalhes

Um impasse pode resultar em um serviço de Reentrante, que restringe instâncias do serviço a um thread de execução de cada vez. Os serviços propensos a encontrar esse problema terão o seguinte ServiceBehaviorAttribute em seu código:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Sugestão

Para resolver 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)]

• Instale a atualização mais recente para o .NET Framework 4.6.2 ou atualize para uma versão posterior do .NET Framework. Isso desativa o fluxo do ExecutionContext in OperationContext.Current. Esse comportamento é configurável; É equivalente a adicionar a seguinte configuração de aplicativo ao seu arquivo de configuração:

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

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

Nome	Valor
Âmbito	Menor
Versão	4.6.2
Type	Redirecionamento

APIs afetadas

• System.ServiceModel.ServiceBehaviorAttribute
• ConcurrencyMode.Reentrant

OperationContext.Current pode retornar null quando chamado em uma cláusula using

Detalhes

OperationContext.Current pode retornar null e pode resultar se NullReferenceException todas as seguintes condições forem verdadeiras:

• Você recupera o OperationContext.Current valor da propriedade em um método que retorna um Task ou Task<TResult>.
• Você instancia o OperationContextScope objeto em uma using cláusula.
• Você recupera o OperationContext.Current valor da propriedade dentro using statementdo . Por exemplo:

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

    // ...
}

Sugestão

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

• Modifique seu código da seguinte maneira para instanciar um novo não-objeto null Current :

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

• Instale a atualização mais recente para o .NET Framework 4.6.2 ou atualize para uma versão posterior do .NET Framework. Isso desabilita o fluxo do in OperationContext.Current e restaura ExecutionContext o comportamento de aplicativos WCF no .NET Framework 4.6.1 e versões anteriores. Esse comportamento é configurável; É equivalente a adicionar a seguinte configuração de aplicativo ao seu 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 contexto de execução fluindo entre contextos de operação, você poderá habilitar seu fluxo da seguinte maneira:

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

Nome	Valor
Âmbito	Edge
Versão	4.6.2
Type	Redirecionamento

APIs afetadas

• OperationContext.Current

A segurança de transporte WCF suporta certificados armazenados usando CNG

Detalhes

Começando com aplicativos destinados ao .NET Framework 4.6.2, a segurança de transporte do WCF oferece suporte a certificados armazenados usando a Biblioteca de Criptografia do Windows (CNG). Este suporte é limitado a certificados com uma chave pública que tem um expoente não superior a 32 bits de comprimento. Quando um aplicativo tem como alvo o .NET Framework 4.6.2, esse recurso está ativado por padrão. Em versões anteriores do .NET Framework, a tentativa de usar 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 em execução no .NET Framework 4.6.2, podem habilitar o suporte para certificados CNG adicionando a seguinte linha à <runtime> seção do arquivo app.config ou web.config:

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

Isso também pode ser feito programaticamente 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, devido a essa alteração, qualquer código de tratamento de exceção que dependa da tentativa de iniciar uma comunicação segura com um certificado CNG para falhar não será mais executado.

Nome	Valor
Âmbito	Menor
Versão	4.6.2
Type	Redirecionamento

Windows Forms

Implementação incorreta de MemberDescriptor.Equals

Detalhes

A implementação original do MemberDescriptor.Equals método 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 é comparar o Category do primeiro objeto com o Category do segundo, e o Description do primeiro com o Description do segundo.

Sugestão

Se seu aplicativo depende de MemberDescriptor.Equals retornar às vezes false quando os descritores são equivalentes, e você está direcionando o .NET Framework 4.6.2 ou posterior, você tem várias opções:

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

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

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

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

Nome	Valor
Âmbito	Edge
Versão	4.6.2
Type	Redirecionamento

APIs afetadas

• MemberDescriptor.Equals(Object)

Windows Presentation Foundation (WPF)

CurrentCulture não é preservado nas operações do WPF Dispatcher

Detalhes

A partir do .NET Framework 4.6, as alterações feitas System.Globalization.CultureInfo.CurrentUICulture ou System.Globalization.CultureInfo.CurrentCulture feitas em um System.Windows.Threading.Dispatcher serão perdidas no final dessa operação do dispatcher. Da mesma forma, as alterações feitas System.Globalization.CultureInfo.CurrentUICulture ou System.Globalization.CultureInfo.CurrentCulture feitas fora de uma operação do Dispatcher podem não ser refletidas quando essa operação é executada. Em termos práticos, isso significa que System.Globalization.CultureInfo.CurrentCulture as alterações podem System.Globalization.CultureInfo.CurrentUICulture não fluir entre retornos de chamada da interface do usuário do WPF e outros códigos em um aplicativo WPF. Isso ocorre devido a uma alteração nas System.Threading.ExecutionContext causas System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture a ser armazenada no contexto de execução, começando com aplicativos destinados ao .NET Framework 4.6. As operações do dispatcher do WPF armazenam o contexto de execução usado para iniciar a operação e restaurar o contexto anterior quando a operação for concluída. Como System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture agora fazem parte desse contexto, as alterações neles dentro de uma operação de dispatcher não são persistentes fora da operação.

Sugestão

Os aplicativos afetados por essa alteração podem contornar isso armazenando o desejado System.Globalization.CultureInfo.CurrentCulture ou System.Globalization.CultureInfo.CurrentUICulture em um campo e verificando em todos os corpos de operação do Dispatcher (incluindo manipuladores de retorno de chamada de eventos da interface do usuário) que estão corretos System.Globalization.CultureInfo.CurrentCulture e System.Globalization.CultureInfo.CurrentUICulture definidos. Como alternativa, como a alteração ExecutionContext subjacente a essa alteração do WPF afeta apenas os aplicativos destinados ao .NET Framework 4.6 ou mais recente, essa interrupção pode ser evitada direcionando o .NET Framework 4.5.2.Apps que visam o .NET Framework 4.6 ou posterior também podem contornar isso 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 Frameworks 4.6, 4.6.1 através de KB 3139549. Os aplicativos destinados ao .NET Framework 4.6 ou posterior obterão automaticamente o comportamento correto em aplicativos WPF - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) seriam preservados nas operações do Dispatcher.

Nome	Valor
Âmbito	Menor
Versão	4.6
Type	Redirecionamento