Partilhar via

O que há de novo no .NET Framework

  • Artigo

Observação

O .NET Framework é atendido independentemente das atualizações do Windows com correções de bugs de segurança e confiabilidade. Em geral, as atualizações de segurança são lançadas trimestralmente. O .NET Framework continuará a ser incluído no Windows, sem planos de removê-lo. Você não precisa migrar seus aplicativos .NET Framework, mas para novos desenvolvimentos, use .NET 8 ou posterior.

Este artigo resume os principais novos recursos e melhorias nas seguintes versões do .NET Framework:

Este artigo não fornece informações abrangentes sobre cada novo recurso e está sujeito a alterações. Para obter informações gerais sobre o .NET Framework, consulte Introdução. Para plataformas suportadas, consulte Requisitos do sistema. Para obter links de download e instruções de instalação, consulte Guia de Instalação.

Observação

A equipe do .NET Framework também libera recursos fora da banda, usando o NuGet, para expandir o suporte à plataforma e introduzir novas funcionalidades, como coleções imutáveis e tipos de vetores habilitados para SIMD. Para obter mais informações, consulte Bibliotecas de classes adicionais e APIs e .NET Framework e Versões fora de banda. Consulte uma lista completa de pacotes NuGet para .NET Framework.

Apresentando o .NET Framework 4.8.1

O .NET Framework 4.8.1 baseia-se em versões anteriores do .NET Framework 4.x adicionando muitas novas correções e vários novos recursos, permanecendo um produto muito estável.

Baixe e instale o .NET Framework 4.8.1

Você pode baixar o .NET Framework 4.8.1 dos seguintes locais:

O .NET Framework 4.8 pode ser instalado no Windows 11, Windows 10 versão 21H2, Windows 10 versão 21H1, Windows 10 versão 20H2 e nas plataformas de servidor correspondentes a partir do Windows Server 2022. Você pode instalar o .NET Framework 4.8.1 usando o instalador da Web ou o instalador offline. A maneira recomendada para a maioria dos usuários é usar o instalador da web.

Você pode utilizar o .NET Framework 4.8.1 no Visual Studio 2022 17.3 ou posterior, instalando o .NET Framework 4.8.1 Developer Pack.

O que há de novo no .NET Framework 4.8.1

O .NET Framework 4.8.1 introduz novos recursos nas seguintes áreas:

A acessibilidade aprimorada, que permite que um aplicativo forneça uma experiência apropriada para usuários de Tecnologia Assistiva, é um dos principais focos do .NET Framework 4.8.1. Para obter informações sobre melhorias de acessibilidade no .NET Framework 4.8.1, consulte Novidades em acessibilidade no .NET Framework.

O .NET Framework 4.8.1 adiciona suporte nativo ao Arm64 à família .NET Framework. Portanto, seus investimentos no vasto ecossistema de aplicativos e bibliotecas do .NET Framework agora podem aproveitar os benefícios de executar cargas de trabalho nativamente no Arm64 — ou seja, melhor desempenho quando comparado à execução de código x64 emulado no Arm64.

A Microsoft tem o compromisso de fornecer produtos e plataformas que sejam acessíveis a todos. O .NET Framework 4.8.1 oferece duas plataformas de desenvolvimento de interface do usuário do Windows, ambas fornecendo aos desenvolvedores o suporte necessário para criar aplicativos acessíveis. Ao longo das últimas versões, o Windows Forms e o WPF adicionaram novos recursos e corrigiram vários problemas de confiabilidade relacionados à acessibilidade. Você pode ler mais sobre os detalhes do que foi corrigido ou adicionado em cada versão visitando Novidades em acessibilidade no .NET Framework.

Nesta atualização, tanto o Windows Forms quanto o WPF fizeram melhorias no tratamento das sugestões de texto para torná-las mais acessíveis. Em ambos os casos, as dicas de ferramentas agora estão em conformidade com as diretrizes estabelecidas no conteúdo WCAG2.1 sobre Hover ou Focus guidance. Os requisitos para dicas de ferramentas são:

  • As dicas de ferramentas devem ser exibidas ao passar o mouse ou pela navegação do teclado no controlo.
  • As dicas de ferramentas devem ser dispensáveis. Ou seja, um simples comando de teclado como Esc deve fechar o tooltip.
  • As dicas de ferramenta devem permitir interação ao passar o rato. Os utilizadores devem ser capazes de colocar o cursor do rato sobre o tooltip. Isso possibilita cenários, como o uso de lupa para permitir que usuários com baixa visão leiam as dicas de ferramenta.
  • As dicas de ferramentas devem ser persistentes. As dicas de ferramentas não devem desaparecer automaticamente após um certo período de tempo. Em vez disso, as dicas de ferramentas devem ser descartadas pelo usuário movendo o mouse para outro controle ou por um comando de teclado.

No Windows Forms, esse suporte só está disponível no Windows 11 ou sistemas operacionais posteriores. O Windows Forms é um wrapper gerenciado fino em torno da API do Windows, e o novo comportamento de dica de ferramenta só ficou disponível no Windows 11. O WPF não tem dependências de versão do sistema operacional para suas dicas de ferramentas acessíveis.

O WPF implementou a maioria dos requisitos para dicas de ferramentas compatíveis com WCAG2.1 no .NET Framework 4.8. Nesta versão, o WPF melhorou a experiência garantindo que um tooltip na janela atual possa ser facilmente descartado usando a tecla Esc, a tecla Ctrl (sozinho) ou pela combinação Ctrl+Shift+F10. O escopo da chave de escape foi reduzido nesta versão para se aplicar apenas à janela atual. Anteriormente, aplicava-se a qualquer dica de ferramenta aberta no aplicativo.

A Windows Forms foi a primeira pilha de interface do Windows desenvolvida para o .NET Framework. Como tal, foi originalmente criado para utilizar tecnologia de acessibilidade legada, que não atende aos requisitos de acessibilidade atuais. Nesta versão, o Windows Forms resolveu uma série de problemas. Para obter uma lista completa das alterações relacionadas à acessibilidade, visite Novidades em acessibilidade no .NET Framework.

Os destaques dos aprimoramentos do Windows Forms no .NET Framework 4.8.1 são:

  • Suporte a padrão de texto– Windows Forms adicionou suporte para o padrão de texto UIA. Esse padrão permite que a tecnologia assistiva percorra o conteúdo de um TextBox ou de um controle baseado em texto semelhante letra por letra. Ele permite que o texto seja selecionado dentro do controle e alterado, e um novo texto seja inserido no cursor. O Windows Forms adicionou esse suporte para TextBox, células DataGridView, controles ComboBox e muito mais.

  • Resolver problemas de contraste– Em vários controles, o Windows Forms alterou a taxa de contraste dos retângulos de seleção para ficar mais escura e visível.

  • Corrigidos vários problemas de DataGridView:

    • Os nomes da barra de rolagem foram atualizados para serem consistentes.
    • O Narrador agora pode se concentrar em células DataGridView vazias.
    • Os desenvolvedores podem definir a propriedade de tipo de controle localizado para células DataGridView personalizadas.
    • A cor do link para as células do DataGridViewLink foi atualizada para ter um melhor contraste com o plano de fundo.

Apresentando o .NET Framework 4.8

O .NET Framework 4.8 se baseia em versões anteriores do .NET Framework 4.x adicionando muitas novas correções e vários novos recursos, permanecendo um produto muito estável.

Baixe e instale o .NET Framework 4.8

Você pode baixar o .NET Framework 4.8 dos seguintes locais:

O .NET Framework 4.8 pode ser instalado no Windows 10, Windows 8.1, Windows 7 SP1 e nas plataformas de servidor correspondentes a partir do Windows Server 2008 R2 SP1. Você pode instalar o .NET Framework 4.8 usando o instalador da Web ou o instalador offline. A maneira recomendada para a maioria dos usuários é usar o instalador da web.

Você pode direcionar o .NET Framework 4.8 no Visual Studio 2012 ou posterior instalando o .NET Framework 4.8 Developer Pack.

O que há de novo no .NET Framework 4.8

O .NET Framework 4.8 introduz novos recursos nas seguintes áreas:

A acessibilidade aprimorada, que permite que um aplicativo forneça uma experiência apropriada para usuários de Tecnologia Assistiva, continua a ser um foco principal do .NET Framework 4.8. Para obter informações sobre melhorias de acessibilidade no .NET Framework 4.8, consulte O que há de novo na acessibilidade no .NET Framework.

Classes de base

Impacto reduzido do FIPS na criptografia. Em versões anteriores do .NET Framework, classes de provedor criptográfico gerenciado, como SHA256Managed lançam um CryptographicException quando as bibliotecas criptográficas do sistema são configuradas em "modo FIPS". Essas exceções são lançadas porque as versões gerenciadas das classes de provedor de criptografia, ao contrário das bibliotecas criptográficas do sistema, não passaram pela certificação FIPS (Federal Information Processing Standards) 140-2. Como poucos programadores têm as suas máquinas de desenvolvimento no modo FIPS, as exceções são frequentemente geradas em ambientes de produção.

Por padrão, em aplicativos destinados ao .NET Framework 4.8, as seguintes classes de criptografia gerenciadas não lançam mais um CryptographicException nesse caso:

Em vez disso, essas classes redirecionam operações criptográficas para uma biblioteca de criptografia do sistema. Essa alteração efetivamente remove uma diferença potencialmente confusa entre ambientes de desenvolvedor e ambientes de produção e faz com que componentes nativos e componentes gerenciados operem sob a mesma política criptográfica. Os aplicativos que dependem dessas exceções podem restaurar o comportamento anterior definindo a opção AppContext Switch.System.Security.Cryptography.UseLegacyFipsThrow como true. Para obter mais informações, consulte Classes de criptografia gerenciadas não lançam uma CryptographyException no modo FIPS.

Uso da versão atualizada do ZLib

A partir do .NET Framework 4.5, o assembly clrcompression.dll usa ZLib, uma biblioteca externa nativa para compactação de dados, a fim de fornecer uma implementação para o algoritmo de esvaziamento. A versão do .NET Framework 4.8 do clrcompression.dll é atualizada para usar o ZLib Versão 1.2.11, que inclui várias melhorias e correções importantes.

Windows Communication Foundation (WCF)

Introdução do ServiceHealthBehavior

Os pontos de verificação de saúde são amplamente utilizados por ferramentas de orquestração para gerir serviços com base no seu estado de saúde. As verificações de integridade também podem ser usadas por ferramentas de monitoramento para rastrear e fornecer notificações sobre a disponibilidade e o desempenho de um serviço.

ServiceHealthBehavior é um comportamento de serviço WCF que amplia IServiceBehavior. Quando um comportamento de serviço é adicionado à coleção ServiceDescription.Behaviors, faz o seguinte:

  • Retorna o status de integridade do serviço com códigos de resposta HTTP. Você pode especificar em uma cadeia de caracteres de consulta o código de status HTTP para uma solicitação de teste de integridade HTTP/GET.

  • Publica informações sobre a saúde do serviço. Detalhes específicos do serviço, incluindo estado do serviço, contagens de aceleração e capacidade, podem ser exibidos usando uma solicitação HTTP/GET com a cadeia de caracteres de consulta ?health. A facilidade de acesso a essas informações é importante ao solucionar problemas de um serviço WCF com comportamento incorreto.

Existem duas maneiras de expor o endpoint de saúde e publicar as informações de integridade do serviço WCF.

  • Por código. Por exemplo:

    ServiceHost host = new ServiceHost(typeof(Service1),
                   new Uri("http://contoso:81/Service1"));
ServiceHealthBehavior healthBehavior =
    host.Description.Behaviors.Find<ServiceHealthBehavior>();
healthBehavior ??= new ServiceHealthBehavior();
host.Description.Behaviors.Add(healthBehavior);

    Dim host As New ServiceHost(GetType(Service1),
            New Uri("http://contoso:81/Service1"))
Dim healthBehavior As ServiceHealthBehavior =
   host.Description.Behaviors.Find(Of ServiceHealthBehavior)()
If healthBehavior Is Nothing Then
   healthBehavior = New ServiceHealthBehavior()
End If
host.Description.Behaviors.Add(healthBehavior)

  • Usando um arquivo de configuração. Por exemplo:

    <behaviors>
  <serviceBehaviors>
    <behavior name="DefaultBehavior">
      <serviceHealth httpsGetEnabled="true"/>
    </behavior>
  </serviceBehaviors>
</behaviors>

O status de integridade de um serviço pode ser consultado usando parâmetros de consulta como OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded) e um código de resposta HTTP pode ser especificado para cada parâmetro de consulta. Se o código de resposta HTTP for omitido para um parâmetro de consulta, um código de resposta HTTP 503 será usado por padrão. Por exemplo:

  • OnServiceFailure: https://contoso:81/Service1?health&OnServiceFailure=450

    Um código de status de resposta HTTP 450 é retornado quando ServiceHost.State é maior que CommunicationState.Opened.

Parâmetros de consulta e exemplos:

  • OnDispatcherFailure: https://contoso:81/Service1?health&OnDispatcherFailure=455

    Um código de estado de resposta HTTP 455 é retornado quando o estado de qualquer um dos despachantes de canal é maior que CommunicationState.Opened.

  • OnListenerFailure: https://contoso:81/Service1?health&OnListenerFailure=465

    Um código de estado de resposta HTTP 465 é retornado quando o estado de qualquer um dos ouvintes do canal é maior que CommunicationState.Opened.

  • OnThrottlePercentExceeded: https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500

    Especifica a porcentagem {1 – 100} que aciona a resposta e seu código de resposta HTTP {200 – 599}. Neste exemplo:

    • Se a porcentagem for maior que 95, um código de resposta HTTP 500 será retornado.

    • Se a percentagem estiver entre os valores 70 e 95, 350 é retornado.

    • Caso contrário, 200 é devolvido.

O status de integridade do serviço pode ser exibido em HTML especificando uma cadeia de caracteres de consulta como https://contoso:81/Service1?health ou em XML especificando uma cadeia de caracteres de consulta como https://contoso:81/Service1?health&Xml. Uma cadeia de caracteres de consulta como https://contoso:81/Service1?health&NoContent retorna uma página HTML vazia.

Windows Presentation Foundation (WPF)

Melhorias de Alto DPI

No .NET Framework 4.8, o WPF adiciona suporte para reconhecimento de DPI Per-Monitor V2 e dimensionamento de DPI Mixed-Mode. Consulte Desenvolvimento de Aplicações de Ambiente de Trabalho com Alta Densidade de Pixels no Windows para obter informações adicionais sobre o desenvolvimento de alta densidade de pixels.

O .NET Framework 4.8 melhora o suporte para HWNDs hospedados e a interoperação de Windows Forms em aplicações WPF High-DPI em plataformas que possuem suporte ao escalonamento de DPI Mixed-Mode (começando com a Atualização de abril de 2018 do Windows 10). Quando HWNDs incorporados ou controlos Windows Forms são criados como janelas dimensionadas por DPI Mixed-Mode ao chamar SetThreadDpiHostingBehavior e SetThreadDpiAwarenessContext, eles podem ser integrados numa aplicação WPF Per-Monitor V2 e são dimensionados e escalados adequadamente. Esse conteúdo hospedado não é renderizado no DPI nativo; em vez disso, o sistema operacional dimensiona o conteúdo hospedado para o tamanho apropriado. O suporte para o modo de reconhecimento de DPI versão 2 Per-Monitor também permite que os controlos WPF sejam hospedados (ou seja, incorporados) numa janela nativa em uma aplicação de alto DPI.

Para habilitar o suporte para Mixed-Mode dimensionamento de DPI alto, pode definir os seguintes interruptores de AppContext no arquivo de configuração da aplicação:

<runtime>
   <AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=false; Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false"/>
</runtime>

Tempo de execução de linguagem comum

O tempo de execução no .NET Framework 4.8 inclui as seguintes alterações e melhorias:

Melhorias no compilador JIT. O compilador Just-in-time (JIT) no .NET Framework 4.8 é baseado no compilador JIT no .NET Core 2.1. Muitas das otimizações e todas as correções de bugs feitas no compilador JIT do .NET Core 2.1 estão incluídas no compilador JIT do .NET Framework 4.8.

melhorias NGEN. O tempo de execução melhorou seu gerenciamento de memória para imagens NGEN (Native Image Generator) para que os dados mapeados a partir de imagens NGEN não sejam residentes na memória. Isso reduz a área de superfície disponível para ataques que tentam executar código arbitrário modificando a memória que será executada.

Verificação antimalware para todos os assemblies. Em versões anteriores do .NET Framework, o runtime verifica todos os assemblies carregados do disco usando o Windows Defender ou software antimalware de terceiros. No entanto, conjuntos carregados de outras fontes, como pelo método Assembly.Load(Byte[]), não são verificados e podem conter malware não detetado. A partir do .NET Framework 4.8 em execução no Windows 10, o tempo de execução inicia uma verificação por soluções antimalware que implementam a Interface de Verificação Antimalware (AMSI).

O que há de novo no .NET Framework 4.7.2

O .NET Framework 4.7.2 inclui novos recursos nas seguintes áreas:

Um foco contínuo no .NET Framework 4.7.2 é a acessibilidade aprimorada, que permite que um aplicativo forneça uma experiência apropriada para usuários de Tecnologia Assistiva. Para obter informações sobre melhorias de acessibilidade no .NET Framework 4.7.2, consulte O que há de novo na acessibilidade no .NET Framework.

Classes de base

O .NET Framework 4.7.2 apresenta um grande número de aprimoramentos criptográficos, melhor suporte à descompactação para arquivos ZIP e APIs de coleção adicionais.

Novas sobrecargas de RSA.Create e DSA.Create

Os métodos DSA.Create(DSAParameters) e RSA.Create(RSAParameters) permitem fornecer parâmetros-chave ao instanciar uma nova DSA ou RSA chave. Eles permitem que você substitua o código como o seguinte:

// Before .NET Framework 4.7.2
using (RSA rsa = RSA.Create())
{
   rsa.ImportParameters(rsaParameters);
   // Other code to execute using the RSA instance.
}

' Before .NET Framework 4.7.2
Using rsa = RSA.Create()
   rsa.ImportParameters(rsaParameters)
   ' Other code to execute using the rsa instance.
End Using

com código como este:

// Starting with .NET Framework 4.7.2
using (RSA rsa = RSA.Create(rsaParameters))
{
   // Other code to execute using the rsa instance.
}

' Starting with .NET Framework 4.7.2
Using rsa = RSA.Create(rsaParameters)
   ' Other code to execute using the rsa instance.
End Using

Os métodos DSA.Create(Int32) e RSA.Create(Int32) permitem gerar novas chaves DSA ou RSA com um tamanho de chave específico. Por exemplo:

using (DSA dsa = DSA.Create(2048))
{
   // Other code to execute using the dsa instance.
}

Using dsa = DSA.Create(2048)
   ' Other code to execute using the dsa instance.
End Using

Os construtores Rfc2898DeriveBytes aceitam um nome de algoritmo de hash

A classe Rfc2898DeriveBytes tem três novos construtores com um parâmetro HashAlgorithmName que identifica o algoritmo HMAC a ser usado ao derivar chaves. Em vez de usar SHA-1, os desenvolvedores devem usar um HMAC baseado em SHA-2 como SHA-256, conforme mostrado no exemplo a seguir:

private static byte[] DeriveKey(string password, out int iterations, out byte[] salt,
                                out HashAlgorithmName algorithm)
{
   iterations = 100000;
   algorithm = HashAlgorithmName.SHA256;

   const int SaltSize = 32;
   const int DerivedValueSize = 32;

   using (Rfc2898DeriveBytes pbkdf2 = new Rfc2898DeriveBytes(password, SaltSize,
                                                             iterations, algorithm))
   {
      salt = pbkdf2.Salt;
      return pbkdf2.GetBytes(DerivedValueSize);
   }
}

Private Shared Function DeriveKey(password As String, ByRef iterations As Integer,
                                  ByRef salt AS Byte(), ByRef algorithm As HashAlgorithmName) As Byte()
   iterations = 100000
   algorithm = HashAlgorithmName.SHA256

   Const SaltSize As Integer = 32
   Const  DerivedValueSize As Integer = 32

   Using pbkdf2 = New Rfc2898DeriveBytes(password, SaltSize, iterations, algorithm)
      salt = pbkdf2.Salt
      Return pbkdf2.GetBytes(DerivedValueSize)
   End Using
End Function

Suporte para chaves efêmeras

A importação PFX pode, opcionalmente, carregar chaves privadas diretamente da memória, ignorando o disco rígido. Quando o novo sinalizador de X509KeyStorageFlags.EphemeralKeySet é especificado no construtor X509Certificate2 ou numa das sobrecargas do método X509Certificate2.Import, as chaves privadas serão carregadas como chaves efémeras. Isso impede que as chaves fiquem visíveis no disco. No entanto:

  • Como as chaves não são persistentes no disco, os certificados carregados com esse sinalizador não são bons candidatos para adicionar a uma X509Store.

  • As chaves carregadas desta forma são quase sempre carregadas através do Windows CNG. Portanto, os chamadores devem acessar a chave privada chamando métodos de extensão, como cert. GetRSAPrivateKey(). A propriedade X509Certificate2.PrivateKey não funciona.

  • Como a propriedade X509Certificate2.PrivateKey herdada não funciona com certificados, os desenvolvedores devem realizar testes rigorosos antes de mudar para chaves efêmeras.

Criação programática de solicitações de assinatura de certificação PKCS#10 e certificados de chave pública X.509

A partir do .NET Framework 4.7.2, as cargas de trabalho podem gerar solicitações de assinatura de certificado (CSRs), o que permite que a geração de solicitações de certificado seja preparada em ferramentas existentes. Isso é frequentemente útil em cenários de teste.

Para obter mais informações e exemplos de código, consulte "Criação programática de solicitações de assinatura de certificação PKCS#10 e certificados de chave pública X.509" nodo Blog do .NET.

Novos membros SignerInfo

A partir do .NET Framework 4.7.2, a classe SignerInfo expõe mais informações sobre a assinatura. Você pode recuperar o valor da propriedade System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm para determinar o algoritmo de assinatura usado pelo signatário. SignerInfo.GetSignature pode ser chamado para obter uma cópia da assinatura criptográfica para este signatário.

Deixar um fluxo encapsulado aberto depois que o CryptoStream é descartado

A partir do .NET Framework 4.7.2, a classe CryptoStream tem um construtor adicional que permite que Dispose não feche o fluxo encapsulado. Para deixar o fluxo encapsulado aberto depois que a instância de CryptoStream for descartada, chame o novo construtor CryptoStream da seguinte maneira:

var cStream = new CryptoStream(stream, transform, mode, leaveOpen: true);

Dim cStream = New CryptoStream(stream, transform, mode, leaveOpen:=true)

Alterações de descompressão no DeflateStream

A partir do .NET Framework 4.7.2, a implementação de operações de descompactação na classe DeflateStream foi alterada para usar APIs nativas do Windows por padrão. Normalmente, isso resulta em uma melhoria substancial de desempenho.

O suporte para descompactação usando APIs do Windows é habilitado por padrão para aplicativos destinados ao .NET Framework 4.7.2. Os aplicativos destinados a versões anteriores do .NET Framework, mas que estão sendo executados no .NET Framework 4.7.2, podem optar por esse comportamento adicionando a seguinte opção AppContext ao arquivo de configuração do aplicativo:

<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

APIs de coleção adicionais

O .NET Framework 4.7.2 adiciona várias novas APIs aos tipos SortedSet<T> e HashSet<T>. Estes incluem:

A classe ConcurrentDictionary<TKey,TValue> inclui novas sobrecargas do AddOrUpdate e GetOrAdd métodos para recuperar um valor do dicionário ou adicioná-lo se ele não for encontrado, e para adicionar um valor ao dicionário ou atualizá-lo se ele já existir.

public TValue AddOrUpdate<TArg>(TKey key, Func<TKey, TArg, TValue> addValueFactory, Func<TKey, TValue, TArg, TValue> updateValueFactory, TArg factoryArgument)

public TValue GetOrAdd<TArg>(TKey key, Func<TKey, TArg, TValue> valueFactory, TArg factoryArgument)

Public AddOrUpdate(Of TArg)(key As TKey, addValueFactory As Func(Of TKey, TArg, TValue), updateValueFactory As Func(Of TKey, TValue, TArg, TValue), factoryArgument As TArg) As TValue

Public GetOrAdd(Of TArg)(key As TKey, valueFactory As Func(Of TKey, TArg, TValue), factoryArgument As TArg) As TValue

ASP.NET

Suporte para injeção de dependência em Web Forms

Injeção de dependência (DI) desacopla objetos e suas dependências para que o código de um objeto não precise mais ser alterado apenas porque uma dependência foi alterada. Ao desenvolver ASP.NET aplicativos destinados ao .NET Framework 4.7.2, você pode:

  • Use a injeção baseada em setter, interface e construtor nos manipuladores , módulos, instâncias de página ,e controles de usuário , de projetos de aplicações web ASP.NET.

  • Use a injeção baseada em setter e interface em manipuladores de e módulos, instâncias de página e controles de usuário em projetos de sites ASP.NET.

  • Conecte diferentes estruturas de injeção de dependência.

Suporte para cookies do mesmo site

SameSite impede que um navegador envie um cookie junto com uma solicitação entre sites. O .NET Framework 4.7.2 adiciona uma propriedade HttpCookie.SameSite cujo valor é um membro da enumeração System.Web.SameSiteMode. Se seu valor for SameSiteMode.Strict ou SameSiteMode.Lax, ASP.NET adicionará o atributo SameSite ao cabeçalho set-cookie. O suporte do SameSite aplica-se aos HttpCookie objetos, bem como aos FormsAuthentication e System.Web.SessionState cookies.

Você pode definir SameSite para um objeto HttpCookie da seguinte maneira:

var c = new HttpCookie("secureCookie", "same origin");
c.SameSite = SameSiteMode.Lax;

Dim c As New HttpCookie("secureCookie", "same origin")
c.SameSite = SameSiteMode.Lax

Você também pode configurar cookies do SameSite no nível do aplicativo modificando o arquivo web.config:

<system.web>
   <httpCookies sameSite="Strict" />
</system.web>

Você pode adicionar SameSite para FormsAuthentication e System.Web.SessionState cookies modificando o arquivo de configuração da web:

<system.web>
   <authentication mode="Forms">
      <forms cookieSameSite="Lax">
         <!-- ...   -->
      </forms>
   </authentication>
   <sessionState cookieSameSite="Lax"></sessionState>
</system.web>

Ligação em rede

A implementação de propriedades do HttpClientHandler

O .NET Framework 4.7.1 adicionou oito propriedades à classe System.Net.Http.HttpClientHandler. No entanto, dois lançaram um PlatformNotSupportedException. O .NET Framework 4.7.2 agora fornece uma implementação para essas propriedades. Os imóveis são:

SQLClient

Suporte para Autenticação Universal do Azure Ative Directory e autenticação multifator

As crescentes exigências de conformidade e segurança exigem que muitos clientes usem a autenticação multifator (MFA). Além disso, as práticas recomendadas atuais desencorajam a inclusão de senhas de usuário diretamente nas cadeias de conexão. Para dar suporte a essas alterações, o .NET Framework 4.7.2 estende as cadeias de conexão SQLClient, adicionando um novo valor, "Active Directory Interactive", para a palavra-chave de "Autenticação" existente, de modo a dar suporte à autenticação multifator (MFA) e à Autenticação do Azure AD. O novo método interativo dá suporte a usuários nativos e federados do Azure AD, bem como a usuários convidados do Azure AD. Quando esse método é usado, a autenticação MFA imposta pelo Azure AD tem suporte para bancos de dados SQL. Além disso, o processo de autenticação solicita uma senha de usuário para aderir às práticas recomendadas de segurança.

Em versões anteriores do .NET Framework, a conectividade SQL suportava apenas as opções SqlAuthenticationMethod.ActiveDirectoryPassword e SqlAuthenticationMethod.ActiveDirectoryIntegrated. Ambos fazem parte do protocolo não interativo ADAL, que não suporta MFA. Com a nova opção SqlAuthenticationMethod.ActiveDirectoryInteractive, a conectividade SQL suporta MFA, bem como métodos de autenticação existentes (senha e autenticação integrada), que permite que os usuários insiram senhas de usuário interativamente sem persistir senhas na cadeia de conexão.

Para obter mais informações e um exemplo, consulte "SQL -- Azure AD Universal and Multifactor Authentication Support" nodo Blog do .NET.

Suporte para Always Encrypted versão 2

NET Framework 4.7.2 adiciona suporte para Always Encrypted baseado em enclave. A versão original do Always Encrypted é uma tecnologia de criptografia do lado do cliente na qual as chaves de criptografia nunca saem do cliente. No Always Encrypted baseado em enclave, o cliente pode, opcionalmente, enviar as chaves de criptografia para um enclave seguro, que é uma entidade computacional segura que pode ser considerada parte do SQL Server, mas que o código do SQL Server não pode adulterar. Para oferecer suporte a Always Encrypted baseado em enclave, o .NET Framework 4.7.2 adiciona os seguintes tipos e membros ao namespace System.Data.SqlClient:

O arquivo de configuração do aplicativo especifica uma implementação concreta da classe System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider abstrata que fornece a funcionalidade para o provedor de enclave. Por exemplo:

<configuration>
  <configSections>
    <section name="SqlColumnEncryptionEnclaveProviders" type="System.Data.SqlClient.SqlColumnEncryptionEnclaveProviderConfigurationSection,System.Data,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b77a5c561934e089"/>
  </configSections>
  <SqlColumnEncryptionEnclaveProviders>
    <providers>
      <add name="Azure" type="Microsoft.SqlServer.Management.AlwaysEncrypted.AzureEnclaveProvider,MyApp"/>
      <add name="HGS" type="Microsoft.SqlServer.Management.AlwaysEncrypted.HGSEnclaveProvider,MyApp" />
    </providers>
  </SqlColumnEncryptionEnclaveProviders >
</configuration>

O fluxo básico do Always Encrypted baseado em enclave é:

  1. O usuário cria uma conexão AlwaysEncrypted com o SQL Server que oferece suporte ao Always Encrypted baseado em enclave. O controlador entra em contato com o serviço de atestação para garantir que está a conectar-se ao enclave certo.

  2. Uma vez que o enclave tenha sido atestado, o driver estabelece um canal seguro com o enclave seguro hospedado no SQL Server.

  3. O driver compartilha chaves de criptografia autorizadas pelo cliente com o enclave seguro durante a duração da conexão SQL.

Windows Presentation Foundation

Localizando Dicionários de Recursos por Fonte

A partir do .NET Framework 4.7.2, um assistente de diagnóstico pode localizar os ResourceDictionaries que foram criados a partir de um determinado Uri de origem. (Esse recurso é para uso por assistentes de diagnóstico, não por aplicativos de produção.) Um assistente de diagnóstico, como o recurso "Editar e continuar" do Visual Studio, permite que o usuário edite um ResourceDictionary com a intenção de que as alterações sejam aplicadas ao aplicativo em execução. Uma etapa para conseguir isso é encontrar todos os ResourceDictionaries que o aplicativo em execução criou a partir do dicionário que está sendo editado. Por exemplo, um aplicativo pode declarar um ResourceDictionary cujo conteúdo é copiado de um determinado URI de origem:

<ResourceDictionary Source="MyRD.xaml" />

Um assistente de diagnóstico que edita a marcação original em MyRD.xaml pode usar o novo recurso para localizar o dicionário. O recurso é implementado por um novo método estático, ResourceDictionaryDiagnostics.GetResourceDictionariesForSource. O assistente de diagnóstico chama o novo método usando um Uri absoluto que identifica a marcação original, conforme ilustrado pelo código a seguir:

IEnumerable<ResourceDictionary> dictionaries = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(new Uri("pack://application:,,,/MyApp;component/MyRD.xaml"));

Dim dictionaries As IEnumerable(Of ResourceDictionary) = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(New Uri("pack://application:,,,/MyApp;component/MyRD.xaml"))

O método retorna um enumerável vazio, a menos que VisualDiagnostics esteja habilitado e a variável de ambiente ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO esteja definida.

Encontrar proprietários do ResourceDictionary

A partir do .NET Framework 4.7.2, um assistente de diagnóstico pode localizar os proprietários de um determinado ResourceDictionary. (O recurso é para uso por assistentes de diagnóstico e não por aplicativos de produção.) Sempre que uma alteração é feita em um , o WPF encontra automaticamente todas as referências DynamicResource que possam ser afetadas pela alteração.

Um assistente de diagnóstico, como o recurso "Edit-and-Continue" do Visual Studio, pode querer estender isto para lidar com referências StaticResource . O primeiro passo neste processo é encontrar os proprietários do dicionário; ou seja, encontrar todos os objetos cuja propriedade Resources se refere ao dicionário (direta ou indiretamente através da propriedade ResourceDictionary.MergedDictionaries). Três novos métodos estáticos implementados na classe System.Windows.Diagnostics.ResourceDictionaryDiagnostics, um para cada um dos tipos base que tem uma propriedade Resources, suportam esta etapa:

Esses métodos retornam um enumerável vazio, a menos que VisualDiagnostics esteja habilitado e a variável de ambiente ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO esteja definida.

Localizar referências a StaticResource

Agora, um assistente de diagnóstico pode receber uma notificação sempre que uma referência StaticResource for resolvida. (O recurso é para uso por assistentes de diagnóstico, não por aplicativos de produção.) Um assistente de diagnóstico, como o recurso "Editar e continuar" do Visual Studio, pode querer atualizar todos os usos de um recurso quando seu valor em um ResourceDictionary muda. O WPF faz isso automaticamente para referências de DynamicResource, mas intencionalmente não faz isso para referências de StaticResource. A partir do .NET Framework 4.7.2, o assistente de diagnóstico pode usar essas notificações para localizar esses usos do recurso estático.

A notificação é implementada pelo novo evento ResourceDictionaryDiagnostics.StaticResourceResolved:

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;

Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)

Este evento é gerado sempre que o tempo de execução do sistema resolve uma referência de StaticResource. Os argumentos descrevem a resolução e indicam o objeto e a propriedade que hospedam a referência StaticResource e a e a chave usadas para a resolução:

public class StaticResourceResolvedEventArgs : EventArgs
{
   public Object TargetObject { get; }

   public Object TargetProperty { get; }

   public ResourceDictionary ResourceDictionary { get; }

   public object ResourceKey { get; }
}

Public Class StaticResourceResolvedEventArgs : Inherits EventArgs
   Public ReadOnly Property TargetObject As Object
   Public ReadOnly Property TargetProperty As Object
   Public ReadOnly Property ResourceDictionary As ResourceDictionary
   Public ReadOnly Property ResourceKey As Object
End Class

O evento não é gerado (e seu acessador de add é ignorado), a menos que VisualDiagnostics esteja habilitado e a variável de ambiente ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO seja definida.

ClickOnce

Aplicativos com reconhecimento de HDPI para Windows Forms, Windows Presentation Foundation (WPF) e Visual Studio Tools for Office (VSTO) podem ser implantados usando ClickOnce. Se a seguinte entrada for encontrada no manifesto do aplicativo, a implantação terá êxito no .NET Framework 4.7.2:

<windowsSettings>
   <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>

Para o aplicativo Windows Forms, a solução alternativa anterior de definir o reconhecimento de DPI no arquivo de configuração do aplicativo em vez do manifesto do aplicativo não é mais necessária para que a implantação do ClickOnce seja bem-sucedida.

O que há de novo no .NET Framework 4.7.1

O .NET Framework 4.7.1 inclui novos recursos nas seguintes áreas:

Além disso, um foco importante no .NET Framework 4.7.1 é a acessibilidade aprimorada, que permite que um aplicativo forneça uma experiência apropriada para usuários de Tecnologia Assistiva. Para obter informações sobre melhorias de acessibilidade no .NET Framework 4.7.1, consulte O que há de novo na acessibilidade no .NET Framework.

Classes de base

Suporte para .NET Standard 2.0

.NET Standard define um conjunto de APIs que devem estar disponíveis em cada implementação do .NET que ofereça suporte a essa versão do padrão. O .NET Framework 4.7.1 suporta totalmente o .NET Standard 2.0 e adiciona cerca de 200 APIs definidas no .NET Standard 2.0 e ausentes do .NET Framework 4.6.1, 4.6.2 e 4.7. (Observe que essas versões do .NET Framework oferecem suporte ao .NET Standard 2.0 somente se arquivos de suporte adicionais do .NET Standard também forem implantados no sistema de destino.) Para obter mais informações, consulte "BCL - .NET Standard 2.0 Support" na postagem do blog .NET Framework 4.7.1 Runtime and Compiler Features.

Suporte para construtores de configuração

Os construtores de configurações permitem que os desenvolvedores injetem e criem definições de configuração para aplicativos dinamicamente em tempo de execução. Os construtores de configurações personalizadas podem ser usados para modificar dados existentes em uma seção de configuração ou para construir uma seção de configuração inteiramente do zero. Sem construtores de configuração, .config arquivos são estáticos e suas configurações são definidas algum tempo antes de um aplicativo ser iniciado.

Para criar um construtor de configuração personalizado, derive o seu construtor da classe abstrata ConfigurationBuilder e substitua os seus ConfigurationBuilder.ProcessConfigurationSection e ConfigurationBuilder.ProcessRawXml. Você também define os seus construtores no seu ficheiro .config. Para obter mais informações, consulte a seção "Configuration Builders" na postagem de blog do .NET Framework 4.7.1 ASP.NET and Configuration Features.

Deteção de recursos em tempo de execução

A classe System.Runtime.CompilerServices.RuntimeFeature fornece um mecanismo para determinar se um recurso predefinido é suportado em uma determinada implementação .NET em tempo de compilação ou tempo de execução. Em tempo de compilação, um compilador pode verificar se existe um campo especificado para determinar se o recurso é suportado; em caso afirmativo, pode emitir código que tira partido dessa funcionalidade. Em tempo de execução, um aplicativo pode chamar o método RuntimeFeature.IsSupported antes de emitir código em tempo de execução. Para obter mais informações, consulte Adicionar método auxiliar para descrever os recursos suportados pelo tempo de execução.

Tipos de tupla de valores são serializáveis

A partir do .NET Framework 4.7.1, System.ValueTuple e seus tipos genéricos associados são marcados como serializável , que permite a serialização binária. Isso deve facilitar a migração de tipos de tupla, como Tuple<T1,T2,T3> e Tuple<T1,T2,T3,T4>, para tipos de tupla de valor. Para obter mais informações, consulte "Compiler -- ValueTuple is Serializable" na publicação do blogue sobre as funcionalidades do runtime e do compilador do .NET Framework 4.7.1.

Suporte para referências somente leitura

O .NET Framework 4.7.1 adiciona o System.Runtime.CompilerServices.IsReadOnlyAttribute. Esse atributo é usado por compiladores de linguagem para marcar membros que têm tipos ou parâmetros de retorno ref somente leitura. Para obter mais informações, consulte "Compiler -- Support for ReadOnlyReferences" na postagem de blog .NET Framework 4.7.1 Runtime and Compiler Features. Para obter informações sobre valores de retorno ref, consulte Ref return values e ref locals e Ref return values (Visual Basic).

Common Language Runtime (CLR)

Melhorias no desempenho da coleta de lixo

As alterações na coleta de lixo (GC) no .NET Framework 4.7.1 melhoram o desempenho geral, especialmente para alocações de heap de objeto grande (LOH). No .NET Framework 4.7.1, são usados bloqueios separados para alocações no heap de objetos pequenos (SOH) e no heap de objetos grandes (LOH), o que permite que as alocações no LOH ocorram quando o GC em background está varrendo o SOH. Como resultado, as aplicações que fazem um grande número de alocações de LOH devem experimentar uma redução na contenção de bloqueio de alocação e um melhor desempenho. Para obter mais informações, consulte a seção "Runtime -- GC Performance Improvements" na postagem do blog .NET Framework 4.7.1 Runtime and Compiler Features.

Ligação em rede

Suporte ao SHA-2 para o Message.HashAlgorithm

No .NET Framework 4.7 e versões anteriores, a propriedade Message.HashAlgorithm suportava valores de HashAlgorithm.Md5 e HashAlgorithm.Sha apenas. A partir do .NET Framework 4.7.1, HashAlgorithm.Sha256, HashAlgorithm.Sha384e HashAlgorithm.Sha512 também são suportados. Se esse valor é realmente usado depende do MSMQ, uma vez que a instância Message em si não faz hash, mas simplesmente passa valores para o MSMQ. Para obter mais informações, consulte a seção "Suporte a SHA-2 para Message.HashAlgorithm" na postagem de blog ASP.NET e configuração do .NET Framework 4.7.1.

ASP.NET

Etapas de execução em aplicativos ASP.NET

ASP.NET processa solicitações em um pipeline predefinido que inclui 23 eventos. ASP.NET executa cada manipulador de eventos como uma etapa de execução. Em versões do ASP.NET até ao .NET Framework 4.7, o ASP.NET não consegue fluir o contexto de execução devido à alternância entre threads nativos e geridos. Em vez disso, o ASP.NET transfere seletivamente apenas o HttpContext. A partir do .NET Framework 4.7.1, o método HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) também permite que os módulos restaurem dados ambientais. Esse recurso é direcionado a bibliotecas relacionadas a rastreamento, criação de perfis, diagnósticos ou transações, por exemplo, que se preocupam com o fluxo de execução do aplicativo. Para obter mais informações, consulte o "ASP.NET Execution Step Feature" na postagem de blog ASP.NET e Recursos de Configuração do .NET Framework 4.7.1.

ASP.NET análise de HttpCookie

O .NET Framework 4.7.1 inclui um novo método, HttpCookie.TryParse, que fornece uma maneira padronizada de criar um objeto HttpCookie a partir de uma cadeia de caracteres e atribuir com precisão valores de cookie, como data de expiração e caminho. Para obter mais informações, consulte "ASP.NET HttpCookie parsing" na postagem de blog do .NET Framework 4.7.1 ASP.NET and Configuration Features.

opções de hash SHA-2 para credenciais de autenticação de formulários ASP.NET

No .NET Framework 4.7 e versões anteriores, ASP.NET permitia que os desenvolvedores armazenassem credenciais de usuário com senhas com hash em arquivos de configuração usando MD5 ou SHA1. A partir do .NET Framework 4.7.1, o ASP.NET também oferece suporte a novas opções de hash SHA-2 seguras, como SHA256, SHA384 e SHA512. SHA1 permanece o padrão, e um algoritmo de hash não padrão pode ser definido no arquivo de configuração da Web.

Importante

A Microsoft recomenda que você use o fluxo de autenticação mais seguro disponível. Se você estiver se conectando ao SQL do Azure, Identidades Gerenciadas para recursos do Azure é o método de autenticação recomendado.

O que há de novo no .NET Framework 4.7

O .NET Framework 4.7 inclui novos recursos nas seguintes áreas:

Para obter uma lista de novas APIs adicionadas ao .NET Framework 4.7, consulte de alterações de API do .NET Framework 4.7 no GitHub. Para obter uma lista de melhorias de recursos e correções de bugs no .NET Framework 4.7, consulte Lista de alterações do .NET Framework 4.7 no GitHub. Para obter mais informações, consulte Anunciando o do .NET Framework 4.7 no blog do .NET.

Classes de base

O .NET Framework 4.7 melhora a serialização através do DataContractJsonSerializer:

Funcionalidade melhorada com Criptografia de Curva Elíptica (ECC)*

No .NET Framework 4.7, ImportParameters(ECParameters) métodos foram adicionados às classes ECDsa e ECDiffieHellman para permitir que um objeto represente uma chave já estabelecida. Um método ExportParameters(Boolean) também foi adicionado para exportar a chave usando parâmetros de curva explícitos.

O .NET Framework 4.7 também adiciona suporte para curvas adicionais (incluindo o pacote de curvas Brainpool) e adicionou definições predefinidas para facilidade de criação por meio dos novos métodos de fábrica Create e Create.

Você pode ver um exemplo de melhorias de criptografia do .NET Framework 4.7 no GitHub.

Melhor suporte para caracteres de controle pelo DataContractJsonSerializer

No .NET Framework 4.7, a classe DataContractJsonSerializer serializa caracteres de controle em conformidade com o padrão ECMAScript 6. Esse comportamento é habilitado por padrão para aplicativos destinados ao .NET Framework 4.7 e é um recurso de aceitação para aplicativos que estão sendo executados no .NET Framework 4.7, mas visam uma versão anterior do .NET Framework. Para obter mais informações, consulte a seção compatibilidade de aplicações.

Ligação em rede

O .NET Framework 4.7 adiciona o seguinte recurso relacionado à rede:

Suporte padrão do sistema operacional para protocolos TLS*

A pilha TLS, que é usada pelos componentes System.Net.Security.SslStream e por componentes de camadas superiores, como HTTP, FTP e SMTP, permite que os desenvolvedores usem os protocolos TLS padrão suportados pelo sistema operativo. Os desenvolvedores não precisam mais codificar uma versão TLS.

ASP.NET

No .NET Framework 4.7, ASP.NET inclui os seguintes novos recursos:

Extensibilidade de Cache de Objetos

A partir do .NET Framework 4.7, o ASP.NET adiciona um novo conjunto de APIs que permitem que os desenvolvedores substituam as implementações de ASP.NET padrão para cache de objetos na memória e monitoramento de memória. Os desenvolvedores agora podem substituir qualquer um dos três componentes a seguir se a implementação ASP.NET não for adequada:

  • Armazenamento em cache de objetos. Ao usar a nova seção de configuração dos provedores de cache, os desenvolvedores podem conectar novas implementações de um cache de objetos para uma aplicação ASP.NET, utilizando a interface de ICacheStoreProvider.

  • Monitoramento de memória. O monitor de memória padrão no ASP.NET notifica os aplicativos quando eles estão sendo executados perto do limite de bytes privados configurado para o processo ou quando a máquina está com pouca RAM física disponível total. Quando esses limites estão próximos, as notificações são enviadas. Para alguns aplicativos, as notificações são disparadas muito perto dos limites configurados para permitir reações úteis. Os desenvolvedores agora podem escrever seus próprios monitores de memória para substituir o padrão usando a propriedade ApplicationMonitors.MemoryMonitor.

  • Reações de limite de memória. Por padrão, o ASP.NET tenta otimizar o cache de objetos e invocar periodicamente GC.Collect quando o limite de bytes privados do processo está próximo. Para alguns aplicativos, a frequência de chamadas para GC.Collect ou a quantidade de cache cortada são ineficientes. Os desenvolvedores agora podem substituir ou complementar o comportamento padrão inscrevendo implementações de IObserver no monitor de memória do aplicativo.

Windows Communication Foundation (WCF)

O Windows Communication Foundation (WCF) adiciona os seguintes recursos e alterações:

Capacidade de configurar as configurações de segurança de mensagem padrão para TLS 1.1 ou TLS 1.2

A partir do .NET Framework 4.7, o WCF permite configurar o TLS 1.1 ou TLS 1.2, além do SSL 3.0 e TLS 1.0 como o protocolo de segurança de mensagem padrão. Esta é uma configuração de aceitação; Para habilitá-lo, você deve adicionar a seguinte entrada ao arquivo de configuração do aplicativo:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>

Confiabilidade melhorada de aplicativos e serialização WCF

O WCF inclui uma série de alterações de código que eliminam as condições de corrida, melhorando assim o desempenho e a confiabilidade das opções de serialização. Estes incluem:

  • Melhor suporte para misturar código assíncrono e síncrono em chamadas para SocketConnection.BeginRead e SocketConnection.Read.
  • Maior confiabilidade ao abortar uma conexão com SharedConnectionListener e DuplexChannelBinder.
  • Maior confiabilidade das operações de serialização ao chamar o método FormatterServices.GetSerializableMembers(Type).
  • Maior confiabilidade ao remover um garçom chamando o ChannelSynchronizer.RemoveWaiter método.

Formulários do Windows

No .NET Framework 4.7, o Windows Forms melhora o suporte para monitores de alto DPI.

Suporte de alto DPI

Começando com aplicativos destinados ao .NET Framework 4.7, o .NET Framework apresenta alto DPI e suporte a DPI dinâmico para aplicativos Windows Forms. O suporte a DPI alto melhora o layout e a aparência de formulários e controles em monitores de alto DPI. O DPI dinâmico altera o layout e a aparência de formulários e controles quando o usuário altera o DPI ou o fator de escala de exibição de um aplicativo em execução.

O suporte a DPI alto é um recurso de aceitação que você configura definindo uma seção <System.Windows.Forms.ConfigurationSection> no arquivo de configuração do aplicativo. Para obter mais informações sobre como adicionar suporte a DPI alto e suporte a DPI dinâmico ao seu aplicativo Windows Forms, consulte Suporte a DPI alto no Windows Forms.

Windows Presentation Foundation (WPF)

No .NET Framework 4.7, o WPF inclui os seguintes aprimoramentos:

Suporte para uma pilha de toque/caneta baseada em mensagens WM_POINTER do Windows

Agora, tem a opção de utilizar uma tecnologia de toque/caneta baseada em mensagens WM_POINTER em vez da Plataforma de Serviços de Tinta do Windows (WISP). Este é um recurso de aceitação no .NET Framework. Para obter mais informações, consulte a seção de compatibilidade de aplicativos.

Nova implementação para APIs de impressão WPF

As APIs de impressão do WPF na classe System.Printing.PrintQueue chamam a API do Pacote de Documentos de Impressão do Windows em vez da API de Impressão XPS do preterida. Para obter o impacto dessa alteração na compatibilidade de aplicativos, consulte a seção de compatibilidade de aplicativos.

O que há de novo no .NET Framework 4.6.2

O .NET Framework 4.6.2 inclui novos recursos nas seguintes áreas:

Para obter uma lista de novas APIs adicionadas ao .NET Framework 4.6.2, consulte de alterações de API do .NET Framework 4.6.2 no GitHub. Para obter uma lista de melhorias de recursos e correções de bugs no .NET Framework 4.6.2, consulte Lista de alterações do .NET Framework 4.6.2 no GitHub. Para obter mais informações, consulte Anunciando o do .NET Framework 4.6.2 no blog do .NET.

ASP.NET

No .NET Framework 4.6.2, ASP.NET inclui os seguintes aprimoramentos:

Suporte melhorado para mensagens de erro localizadas em validadores de anotação de dados

Os validadores de anotação de dados permitem que você execute a validação adicionando um ou mais atributos a uma propriedade de classe. O elemento ValidationAttribute.ErrorMessage do atributo define o texto da mensagem de erro se a validação falhar. A partir do .NET Framework 4.6.2, ASP.NET facilita a localização de mensagens de erro. As mensagens de erro serão localizadas se:

  1. O ValidationAttribute.ErrorMessage é fornecido no atributo de validação.

  2. O arquivo de recurso é armazenado na pasta App_LocalResources.

  3. O nome do arquivo de recursos localizados tem a forma DataAnnotation.Localization.{nome}.resx, onde nome é um nome de cultura no formato languageCode-país/regiãoCode ou languageCode.

  4. O nome da chave do recurso é a cadeia de caracteres atribuída ao atributo ValidationAttribute.ErrorMessage e seu valor é a mensagem de erro localizada.

Por exemplo, o seguinte atributo de anotação de dados define a mensagem de erro da cultura padrão para uma classificação inválida.

public class RatingInfo
{
   [Required(ErrorMessage = "The rating must be between 1 and 10.")]
   [Display(Name = "Your Rating")]
   public int Rating { get; set; }
}

Public Class RatingInfo
   <Required(ErrorMessage = "The rating must be between 1 and 10.")>
   <Display(Name = "Your Rating")>
   Public Property Rating As Integer = 1
End Class

Em seguida, você pode criar um arquivo de recurso, DataAnnotation.Localization.fr.resx, cuja chave é a cadeia de caracteres da mensagem de erro e cujo valor é a mensagem de erro localizada. O arquivo deve ser encontrado na pasta App.LocalResources. Por exemplo, a seguir está a chave e o seu valor em uma mensagem de erro localizada em francês (fr):

Nome Valor
A classificação deve estar entre 1 e 10. La note doit être comprise entre 1 et 10.

Além disso, a localização da anotação de dados é extensível. Os desenvolvedores podem integrar os seus próprios fornecedores de localizadores de strings, implementando a interface IStringLocalizerProvider para armazenar strings de localização num local diferente de um ficheiro de recursos.

Suporte assíncrono com provedores de armazenamento de estado de sessão

ASP.NET agora permite que métodos de retorno de tarefas sejam usados com provedores de armazenamento de estado de sessão, permitindo assim que aplicativos ASP.NET obtenham os benefícios de escalabilidade do async. Para oferecer suporte a operações assíncronas com provedores de armazenamento de estado de sessão, ASP.NET inclui uma nova interface, System.Web.SessionState.ISessionStateModule, que herda de IHttpModule e permite que os desenvolvedores implementem seus próprios provedores de armazenamento de sessão e armazenamento de sessão assíncrono. A interface é definida da seguinte forma:

public interface ISessionStateModule : IHttpModule {
    void ReleaseSessionState(HttpContext context);
    Task ReleaseSessionStateAsync(HttpContext context);
}

Public Interface ISessionStateModule : Inherits IHttpModule
   Sub ReleaseSessionState(context As HttpContext)
   Function ReleaseSessionStateAsync(context As HttpContext) As Task
End Interface

Além disso, a classe SessionStateUtility inclui dois novos métodos, IsSessionStateReadOnly e IsSessionStateRequired, que podem ser usados para dar suporte a operações assíncronas.

Suporte assíncrono para provedores de cache de saída

A partir do .NET Framework 4.6.2, os métodos de retorno de tarefas podem ser usados com provedores de cache de saída para fornecer os benefícios de escalabilidade do assíncrono. Os provedores que implementam esses métodos reduzem o bloqueio de threads em um servidor Web e melhoram a escalabilidade de um serviço ASP.NET.

As seguintes APIs foram adicionadas para oferecer suporte a provedores assíncronos de cache de saída:

Categorias de personagens

Os caracteres no .NET Framework 4.6.2 são classificados com base no Unicode Standard, Versão 8.0.0. No .NET Framework 4.6 e no .NET Framework 4.6.1, os caracteres foram classificados com base nas categorias de caracteres Unicode 6.3.

O suporte para Unicode 8.0 é limitado à classificação de caracteres pela classe CharUnicodeInfo e aos tipos e métodos que dependem dele. Eles incluem a classe StringInfo, o método Char.GetUnicodeCategory sobrecarregado e as classes de caracteres reconhecidas pelo mecanismo de expressão regular do .NET Framework. A comparação e a classificação de caracteres e cadeias de caracteres não são afetadas por essa alteração e continuam a depender do sistema operacional subjacente ou, em sistemas Windows 7, dos dados de caracteres fornecidos pelo .NET Framework.

Para alterações nas categorias de caracteres de Unicode 6.0 para Unicode 7.0, consulte The Unicode Standard, Version 7.0.0 no site do Unicode Consortium. Para ver as alterações do Unicode 7.0 para o Unicode 8.0, consulte O Padrão Unicode, Versão 8.0.0 no site do Consórcio Unicode.

Criptografia

Suporte para certificados X509 contendo FIPS 186-3 DSA

O .NET Framework 4.6.2 adiciona suporte para certificados DSA (Digital Signature Algorithm) X509 cujas chaves excedem o limite FIPS 186-2 de 1024 bits.

Além de suportar os tamanhos de chave maiores do FIPS 186-3, o .NET Framework 4.6.2 permite assinaturas de computação com a família SHA-2 de algoritmos de hash (SHA256, SHA384 e SHA512). O suporte a FIPS 186-3 é fornecido pela nova classe System.Security.Cryptography.DSACng.

De acordo com as alterações recentes na classe RSA no .NET Framework 4.6 e na classe ECDsa no .NET Framework 4.6.1, a classe base abstrata DSA no .NET Framework 4.6.2 tem métodos adicionais para permitir que os utilizadores utilizem esta funcionalidade sem necessidade de casting. Você pode chamar o método de extensão DSACertificateExtensions.GetDSAPrivateKey para assinar dados, como mostra o exemplo a seguir.

public static byte[] SignDataDsaSha384(byte[] data, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPrivateKey())
    {
        return dsa.SignData(data, HashAlgorithmName.SHA384);
    }
}

Public Shared Function SignDataDsaSha384(data As Byte(), cert As X509Certificate2) As Byte()
    Using DSA As DSA = cert.GetDSAPrivateKey()
        Return DSA.SignData(data, HashAlgorithmName.SHA384)
    End Using
End Function

E você pode chamar o método de extensão DSACertificateExtensions.GetDSAPublicKey para verificar dados assinados, como mostra o exemplo a seguir.

public static bool VerifyDataDsaSha384(byte[] data, byte[] signature, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPublicKey())
    {
        return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384);
    }
}

 Public Shared Function VerifyDataDsaSha384(data As Byte(), signature As Byte(), cert As X509Certificate2) As Boolean
    Using dsa As DSA = cert.GetDSAPublicKey()
        Return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384)
    End Using
End Function

Maior clareza para entradas em rotinas de derivação de chaves ECDiffieHellman

.NET Framework 3.5 adicionou suporte para Acordo de Chave de Curva Elíptica Diffie-Hellman com três rotinas diferentes de Função de Derivação de Chave (KDF). As entradas para as rotinas, e as próprias rotinas, foram configuradas através de propriedades no objeto ECDiffieHellmanCng. Mas como nem todas as rotinas leem todas as propriedades de entrada, havia amplo espaço para confusão sobre o passado do desenvolvedor.

Para resolver isso no .NET Framework 4.6.2, os três métodos a seguir foram adicionados à classe base ECDiffieHellman para representar mais claramente essas rotinas KDF e suas entradas:

Método ECDiffieHellman Descrição
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) Deriva o material chave usando a fórmula

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

onde x é o resultado calculado do algoritmo EC Diffie-Hellman.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) Deriva o material chave usando a fórmula

HMAC(hmacKey, secretPrepend || x || secretAppend)

HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend)

onde x é o resultado calculado do algoritmo EC Diffie-Hellman.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) Deriva material chave usando o algoritmo de derivação de função pseudoaleatória (PRF) TLS.

Suporte para criptografia simétrica de chave persistente

A biblioteca de criptografia do Windows (CNG) adicionou suporte para armazenar chaves simétricas persistentes e usar chaves simétricas armazenadas em hardware, e o .NET Framework 4.6.2 tornou possível para os desenvolvedores fazer uso desse recurso. Como a noção de nomes-chave e provedores-chave é específica da implementação, o uso desse recurso requer a utilização do construtor dos tipos de implementação concretos em vez da abordagem de fábrica preferida (como chamar Aes.Create).

Existe suporte para encriptação simétrica de chave persistente para os algoritmos AES (AesCng) e 3DES (TripleDESCng). Por exemplo:

public static byte[] EncryptDataWithPersistedKey(byte[] data, byte[] iv)
{
    using (Aes aes = new AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider))
    {
        aes.IV = iv;

        // Using the zero-argument overload is required to make use of the persisted key
        using (ICryptoTransform encryptor = aes.CreateEncryptor())
        {
            if (!encryptor.CanTransformMultipleBlocks)
            {
                throw new InvalidOperationException("This is a sample, this case wasn't handled...");
            }

            return encryptor.TransformFinalBlock(data, 0, data.Length);
        }
    }
}

Public Shared Function EncryptDataWithPersistedKey(data As Byte(), iv As Byte()) As Byte()
    Using Aes As Aes = New AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider)
        Aes.IV = iv

        ' Using the zero-argument overload Is required to make use of the persisted key
        Using encryptor As ICryptoTransform = Aes.CreateEncryptor()
            If Not encryptor.CanTransformMultipleBlocks Then
                Throw New InvalidOperationException("This is a sample, this case wasn't handled...")
            End If
            Return encryptor.TransformFinalBlock(data, 0, data.Length)
        End Using
    End Using
End Function

Suporte de SignedXml para hashing SHA-2

O .NET Framework 4.6.2 adiciona suporte à classe SignedXml para métodos de assinatura RSA-SHA256, RSA-SHA384 e RSA-SHA512 PKCS#1 e algoritmos de resumo de referência SHA256, SHA384 e SHA512.

As constantes de URI são todas expostas em SignedXml:

Campo SignedXml Constante
XmlDsigSHA256Url "http://www.w3.org/2001/04/xmlenc#sha256"
XmlDsigRSASHA256Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
XmlDsigSHA384Url "http://www.w3.org/2001/04/xmldsig-more#sha384"
XmlDsigRSASHA384Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"
XmlDsigSHA512Url "http://www.w3.org/2001/04/xmlenc#sha512"
XmlDsigRSASHA512Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"

Todos os programas que registraram um manipulador de SignatureDescription personalizado no CryptoConfig para adicionar suporte a esses algoritmos continuarão a funcionar como no passado, mas como agora há padrões de plataforma, o registro CryptoConfig não é mais necessário.

SqlClient

O Provedor de Dados do .NET Framework para SQL Server (System.Data.SqlClient) inclui os seguintes novos recursos no .NET Framework 4.6.2:

Pool de conexões e tempos limite com bancos de dados SQL do Azure

Quando o pool de conexões é habilitado e ocorre um tempo limite ou outro erro de login, uma exceção é armazenada em cache e a exceção armazenada em cache é lançada em qualquer tentativa de conexão subsequente pelos próximos 5 segundos a 1 minuto. Para obter mais informações, consulte Pool de conexões do SQL Server (ADO.NET).

Esse comportamento não é desejável ao se conectar aos Bancos de Dados SQL do Azure, pois as tentativas de conexão podem falhar com erros transitórios que normalmente são recuperados rapidamente. Para otimizar melhor a experiência de repetição de conexão, o comportamento do período de bloqueio do pool de conexões é removido quando as conexões com os Bancos de Dados SQL do Azure falham.

A adição da nova palavra-chave PoolBlockingPeriod permite selecionar o período de bloqueio mais adequado para o seu aplicativo. Os valores incluem:

Auto

O período de bloqueio do pool de conexões para um aplicativo que se conecta a um Banco de Dados SQL do Azure está desabilitado e o período de bloqueio do pool de conexões para um aplicativo que se conecta a qualquer outra instância do SQL Server está habilitado. Este é o valor padrão. Se o nome do ponto de extremidade do Servidor terminar com qualquer um dos seguintes, eles serão considerados Bancos de Dados SQL do Azure:

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

O período de bloqueio do pool de conexões está sempre ativado.

NeverBlock

O período de bloqueio do pool de conexões é sempre desativado.

Aprimoramentos para Always Encrypted

SQLClient introduz dois aprimoramentos para Always Encrypted:

  • Para melhorar o desempenho de consultas parametrizadas em colunas de banco de dados criptografadas, os metadados de criptografia para parâmetros de consulta agora são armazenados em cache. Com a propriedade SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled definida como true (que é o valor padrão), se a mesma consulta for chamada várias vezes, o cliente recuperará metadados de parâmetro do servidor apenas uma vez.

  • As entradas de chave de criptografia de coluna no cache de chaves agora são removidas após um intervalo de tempo configurável, definido usando a propriedade SqlConnection.ColumnEncryptionKeyCacheTtl.

Windows Communication Foundation

No .NET Framework 4.6.2, o Windows Communication Foundation foi aprimorado nas seguintes áreas:

Suporte à segurança de transporte WCF para certificados armazenados usando CNG

A segurança de transporte do WCF oferece suporte a certificados armazenados usando a biblioteca de criptografia do Windows (CNG). No .NET Framework 4.6.2, esse suporte é limitado ao uso de 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.

Para aplicativos destinados ao .NET Framework 4.6.1 e anteriores, mas que estão sendo executados no .NET Framework 4.6.2, esse recurso pode ser habilitado adicionando a seguinte linha à seção de tempo de execução do arquivo app.config ou web.config.

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

Isso também pode ser feito programaticamente com código como o seguinte:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificates";
AppContext.SetSwitch(disableCngCertificates, false);

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

Melhor suporte para várias regras de ajuste de horário de verão pela classe DataContractJsonSerializer

Os clientes podem usar uma definição de configuração do aplicativo para determinar se a classe DataContractJsonSerializer oferece suporte a várias regras de ajuste para um único fuso horário. Este é um recurso de adesão. Para habilitá-lo, adicione a seguinte configuração ao seu arquivo app.config:

<runtime>
     <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" />
</runtime>

Quando esse recurso está habilitado, um objeto DataContractJsonSerializer usa o tipo TimeZoneInfo em vez do tipo TimeZone para desserializar dados de data e hora. TimeZoneInfo suporta várias regras de ajuste, o que torna possível trabalhar com dados históricos de fuso horário; TimeZone não.

Para obter mais informações sobre a estrutura do TimeZoneInfo e os ajustes de fuso horário, consulte Visão geral do fuso horário .

Compatibilidade ideal para NetNamedPipeBinding

O WCF tem uma nova definição de aplicação que pode ser configurada em aplicativos cliente para garantir que eles estejam sempre conectados ao serviço a ouvir no URI que melhor corresponde ao solicitado. Com essa configuração de aplicativo definida como false (o padrão), é possível que os clientes que usam NetNamedPipeBinding tentem se conectar a um serviço escutando em um URI que é uma substring do URI solicitado.

Por exemplo, um cliente tenta conectar-se a um serviço que escuta em net.pipe://localhost/Service1, mas um serviço diferente nessa máquina que está a correr com privilégios de administrador está a escutar em net.pipe://localhost. Com essa configuração de aplicativo definida como false, o cliente tentaria se conectar ao serviço errado. Depois de definir a configuração da aplicação como true, o cliente conectará sempre ao serviço mais adequado.

Observação

Os clientes que usam NetNamedPipeBinding encontram serviços com base no endereço base do serviço (se ele existir) em vez do endereço completo do endpoint. Para garantir que essa configuração sempre funcione, o serviço deve usar um endereço base exclusivo.

Para habilitar essa alteração, adicione a seguinte configuração de aplicativo ao arquivo App.config ou Web.config do aplicativo cliente:

<configuration>
    <appSettings>
        <add key="wcf:useBestMatchNamedPipeUri" value="true" />
    </appSettings>
</configuration>

SSL 3.0 não é um protocolo padrão

Ao usar NetTcp com segurança de transporte e um tipo de credencial de certificado, o SSL 3.0 não é mais um protocolo padrão usado para negociar uma conexão segura. Na maioria dos casos, não deve haver impacto nos aplicativos existentes, porque o TLS 1.0 está incluído na lista de protocolos para NetTcp. Todos os clientes existentes devem ser capazes de negociar uma conexão usando pelo menos TLS 1.0. Se Ssl3 for necessário, use um dos seguintes mecanismos de configuração para adicioná-lo à lista de protocolos negociados.

Windows Presentation Foundation (WPF)

No .NET Framework 4.6.2, o Windows Presentation Foundation foi aprimorado nas seguintes áreas:

Classificação de grupo

Um aplicativo que usa um objeto CollectionView para agrupar dados agora pode declarar explicitamente como classificar os grupos. A classificação explícita resolve o problema da ordenação não intuitiva que ocorre quando um aplicativo adiciona ou remove grupos dinamicamente ou quando altera o valor das propriedades do item envolvidas no agrupamento. Ele também pode melhorar o desempenho do processo de criação de grupo movendo comparações das propriedades de agrupamento do tipo da coleção completa para o tipo dos grupos.

Para dar suporte à classificação de grupos, as novas propriedades GroupDescription.SortDescriptions e GroupDescription.CustomSort descrevem como classificar a coleção de grupos produzidos pelo objeto GroupDescription. Isso é análogo à maneira como as propriedades ListCollectionView nomeadas de forma idêntica descrevem como classificar os itens de dados.

Duas novas propriedades estáticas da classe PropertyGroupDescription, CompareNameAscending e CompareNameDescending, podem ser usadas para os casos mais comuns.

Por exemplo, o XAML a seguir agrupa dados por idade, classifica as faixas etárias em ordem crescente e agrupa os itens dentro de cada faixa etária por sobrenome.

<GroupDescriptions>
     <PropertyGroupDescription
         PropertyName="Age"
         CustomSort=
              "{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
     </PropertyGroupDescription>
</GroupDescriptions>

<SortDescriptions>
     <SortDescription PropertyName="LastName"/>
</SortDescriptions>

Suporte de teclado tátil

O suporte ao teclado virtual permite o rastreamento de foco em aplicativos WPF, invocando e descartando automaticamente o teclado virtual no Windows 10 quando a entrada por toque é recebida por um controle que pode receber entrada textual.

Em versões anteriores do .NET Framework, os aplicativos WPF não podem aceitar o rastreamento de foco sem desabilitar o suporte a gestos de caneta/toque WPF. Como resultado, as aplicações WPF devem escolher entre o suporte total ao toque do WPF ou contar com a promoção do rato do Windows.

DPI por monitor

Para suportar a recente proliferação de ambientes de DPI alto e DPI híbrido para aplicativos WPF, o WPF no .NET Framework 4.6.2 permite o reconhecimento por monitor. Consulte os exemplos de e o guia do desenvolvedor no GitHub para obter mais informações sobre como habilitar seu aplicativo WPF para obter reconhecimento de DPI por monitor.

Em versões anteriores do .NET Framework, os aplicativos WPF reconhecem DPI do sistema. Em outras palavras, a interface do usuário do aplicativo é dimensionada pelo sistema operacional conforme apropriado, dependendo do DPI do monitor no qual o aplicativo é renderizado.

Para aplicações executadas no .NET Framework 4.6.2, pode desativar as alterações de DPI por monitor em aplicações WPF, adicionando uma instrução de configuração à secção de runtime <> do ficheiro de configuração da aplicação, da seguinte maneira:

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

Windows Workflow Foundation (WF)

No .NET Framework 4.6.2, o Windows Workflow Foundation foi aprimorado na seguinte área:

Suporte para expressões C# e IntelliSense no Rehosted WF Designer

A partir do .NET Framework 4.5, o WF oferece suporte a expressões C# no Visual Studio Designer e em fluxos de trabalho de código. O Designer de Fluxo de Trabalho Rehospedado é um recurso chave do WF que permite que o Designer de Fluxo de Trabalho esteja em um aplicativo fora do Visual Studio (por exemplo, no WPF). O Windows Workflow Foundation oferece a capacidade de oferecer suporte a expressões C# e IntelliSense no Designer de Fluxo de Trabalho Rehospedado. Para obter mais informações, consulte o blog Windows Workflow Foundation.

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio Em versões do .NET Framework anteriores à 4.6.2, o WF Designer IntelliSense é interrompido quando um cliente recria um projeto de fluxo de trabalho do Visual Studio. Embora a compilação do projeto seja bem-sucedida, os tipos de fluxo de trabalho não são encontrados no designer, e avisos do IntelliSense sobre os tipos de fluxo de trabalho ausentes aparecem na janela Lista de Erros do . O .NET Framework 4.6.2 resolve esse problema e disponibiliza o IntelliSense.

aplicativos Workflow V1 com o Workflow Tracking agora são executados no modo FIPS

As máquinas com o Modo de Conformidade FIPS ativado agora podem executar com êxito um aplicativo de fluxo de trabalho no estilo Versão 1 com o acompanhamento do fluxo de trabalho ativado. Para habilitar esse cenário, você deve fazer a seguinte alteração no arquivo app.config:

<add key="microsoft:WorkflowRuntime:FIPSRequired" value="true" />

Se esse cenário não estiver habilitado, a execução do aplicativo continuará a gerar uma exceção com a mensagem "Esta implementação não faz parte dos algoritmos criptográficos validados FIPS da Plataforma Windows".

Melhorias no Fluxo de Trabalho ao Usar a Atualização Dinâmica com o Visual Studio Workflow Designer

O Designer de Fluxo de Trabalho, o Designer de Atividade de Fluxograma e outros Designers de Atividade de Fluxo de Trabalho agora carregam e exibem com êxito fluxos de trabalho que foram salvos depois de chamar o método DynamicUpdateServices.PrepareForUpdate. Em versões do .NET Framework anteriores ao .NET Framework 4.6.2, carregar um arquivo XAML no Visual Studio para um fluxo de trabalho que foi salvo após chamar DynamicUpdateServices.PrepareForUpdate pode resultar nos seguintes problemas:

  • O Designer de Fluxo de Trabalho não pode carregar o arquivo XAML corretamente (quando o ViewStateData.Id está no final da linha).

  • O Designer de Atividade de Fluxograma ou outros Designers de Atividade de Fluxo de Trabalho podem exibir todos os objetos em seus locais padrão, em oposição aos valores das propriedades anexadas.

ClickOnce

ClickOnce foi atualizado para suportar TLS 1.1 e TLS 1.2, além do protocolo 1.0, que já suporta. ClickOnce deteta automaticamente qual protocolo é necessário; nenhuma etapa extra dentro do aplicativo ClickOnce é necessária para habilitar o suporte a TLS 1.1 e 1.2.

Convertendo aplicativos Windows Forms e WPF em aplicativos UWP

O Windows agora oferece recursos para trazer aplicativos de área de trabalho existentes do Windows, incluindo aplicativos WPF e Windows Forms, para a Plataforma Universal do Windows (UWP). Essa tecnologia atua como uma ponte, permitindo que você migre gradualmente sua base de código existente para a UWP, levando seu aplicativo a todos os dispositivos Windows 10.

Os aplicativos de área de trabalho convertidos ganham uma identidade de aplicativo semelhante à identidade de aplicativo de aplicativos UWP, o que torna as APIs UWP acessíveis para habilitar recursos como Live Tiles e notificações. O aplicativo continua a se comportar como antes e é executado como um aplicativo de confiança total. Depois que o aplicativo é convertido, um processo de contêiner de aplicativo pode ser adicionado ao processo de confiança total existente para adicionar uma interface de usuário adaptável. Quando todas as funcionalidades são movidas para o processo de contêiner de aplicativo, o processo de confiança total pode ser removido e o novo aplicativo UWP pode ser disponibilizado para todos os dispositivos Windows 10.

Melhorias na depuração

O API de depuração não gerido, , foi melhorado no .NET Framework 4.6.2 para realizar análises adicionais sempre que um NullReferenceException ocorre, de modo a tornar possível determinar qual variável numa única linha de código-fonte é null. Para dar suporte a esse cenário, as APIs a seguir foram adicionadas à API de depuração não gerenciada.

O que há de novo no .NET Framework 4.6.1

O .NET Framework 4.6.1 inclui novos recursos nas seguintes áreas:

Para obter mais informações sobre o .NET Framework 4.6.1, consulte os seguintes tópicos:

Criptografia: Suporte para certificados X509 contendo ECDSA

O .NET Framework 4.6 adicionou suporte a RSACng para certificados X509. O .NET Framework 4.6.1 adiciona suporte para certificados ECDSA (Elliptic Curve Digital Signature Algorithm) X509.

O ECDSA oferece melhor desempenho e é um algoritmo de criptografia mais seguro do que o RSA, fornecendo uma excelente opção onde o desempenho e a escalabilidade do Transport Layer Security (TLS) são uma preocupação. A implementação do .NET Framework encapsula chamadas na funcionalidade existente do Windows.

O código de exemplo a seguir mostra como é fácil gerar uma assinatura para um fluxo de bytes usando o novo suporte para certificados ECDSA X509 incluídos no .NET Framework 4.6.1.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net461Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        using (ECDsa privateKey = cert.GetECDsaPrivateKey())
        {
            return privateKey.SignData(data, HashAlgorithmName.SHA512);
        }
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        return privateKey.SignData(data, HashAlgorithmName.SHA512);
    }
}

Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net461Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        Using privateKey As ECDsa = cert.GetECDsaPrivateKey()
            Return privateKey.SignData(data, HashAlgorithmName.SHA512)
        End Using
    End Function

    Public Shared Function SignECDsaSha512(data As Byte, privateKey As ECDsa) As Byte()
        Return privateKey.SignData(data, HashAlgorithmName.SHA512)
    End Function
End Class

Isso oferece um contraste acentuado com o código necessário para gerar uma assinatura no .NET Framework 4.6.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net46Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        // This would require using cert.Handle and a series of p/invokes to get at the
        // underlying key, then passing that to a CngKey object, and passing that to
        // new ECDsa(CngKey).  It's a lot of work.
        throw new Exception("That's a lot of work...");
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        // This way works, but SignData probably better matches what you want.
        using (SHA512 hasher = SHA512.Create())
        {
            byte[] signature1 = privateKey.SignHash(hasher.ComputeHash(data));
        }

        // This might not be the ECDsa you got!
        ECDsaCng ecDsaCng = (ECDsaCng)privateKey;
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512;
        return ecDsaCng.SignData(data);
    }
}

Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net46Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        ' This would require using cert.Handle and a series of p/invokes to get at the
        ' underlying key, then passing that to a CngKey object, and passing that to
        ' new ECDsa(CngKey).  It's a lot of work.
        Throw New Exception("That's a lot of work...")
    End Function

    Public Shared Function SignECDsaSha512(data As Byte(), privateKey As ECDsa) As Byte()
        ' This way works, but SignData probably better matches what you want.
        Using hasher As SHA512 = SHA512.Create()
            Dim signature1 As Byte() = privateKey.SignHash(hasher.ComputeHash(data))
        End Using

        ' This might not be the ECDsa you got!
        Dim ecDsaCng As ECDsaCng = CType(privateKey, ECDsaCng)
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512
        Return ecDsaCng.SignData(data)
    End Function
End Class

ADO.NET

Ao ADO.NET foi aditado o seguinte:

Suporte Always Encrypted para chaves protegidas por hardware

ADO.NET agora suporta nativamente o armazenamento de chaves mestras de coluna Always Encrypted em Módulos de Segurança de Hardware (HSMs). Com esse suporte, os clientes podem aproveitar chaves assimétricas armazenadas em HSMs sem precisar escrever provedores de armazenamento de chaves mestras de coluna personalizadas e registrá-los em aplicativos.

Os clientes precisam instalar o provedor CSP fornecido pelo fornecedor do HSM ou os provedores de armazenamento de chaves CNG nos servidores de aplicativos ou computadores clientes para acessar dados Always Encrypted protegidos com chaves mestras de coluna armazenadas em um HSM.

Comportamento de conexão de MultiSubnetFailover aprimorado para o AlwaysOn

SqlClient agora fornece automaticamente conexões mais rápidas para um Grupo de Disponibilidade AlwaysOn (AG). Ele deteta de forma transparente se seu aplicativo está se conectando a um grupo de disponibilidade (AG) AlwaysOn em uma sub-rede diferente, descobre rapidamente o servidor ativo atual e fornece uma conexão com o servidor. Antes desta versão, um aplicativo tinha que definir a cadeia de conexão para incluir "MultisubnetFailover=true" para indicar que estava se conectando a um Grupo de Disponibilidade AlwaysOn. Sem definir a palavra-chave de conexão como true, um aplicativo pode enfrentar um timeout ao conectar-se a um grupo de disponibilidade AlwaysOn. Com esta versão, um aplicativo não precisa mais definir MultiSubnetFailover para true. Para obter mais informações sobre o suporte do SqlClient para Grupos de Disponibilidade Always On, consulte Suporte do SqlClient para Alta Disponibilidade, Recuperação de Desastres.

Windows Presentation Foundation (WPF)

O Windows Presentation Foundation inclui uma série de melhorias e alterações.

Melhor desempenho

O atraso no disparo de eventos de toque foi corrigido no .NET Framework 4.6.1. Além disso, digitar um controle de RichTextBox não amarra mais o thread de renderização durante a entrada rápida.

Melhorias na verificação ortográfica

O verificador ortográfico no WPF foi atualizado no Windows 8.1 e versões posteriores para aproveitar o suporte do sistema operacional para verificação ortográfica de idiomas adicionais. Não há nenhuma alteração na funcionalidade em versões do Windows anteriores ao Windows 8.1.

Como nas versões anteriores do .NET Framework, a linguagem para um controle de TextBox ou um bloco de RichTextBox é detetada procurando informações na seguinte ordem:

  • xml:lang, se estiver presente.

  • Idioma de entrada atual.

  • Cultura atual.

Para obter mais informações sobre suporte a idiomas no WPF, consulte a postagem do blog WPF sobre os recursos do .NET Framework 4.6.1.

Suporte adicional para dicionários personalizados por usuário

No .NET Framework 4.6.1, o WPF reconhece dicionários personalizados que são registrados globalmente. Este recurso está disponível, além da capacidade de os registar por cada controlo.

Em versões anteriores do WPF, os dicionários personalizados não reconheciam palavras excluídas e listas de AutoCorreção. Eles são suportados no Windows 8.1 e Windows 10 através do uso de arquivos que podem ser colocados sob o diretório %AppData%\Microsoft\Spelling\<language tag>. As seguintes regras aplicam-se a estes ficheiros:

  • Os arquivos devem ter extensões de .dic (para palavras adicionadas), .exc (para palavras excluídas) ou .acl (para AutoCorreção).

  • Os ficheiros devem ser texto simples UTF-16 LE que começa com a Marca de Ordem de Bytes (BOM).

  • Cada linha deve consistir em uma única palavra (nas listas de palavras adicionadas e excluídas), ou um par de correção automática com as palavras separadas por uma barra vertical (‘|’) (na lista de palavras de Correção Automática).

  • Esses arquivos são considerados somente leitura e não são modificados pelo sistema.

Observação

Esses novos formatos de arquivo não são suportados diretamente pelas APIs de verificação ortográfica do WPF, e os dicionários personalizados fornecidos ao WPF em aplicativos devem continuar a usar arquivos .lex.

Amostras

Há vários exemplos de WPF no repositório Microsoft/WPF-Samples GitHub. Ajude-nos a melhorar nossas amostras enviando-nos um pull-request ou abrindo um problema GitHub.

extensões DirectX

O WPF inclui um pacote NuGet que fornece novas implementações de D3DImage que facilitam a interoperação com conteúdo DX10 e Dx11. O código para este pacote foi de código aberto e está disponível no GitHub.

Windows Workflow Foundation: Transações

O método Transaction.EnlistPromotableSinglePhase agora pode usar um gerenciador de transações distribuído diferente do MSDTC para promover a transação. Para fazer isso, especifique um identificador de promotor de transação GUID nesta nova sobrecarga Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid). Se essa operação for bem-sucedida, há limitações colocadas nos recursos da transação. Uma vez alistado um coordenador de transação não-MSDTC, os seguintes métodos geram um TransactionPromotionException porque requerem promoção para MSDTC.

Uma vez que um promotor de transação não-MSDTC é inscrito, ele deve ser utilizado para alistamentos duráveis futuros utilizando protocolos que ele define. O Guid do promotor da transação pode ser obtido utilizando a propriedade PromoterType. Quando a transação é promovida, o promotor da transação fornece uma matriz Byte que representa o token promovido. Uma aplicação pode obter o token promovido para uma transação promovida que não seja MSDTC com o método GetPromotedToken.

Os utilizadores da nova sobrecarga Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) devem seguir uma sequência específica de chamadas para que a operação de promoção seja concluída com êxito. Essas regras estão documentadas na documentação do método.

Perfilagem

A API de criação de perfil não gerenciada foi aprimorada da seguinte maneira:

  • Melhor suporte para acessar PDBs no ICorProfilerInfo7 interface.

    Em ASP.NET Core, está se tornando muito mais comum que as montagens sejam compiladas na memória por Roslyn. Para desenvolvedores que criam ferramentas de criação de perfil, isso significa que PDBs que historicamente eram serializados em disco podem não estar mais presentes. As ferramentas do Profiler geralmente usam PDBs para mapear o código de volta às linhas de origem para tarefas como cobertura de código ou análise de desempenho linha por linha. O ICorProfilerInfo7 interface agora inclui dois novos métodos, ICorProfilerInfo7::GetInMemorySymbolsLength e ICorProfilerInfo7::ReadInMemorySymbols, para fornecer a essas ferramentas de criação de perfil acesso aos dados PDB na memória, Usando as novas APIs, um criador de perfil pode obter o conteúdo de um PDB na memória como uma matriz de bytes e, em seguida, processá-lo ou serializá-lo para o disco.

  • Melhor instrumentação com a interface ICorProfiler.

    Os perfiladores que estão usando a funcionalidade ReJit das APIs ICorProfiler para instrumentação dinâmica agora podem modificar alguns metadados. Anteriormente, essas ferramentas podiam instrumentar IL a qualquer momento, mas os metadados só podiam ser modificados no tempo de carregamento do módulo. Como a IL se refere a metadados, isso limitou os tipos de instrumentação que poderiam ser feitos. Eliminamos alguns desses limites adicionando o método ICorProfilerInfo7::ApplyMetaData para dar suporte a um subconjunto de edições de metadados após o carregamento do módulo, em particular adicionando novos registros de AssemblyRef, TypeRef, TypeSpec, MemberRef, MemberSpece UserString. Essa mudança possibilita uma gama muito mais ampla de instrumentação em tempo real.

PDBs do Gerador de Imagem Nativa (NGEN)

O rastreamento de eventos entre máquinas permite que os clientes criem o perfil de um programa na Máquina A e examinem os dados de criação de perfil com o mapeamento da linha de origem na Máquina B. Usando versões anteriores do .NET Framework, o usuário copiaria todos os módulos e imagens nativas da máquina perfilada para a máquina de análise que contém o PDB IL para criar o mapeamento de origem para nativo. Embora esse processo possa funcionar bem quando os arquivos são relativamente pequenos, como para aplicativos de telefone, os arquivos podem ser muito grandes em sistemas de desktop e exigem tempo significativo para copiar.

Com os PDBs do NGen, o NGen pode criar um PDB que inclui o mapeamento de IL para nativo sem uma dependência do PDB IL. Em nosso cenário de rastreamento de eventos entre máquinas, tudo o que é necessário é copiar o PDB de imagem nativo gerado pela Máquina A para a Máquina B e usar APIs de Acesso à Interface de Depuração, para ler o mapeamento deto-IL de origem do PDB de IL e o mapeamento de IL para nativo do PDB de imagem nativa. A combinação dos dois mapeamentos fornece um mapeamento de origem a nativo. Como o PDB de imagem nativo é muito menor do que todos os módulos e imagens nativas, o processo de cópia da Máquina A para a Máquina B é muito mais rápido.

O que há de novo no .NET 2015

O .NET 2015 apresenta o .NET Framework 4.6 e o .NET Core. Alguns novos recursos se aplicam a ambos, e outros recursos são específicos do .NET Framework 4.6 ou .NET Core.

  • ASP.NET Core

    O .NET 2015 inclui o ASP.NET Core, que é uma implementação .NET enxuta para criar aplicativos modernos baseados em nuvem. ASP.NET Core é modular para que você possa incluir apenas os recursos necessários em seu aplicativo. Ele pode ser hospedado no IIS ou auto-hospedado em um processo personalizado, e você pode executar aplicativos com diferentes versões do .NET Framework no mesmo servidor. Ele inclui um novo sistema de configuração de ambiente projetado para implantação em nuvem.

    MVC, API da Web e páginas da Web são unificados em uma única estrutura chamada MVC 6. Você cria aplicativos ASP.NET Core por meio de ferramentas no Visual Studio 2015 ou posterior. Seus aplicativos existentes funcionarão no novo .NET Framework; no entanto, para criar um aplicativo que usa MVC 6 ou SignalR 3, você deve usar o sistema de projeto no Visual Studio 2015 ou posterior.

    Para obter informações, consulte ASP.NET Core.

  • Atualizações do ASP.NET

    • API baseada em tarefas para descarga assíncrona de resposta

      ASP.NET agora fornece uma API simples baseada em tarefas para liberação de resposta assíncrona, HttpResponse.FlushAsync, que permite que as respostas sejam liberadas de forma assíncrona usando o suporte de async/await do seu idioma.

    • Vinculação de Modelo suporta métodos que retornam tarefas

      No .NET Framework 4.5, ASP.NET adicionou o recurso de vinculação de modelo que habilitava uma abordagem extensível e focada em código para operações de dados baseadas em CRUD em páginas de Web Forms e controles de usuário. O sistema de vinculação de modelos agora suporta métodos de vinculação que retornam modelos com Task. Esse recurso permite que os desenvolvedores de Web Forms obtenham os benefícios de escalabilidade da programação assíncrona com a facilidade do sistema de ligação de dados ao usar versões mais recentes de ORMs, incluindo o Entity Framework.

      A vinculação de modelo assíncrono é controlada pela configuração aspnet:EnableAsyncModelBinding.

      <appSettings>
    <add key=" aspnet:EnableAsyncModelBinding" value="true|false" />
</appSettings>

      Em aplicações que têm como alvo o .NET Framework 4.6, o padrão é true. Em aplicativos executados no .NET Framework 4.6 destinados a uma versão anterior do .NET Framework, ele é false por padrão. Ele pode ser habilitado definindo a configuração como true.

    • Suporte HTTP/2 (Windows 10)

      HTTP/2 é uma nova versão do protocolo HTTP que fornece uma utilização de conexão muito melhor (menos viagens de ida e volta entre cliente e servidor), resultando em menor latência de carregamento de páginas da Web para os usuários. As páginas da Web (ao contrário dos serviços) são as que mais se beneficiam do HTTP/2, uma vez que o protocolo otimiza para vários artefatos solicitados como parte de uma única experiência. O suporte a HTTP/2 foi adicionado ao ASP.NET no .NET Framework 4.6. Como a funcionalidade de rede existe em várias camadas, novos recursos foram necessários no Windows, no IIS e no ASP.NET para habilitar o HTTP/2. Você deve estar executando no Windows 10 para usar HTTP/2 com ASP.NET.

      HTTP/2 também é suportado e ativado por padrão para aplicativos da Plataforma Universal do Windows (UWP) do Windows 10 que usam a API System.Net.Http.HttpClient.

      A fim de fornecer uma maneira de usar o recurso PUSH_PROMISE em aplicativos ASP.NET, um novo método com duas sobrecargas, PushPromise(String) e PushPromise(String, String, NameValueCollection), foi adicionado à classe HttpResponse.

      Observação

      Embora o ASP.NET Core suporte HTTP/2, o suporte para o recurso PUSH PROMISE ainda não foi adicionado.

      O navegador e o servidor Web (IIS no Windows) fazem todo o trabalho. Você não precisa fazer nenhum trabalho pesado para seus usuários.

      A maioria dos principais navegadores suportam HTTP/2, então é provável que seus usuários se beneficiem do suporte HTTP/2 se seu servidor o suportar.

    • Suporte para o protocolo de vinculação de token

      A Microsoft e o Google têm colaborado em uma nova abordagem de autenticação, chamada de Token Binding Protocol. A premissa é que os tokens de autenticação (no cache do seu navegador) podem ser roubados e usados por criminosos para acessar recursos seguros (por exemplo, sua conta bancária) sem exigir sua senha ou qualquer outro conhecimento privilegiado. O novo protocolo visa mitigar este problema.

      O Token Binding Protocol será implementado no Windows 10 como um recurso do navegador. ASP.NET aplicativos participarão do protocolo, para que os tokens de autenticação sejam validados para serem legítimos. As implementações do cliente e do servidor estabelecem a proteção de ponta a ponta especificada pelo protocolo.

    • Algoritmos de hash aleatórios para cadeias de caracteres

      O .NET Framework 4.5 introduziu um algoritmo de hash de cadeia de caracteres aleatória . No entanto, ele não era suportado pelo ASP.NET por causa de alguns recursos ASP.NET dependiam de um código hash estável. No .NET Framework 4.6, agora há suporte para algoritmos de hash de cadeia de caracteres aleatória. Para habilitar este recurso, use a definição aspnet:UseRandomizedStringHashAlgorithm.

      <appSettings>
    <add key="aspnet:UseRandomizedStringHashAlgorithm" value="true|false" />
</appSettings>

  • ADO.NET

    O ADO .NET agora oferece suporte ao recurso Always Encrypted disponível no SQL Server 2016. Com o Always Encrypted, o SQL Server pode executar operações em dados criptografados e, o melhor de tudo, a chave de criptografia reside no aplicativo dentro do ambiente confiável do cliente e não no servidor. O Always Encrypted protege os dados do cliente para que os DBAs não tenham acesso a dados de texto sem formatação. A encriptação e desencriptação de dados acontece de forma transparente ao nível do controlador, minimizando as alterações que têm de ser feitas às aplicações existentes. Para obter detalhes, consulte Always Encrypted (Mecanismo de Banco de Dados) e Always Encrypted (desenvolvimento de cliente).

  • Compilador JIT de 64 bits para código gerenciado

    O .NET Framework 4.6 apresenta uma nova versão do compilador JIT de 64 bits (originalmente codinome RyuJIT). O novo compilador de 64 bits fornece melhorias significativas de desempenho em relação ao compilador JIT de 64 bits mais antigo. O novo compilador de 64 bits está habilitado para processos de 64 bits executados sobre o .NET Framework 4.6. Seu aplicativo será executado em um processo de 64 bits se for compilado como 64 bits ou AnyCPU e estiver sendo executado em um sistema operacional de 64 bits. Embora tenha sido tomado cuidado para tornar a transição para o novo compilador o mais transparente possível, mudanças no comportamento são possíveis.

    O novo compilador JIT de 64 bits também inclui recursos de aceleração SIMD de hardware quando acoplado a tipos habilitados para SIMD no namespace System.Numerics, o que pode gerar boas melhorias de desempenho.

  • Melhorias no carregador de montagem

    O carregador de montagem agora usa a memória de forma mais eficiente, descarregando montagens IL depois que uma imagem NGEN correspondente é carregada. Essa alteração diminui a memória virtual, o que é particularmente benéfico para aplicativos grandes de 32 bits (como o Visual Studio), e também economiza memória física.

  • Alterações na biblioteca de classes base

    Muitas novas APIs foram adicionadas ao .NET Framework 4.6 para habilitar cenários-chave. Estas incluem as seguintes alterações e adições:

    • IReadOnlyCollection<T> implementações

      Coleções adicionais implementam IReadOnlyCollection<T>, tais como Queue<T> e Stack<T>.

    • CultureInfo.CurrentCulture e CultureInfo.CurrentUICulture

      As propriedades CultureInfo.CurrentCulture e CultureInfo.CurrentUICulture agora são leitura-gravação em vez de somente leitura. Se você atribuir um novo objeto CultureInfo a essas propriedades, a cultura de thread atual definida pela propriedade Thread.CurrentThread.CurrentCulture e a cultura de thread da interface do usuário atual definida pelas propriedades Thread.CurrentThread.CurrentUICulture também serão alteradas.

    • Melhorias na coleta de lixo (GC)

      A classe GC agora inclui métodos TryStartNoGCRegion e EndNoGCRegion que permitem não permitir a coleta de lixo durante a execução de um caminho crítico.

      Uma nova sobrecarga do método GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) permite-lhe controlar se as pilhas de objetos pequenos e de objetos grandes são varridas e compactadas ou apenas varridas.

    • tipos habilitados para SIMD

      O namespace System.Numerics agora inclui vários tipos habilitados para SIMD, como Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2, Vector3e Vector4.

      Como o novo compilador JIT de 64 bits também inclui recursos de aceleração SIMD de hardware, há melhorias de desempenho especialmente significativas ao usar os tipos habilitados para SIMD com o novo compilador JIT de 64 bits.

    • Atualizações de criptografia

      A API System.Security.Cryptography está sendo atualizada para oferecer suporte às APIs de criptografia Windows CNG. As versões anteriores do .NET Framework dependiam inteiramente de uma versão anterior das APIs de criptografia do Windows como base para a implementação do System.Security.Cryptography. Tivemos pedidos para suportar a API CNG, uma vez que suporta modernos algoritmos de encriptação, que são importantes para certas categorias de aplicações.

      O .NET Framework 4.6 inclui os seguintes novos aprimoramentos para oferecer suporte às APIs de criptografia do Windows CNG:

      • Um conjunto de métodos de extensão para certificados X509, System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2) e System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2), que retornam uma implementação baseada em CNG em vez de uma implementação baseada em CAPI, quando possível. (Alguns cartões inteligentes, etc., ainda exigem CAPI, e as APIs lidam com o fallback).

      • A classe System.Security.Cryptography.RSACng, que fornece uma implementação CNG do algoritmo RSA.

      • Aprimoramentos na API RSA para que ações comuns não exijam mais transmissão. Por exemplo, criptografar dados usando um objeto X509Certificate2 requer código como o seguinte em versões anteriores do .NET Framework.

        RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)cert.PrivateKey;
byte[] oaepEncrypted = rsa.Encrypt(data, true);
byte[] pkcs1Encrypted = rsa.Encrypt(data, false);

        Dim rsa As RSACryptoServiceProvider = CType(cert.PrivateKey, RSACryptoServiceProvider)
Dim oaepEncrypted() As Byte = rsa.Encrypt(data, True)
Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, False)

        O código que usa as novas APIs de criptografia no .NET Framework 4.6 pode ser reescrito da seguinte maneira para evitar a transmissão.

        RSA rsa = cert.GetRSAPrivateKey();
if (rsa == null)
   throw new InvalidOperationException("An RSA certificate was expected");

byte[] oaepEncrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1);
byte[] pkcs1Encrypted = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1);

        Dim rsa As RSA = cert.GetRSAPrivateKey()
If rsa Is Nothing Then
    Throw New InvalidOperationException("An RSA certificate was expected")
End If

Dim oaepEncrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1)
Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1)

    • Suporte para conversão de datas e horas de ou para tempo Unix

      Os seguintes novos métodos foram adicionados à estrutura DateTimeOffset para suportar a conversão de valores de data e hora de ou para a hora Unix:

    • Comutadores de compatibilidade

      A classe AppContext adiciona um novo recurso de compatibilidade que permite que os escritores de bibliotecas forneçam um mecanismo de exclusão uniforme para novas funcionalidades para seus usuários. Estabelece um contrato de acoplamento flexível entre componentes, a fim de comunicar um pedido de autoexclusão. Esse recurso geralmente é importante quando uma alteração é feita na funcionalidade existente. Por outro lado, já existe um opt-in implícito para novas funcionalidades.

      Com AppContext, as bibliotecas definem e expõem opções de compatibilidade, enquanto o código que depende delas pode definir essas opções para afetar o comportamento da biblioteca. Por padrão, as bibliotecas fornecem a nova funcionalidade e só a alteram (ou seja, fornecem a funcionalidade anterior) se a opção estiver definida.

      Um aplicativo (ou uma biblioteca) pode declarar o valor de um switch (que é sempre um valor Boolean) que uma biblioteca dependente define. O interruptor está sempre implicitamente definido para false. Definir o interruptor para true permite-o. Configurar explicitamente o interruptor para false proporciona o novo comportamento.

      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", true);

      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", True)

      A biblioteca deve verificar se um consumidor declarou o valor do interruptor e, em seguida, agir de forma adequada sobre ele.

      if (!AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", out shouldThrow))
{
    // This is the case where the switch value was not set by the application.
    // The library can choose to get the value of shouldThrow by other means.
    // If no overrides nor default values are specified, the value should be 'false'.
    // A false value implies the latest behavior.
}

// The library can use the value of shouldThrow to throw exceptions or not.
if (shouldThrow)
{
    // old code
}
else
{
    // new code
}

      If Not AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", shouldThrow) Then
    ' This is the case where the switch value was not set by the application.
    ' The library can choose to get the value of shouldThrow by other means.
    ' If no overrides nor default values are specified, the value should be 'false'.
    ' A false value implies the latest behavior.
End If

' The library can use the value of shouldThrow to throw exceptions or not.
If shouldThrow Then
    ' old code
Else
    ' new code
End If

      É benéfico usar um formato consistente para switches, uma vez que são um contrato formal exposto por uma biblioteca. Seguem-se dois formatos óbvios.

      • Switch.namespace.nome do interruptor

      • Switch.biblioteca.nome do interruptor

    • Alterações no padrão assíncrono baseado em tarefas (TAP)

      Para aplicações que visam o .NET Framework 4.6, os objetos Task e Task<TResult> herdam a cultura e a cultura da IU do thread de chamada. O comportamento de aplicativos destinados a versões anteriores do .NET Framework, ou que não visam uma versão específica do .NET Framework, não é afetado. Para obter mais informações, consulte a seção "Cultura e operações assíncronas baseadas em tarefas" do tópico CultureInfo classe.

      A classe System.Threading.AsyncLocal<T> permite que você represente dados ambientais que são locais para um determinado fluxo de controle assíncrono, como um método async. Ele pode ser usado para persistir dados entre threads. Você também pode definir um método de retorno de chamada que é notificado sempre que os dados de ambiente são alterados porque a propriedade AsyncLocal<T>.Value foi explicitamente alterada ou porque o thread encontrou uma transição de contexto.

      Três métodos de conveniência, Task.CompletedTask, Task.FromCancelede Task.FromException, foram adicionados ao padrão assíncrono baseado em tarefas (TAP) para retornar tarefas concluídas em um estado específico.

      A classe NamedPipeClientStream agora oferece suporte à comunicação assíncrona com seu novo ConnectAsync. método.

    • EventSource agora oferece suporte à gravação no log de eventos

      Agora você pode usar a classe EventSource para registrar mensagens administrativas ou operacionais no log de eventos, além de quaisquer sessões ETW existentes criadas na máquina. No passado, você tinha que usar o pacote NuGet Microsoft.Diagnostics.Tracing.EventSource para essa funcionalidade. Esta funcionalidade está agora incorporada no .NET Framework 4.6.

      O pacote NuGet e o .NET Framework 4.6 foram atualizados com os seguintes recursos:

      • Eventos dinâmicos

        Permite eventos definidos "on the fly" sem criar métodos de evento.

      • Cargas úteis avançadas

        Permite que classes e matrizes especialmente atribuídas, bem como tipos primitivos, sejam passados como uma carga útil

      • Rastreamento de atividades

        Faz com que os eventos Start e Stop marquem eventos entre eles com uma ID que representa todas as atividades ativas no momento.

      Para suportar essas funcionalidades, o método sobrecarregado Write foi adicionado à classe EventSource.

  • Windows Presentation Foundation (WPF)

    • melhorias no HDPI

      O suporte a HDPI no WPF agora é melhor no .NET Framework 4.6. Foram feitas alterações no arredondamento de layout para reduzir as ocorrências de recorte em controles com bordas. Por padrão, esse recurso é habilitado somente se seu TargetFrameworkAttribute estiver definido como .NET Framework 4.6. Os aplicativos destinados a versões anteriores da estrutura, mas em execução no .NET Framework 4.6, podem aceitar o novo comportamento adicionando a seguinte linha à seção de tempo de execução do arquivo app.config:

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

      As janelas WPF que abrangem vários monitores com diferentes configurações de DPI (configuração Multi-DPI) agora são completamente renderizadas sem regiões escurecidas. Você pode desativar esse comportamento adicionando a seguinte linha à seção <appSettings> do arquivo app.config para desabilitar esse novo comportamento:

      <add key="EnableMultiMonitorDisplayClipping" value="true"/>

      O suporte para carregar automaticamente o cursor direito com base na configuração DPI foi adicionado ao System.Windows.Input.Cursor.

    • O Touch é melhor

      Os relatórios dos clientes sobre Connect, indicando que o toque produzia um comportamento imprevisível, foram resolvidos no .NET Framework 4.6. O limite de toque duplo para aplicativos da Windows Store e aplicativos WPF agora é o mesmo no Windows 8.1 e superior.

    • Suporte para janela filha transparente

      WPF no .NET Framework 4.6 oferece suporte a janelas secundárias transparentes no Windows 8.1 e superior. Isso permite que você crie janelas filho não retangulares e transparentes em suas janelas de nível superior. Você pode habilitar esse recurso definindo a propriedade HwndSourceParameters.UsesPerPixelTransparency como true.

  • Windows Communication Foundation (WCF)

    • suporte SSL

      O WCF agora suporta SSL versão TLS 1.1 e TLS 1.2, além de SSL 3.0 e TLS 1.0, ao usar NetTcp com segurança de transporte e autenticação de cliente. Agora é possível selecionar qual protocolo usar, ou desativar antigos protocolos menos seguros. Isso pode ser feito definindo a propriedade SslProtocols ou adicionando o seguinte a um arquivo de configuração.

      <netTcpBinding>
    <binding>
      <security mode= "None|Transport|Message|TransportWithMessageCredential" >
          <transport clientCredentialType="None|Windows|Certificate"
                    protectionLevel="None|Sign|EncryptAndSign"
                    sslProtocols="Ssl3|Tls1|Tls11|Tls12">
            </transport>
      </security>
    </binding>
</netTcpBinding>

    • Enviar mensagens usando diferentes conexões HTTP

      O WCF agora permite que os usuários garantam que determinadas mensagens sejam enviadas usando diferentes conexões HTTP subjacentes. Há duas maneiras de fazer isso:

      • Usando um prefixo de nome de grupo de conexões

        Os usuários podem especificar uma cadeia de caracteres que o WCF usará como um prefixo para o nome do grupo de conexões. Duas mensagens com prefixos diferentes são enviadas usando conexões HTTP subjacentes diferentes. Você define o prefixo adicionando um par chave/valor à propriedade Message.Properties da mensagem. A chave é "HttpTransportConnectionGroupNamePrefix"; O valor é o prefixo desejado.

      • Usando fábricas de canais diferentes

        Os usuários também podem habilitar um recurso que garante que as mensagens enviadas usando canais criados por fábricas de canais diferentes usarão diferentes conexões HTTP subjacentes. Para habilitar esta funcionalidade, os utilizadores devem configurar o seguinte appSetting para true:

        <appSettings>
    <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
</appSettings>

  • do Windows Workflow Foundation (WWF)

    Agora você pode especificar o número de segundos que um serviço de fluxo de trabalho manterá em uma solicitação de operação fora de ordem quando houver um marcador "não protocolar" pendente antes de atingir o tempo limite da solicitação. Um marcador "não protocolar" é um marcador que não está relacionado a atividades pendentes de Recebimento. Algumas atividades criam marcadores não protocolares em sua implementação, portanto, pode não ser óbvio que exista um marcador não protocolar. Estes incluem State e Pick. Portanto, se você tiver um serviço de fluxo de trabalho implementado com uma máquina de estado ou contendo uma atividade Pick, provavelmente terá marcadores não protocolares. Para especificar o intervalo, adicione uma linha como a seguinte à seção appSettings do arquivo app.config:

    <add key="microsoft:WorkflowServices:FilterResumeTimeoutInSeconds" value="60"/>

    O valor padrão é 60 segundos. Se value estiver definido como 0, as solicitações fora de ordem serão imediatamente rejeitadas com uma falha no texto semelhante a esta:

    Operation 'Request3|{http://tempuri.org/}IService' on service instance with identifier '2b0667b6-09c8-4093-9d02-f6c67d534292' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees.

    Esta é a mesma mensagem que você recebe se uma mensagem de operação fora de ordem for recebida e não houver marcadores não protocolares.

    Se o valor do elemento FilterResumeTimeoutInSeconds for diferente de zero, houver marcadores não protocolares e o intervalo de tempo limite expirar, a operação falhará com uma mensagem de tempo limite.

  • Transações

    Agora você pode incluir o identificador de transação distribuída para a transação que causou uma exceção derivada de TransactionException a ser lançada. Para fazer isso, adicione a seguinte chave à seção appSettings do arquivo app.config:

    <add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>

    O valor padrão é false.

  • Rede de Contactos

    • Reutilização de Socket

      O Windows 10 inclui um novo algoritmo de rede de alta escalabilidade que faz melhor uso dos recursos da máquina reutilizando portas locais para conexões TCP de saída. O .NET Framework 4.6 oferece suporte ao novo algoritmo, permitindo que os aplicativos .NET aproveitem o novo comportamento. Em versões anteriores do Windows, havia um limite de conexão simultânea artificial (normalmente 16.384, o tamanho padrão do intervalo de portas dinâmicas), que poderia limitar a escalabilidade de um serviço, causando exaustão da porta quando sob carga.

      No .NET Framework 4.6, duas APIs foram adicionadas para habilitar a reutilização de portas, o que efetivamente remove o limite de 64 KB em conexões simultâneas:

      Por padrão, a propriedade ServicePointManager.ReusePort é false a menos que o valor HWRPortReuseOnSocketBind da chave do Registro HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 esteja definido como 0x1. Para habilitar a reutilização de porta local em conexões HTTP, defina a propriedade ServicePointManager.ReusePort como true. Isso faz com que todas as conexões de soquete TCP de saída do HttpClient e HttpWebRequest usem uma nova opção de soquete do Windows 10, SO_REUSE_UNICASTPORT, que permite a reutilização da porta local.

      Os desenvolvedores que escrevem um aplicativo somente soquetes podem especificar a opção System.Net.Sockets.SocketOptionName ao chamar um método como Socket.SetSocketOption para que os soquetes de saída reutilizem portas locais durante a vinculação.

    • Suporte para nomes de domínio internacionais e PunyCode

      Uma nova propriedade, IdnHost, foi adicionada à classe Uri para oferecer melhor suporte a nomes de domínio internacionais e PunyCode.

  • Redimensionamento em controles do Windows Forms.

    Esse recurso foi expandido no .NET Framework 4.6 para incluir os tipos DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn e ToolStripSplitButton e o retângulo especificado pela propriedade Bounds usada ao desenhar um UITypeEditor.

    Esta é uma funcionalidade de adesão voluntária. Para habilitá-lo, defina o elemento EnableWindowsFormsHighDpiAutoResizing como true no arquivo de configuração do aplicativo (app.config):

    <appSettings>
    <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
</appSettings>

  • Suporte para codificações de páginas de código

    O .NET Core suporta principalmente as codificações Unicode e, por padrão, fornece suporte limitado para codificações de página de código. Você pode adicionar suporte para codificações de página de código disponíveis no .NET Framework, mas sem suporte no .NET Core, registrando codificações de página de código com o método Encoding.RegisterProvider. Para obter mais informações, consulte System.Text.CodePagesEncodingProvider.

  • nativo do .NET

Os aplicativos da Plataforma Universal do Windows (UWP) escritos em C# ou Visual Basic podem tirar proveito de uma nova tecnologia que compila aplicativos para código nativo em vez de IL. Esta tecnologia produz aplicações que têm tempos de arranque e execução mais rápidos. Para obter mais informações, consulte compilando aplicativos com o .NET Native. Para obter uma visão geral do .NET Native que examina como ele difere da compilação JIT e NGEN e o que isso significa para seu código, consulte .NET Native and Compilation.

Seus aplicativos são compilados em código nativo por padrão quando você os compila com o Visual Studio 2015 ou posterior. Para obter mais informações, consulte Introdução ao .NET Native.

Para dar suporte à depuração de aplicativos nativos do .NET, várias novas interfaces e enumerações foram adicionadas à API de depuração não gerenciada. Para obter mais informações, consulte o tópico Debugging (Unmanaged API Reference).

O que há de novo no .NET Framework 4.5.2

  • Novas APIs para aplicativos ASP.NET. Os novos métodos HttpResponse.AddOnSendingHeaders e HttpResponseBase.AddOnSendingHeaders permitem inspecionar e modificar cabeçalhos de resposta e código de status à medida que a resposta é liberada para o aplicativo cliente. Considere usar esses métodos em vez dos eventos PreSendRequestHeaders e PreSendRequestContent; são mais eficientes e fiáveis.

    O método HostingEnvironment.QueueBackgroundWorkItem permite agendar pequenos itens de trabalho em segundo plano. ASP.NET rastreia esses itens e impede que o IIS encerre abruptamente o processo de trabalho até que todos os itens de trabalho em segundo plano sejam concluídos. Esse método não pode ser chamado fora de um domínio de aplicativo gerenciado ASP.NET.

    As novas propriedades HttpResponse.HeadersWritten e HttpResponseBase.HeadersWritten retornam valores booleanos que indicam se os cabeçalhos de resposta foram gravados. Você pode usar essas propriedades para assegurar que as chamadas para APIs como HttpResponse.StatusCode (que geram exceções se os cabeçalhos tiverem sido gravados) sejam bem-sucedidas.

  • Redimensionamento nos controlos do Windows Forms. Este recurso foi expandido. Agora você pode usar a configuração DPI do sistema para redimensionar componentes dos seguintes controles adicionais (por exemplo, a seta suspensa em caixas de combinação):

    Esta é uma funcionalidade opcional. Para habilitá-lo, defina o elemento EnableWindowsFormsHighDpiAutoResizing como true no arquivo de configuração do aplicativo (app.config):

    <appSettings>
    <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
</appSettings>

  • Novo recurso de fluxo de trabalho. Um gerenciador de recursos que está usando o método EnlistPromotableSinglePhase (e, portanto, implementando a interface IPromotableSinglePhaseNotification) pode usar o novo método Transaction.PromoteAndEnlistDurable para solicitar o seguinte:

    Isso pode ser feito dentro do mesmo domínio do aplicativo e não requer nenhum código não gerenciado extra para interagir com o MSDTC para executar a promoção. O novo método pode ser chamado somente quando há uma chamada pendente de System.Transactions para o método IPromotableSinglePhaseNotificationPromote implementado pelo alistamento promocional.

  • Melhorias na criação de perfis. As novas APIs de criação de perfil não gerenciadas a seguir fornecem uma criação de perfil mais robusta:

    Implementações de ICorProfiler anteriores suportavam o carregamento lento de assemblies dependentes. As novas APIs de criação de perfil exigem que as assemblies dependentes injetadas pelo instrumentador sejam carregáveis imediatamente, em vez de serem carregadas após a aplicação estar totalmente inicializada. Essa alteração não afeta os usuários das APIs de ICorProfiler existentes.

  • Melhorias na depuração. As seguintes novas APIs de depuração não geridas proporcionam uma melhor integração com um perfilador. Agora pode aceder aos metadados inseridos pelo perfilador, bem como às variáveis locais e ao código produzido por pedidos de ReJIT do compilador durante a análise de um dump.

  • Alterações no rastreamento de eventos. O .NET Framework 4.5.2 permite o rastreamento de atividades baseado em Rastreamento de Eventos para Windows (ETW) fora do processo para uma área de superfície maior. Isso permite que os fornecedores de Gestão Avançada de Energia (APM) forneçam ferramentas leves que rastreiam com precisão os custos de solicitações individuais e atividades que se interligam entre threads. Esses eventos são gerados somente quando os controladores ETW os habilitam; portanto, as alterações não afetam o código ETW escrito anteriormente ou o código executado com o ETW desativado.

  • Promover uma transação e convertê-la em uma adesão durável

    Transaction.PromoteAndEnlistDurable é uma nova API adicionada ao .NET Framework 4.5.2 e 4.6:

    [System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name = "FullTrust")]
public Enlistment PromoteAndEnlistDurable(Guid resourceManagerIdentifier,
                                          IPromotableSinglePhaseNotification promotableNotification,
                                          ISinglePhaseNotification enlistmentNotification,
                                          EnlistmentOptions enlistmentOptions)

    <System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name:="FullTrust")>
public Function PromoteAndEnlistDurable(resourceManagerIdentifier As Guid,
                                        promotableNotification As IPromotableSinglePhaseNotification,
                                        enlistmentNotification As ISinglePhaseNotification,
                                        enlistmentOptions As EnlistmentOptions) As Enlistment

    O método pode ser usado por um alistamento que foi previamente criado por Transaction.EnlistPromotableSinglePhase em resposta ao método ITransactionPromoter.Promote. Pede a System.Transactions que eleve a transação a uma transação MSDTC e que "converta" o alistamento promovível num alistamento duradouro. Depois que esse método for concluído com êxito, a interface IPromotableSinglePhaseNotification não será mais referenciada por System.Transactionse quaisquer notificações futuras chegarão na interface ISinglePhaseNotification fornecida. O alistamento em questão deve funcionar como um alistamento duradouro, suportando o registo e a recuperação de transações. Consulte Transaction.EnlistDurable para obter detalhes. Além disso, o alistamento deve apoiar ISinglePhaseNotification. Este método só pode ser chamado durante o processamento de uma chamada ITransactionPromoter.Promote. Se não for esse o caso, uma exceção TransactionException é lançada.

O que há de novo no .NET Framework 4.5.1

Atualizações de abril de 2014:

  • Visual Studio 2013 Atualização 2 inclui atualizações para os modelos de Biblioteca de Classes Portátil para oferecer suporte a estes cenários:

    • Você pode usar APIs do Tempo de Execução do Windows em bibliotecas portáteis destinadas ao Windows 8.1, Windows Phone 8.1 e Windows Phone Silverlight 8.1.

    • Você pode incluir XAML (tipos Windows.UI.XAML) em bibliotecas portáteis ao direcionar o Windows 8.1 ou o Windows Phone 8.1. Os seguintes modelos XAML são suportados: Página em Branco, Dicionário de Recursos, Controle de Modelo e Controle de Usuário.

    • Você pode criar um componente portátil do Tempo de Execução do Windows (arquivo .winmd) para uso em aplicativos da Loja destinados ao Windows 8.1 e ao Windows Phone 8.1.

    • Você pode redirecionar uma biblioteca de classes da Windows Store ou da Loja do Windows Phone como uma Biblioteca de Classes Portátil.

    Para obter mais informações sobre essas alterações, consulte Biblioteca de Classes Portátil.

  • O conjunto de conteúdo do .NET Framework agora inclui documentação para o .NET Native, que é uma tecnologia de pré-compilação para criar e implantar aplicativos do Windows. O .NET Native compila seus aplicativos diretamente para código nativo, em vez de linguagem intermediária (IL), para um melhor desempenho. Para obter detalhes, consulte compilando aplicativos com o .NET Native.

  • A Fonte de Referência do .NET Framework fornece uma nova experiência de navegação e funcionalidade aprimorada. Agora pode navegar pelo código-fonte do .NET Framework online, baixar o arquivo de referência para visualização offline e percorrer o código-fonte (incluindo patches e atualizações) durante a depuração. Para obter mais informações, consulte a entrada de blog Uma nova aparência para a fonte de referência do .NET.

Novos recursos e aprimoramentos nas classes base no .NET Framework 4.5.1 incluem:

  • Redirecionamento automático de vinculação para montagens. A partir do Visual Studio 2013, quando você compila um aplicativo destinado ao .NET Framework 4.5.1, redirecionamentos de vinculação podem ser adicionados ao arquivo de configuração do aplicativo se seu aplicativo ou seus componentes fizerem referência a várias versões do mesmo assembly. Você também pode habilitar esse recurso para projetos destinados a versões mais antigas do .NET Framework. Para obter mais informações, consulte Como habilitar e desabilitar o redirecionamento automático de vinculação.

  • Capacidade de coletar informações de diagnóstico para ajudar os desenvolvedores a melhorar o desempenho de aplicativos de servidor e nuvem. Para obter mais informações, consulte os métodos WriteEventWithRelatedActivityId e WriteEventWithRelatedActivityIdCore na classe EventSource.

  • Capacidade de compactar explicitamente a pilha de objetos grandes (LOH) durante a coleta de lixo. Para obter mais informações, consulte a propriedade GCSettings.LargeObjectHeapCompactionMode.

  • Melhorias adicionais de desempenho, como suspensão de aplicativos ASP.NET, melhorias JIT multicore e inicialização mais rápida do aplicativo após uma atualização do .NET Framework. Para obter detalhes, consulte o anúncio do .NET Framework 4.5.1 e a postagem de blog sobre a suspensão da app ASP.NET .

As melhorias no Windows Forms incluem:

  • Redimensionamento em controles do Windows Forms. Você pode usar a configuração DPI do sistema para redimensionar componentes de controlos (por exemplo, os ícones que aparecem numa grade de propriedades) optando por uma entrada no ficheiro de configuração da aplicação (app.config) para a sua aplicação. Esse recurso é suportado atualmente nos seguintes controles do Windows Forms:

    Para habilitar esse recurso, adicione um novo elemento <appSettings> ao arquivo de configuração (app.config) e defina o elemento EnableWindowsFormsHighDpiAutoResizing como true:

    <appSettings>
    <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
</appSettings>

As melhorias ao depurar as suas aplicações do .NET Framework no Visual Studio 2013 incluem:

  • Retornar valores no depurador do Visual Studio. Quando você depura um aplicativo gerenciado no Visual Studio 2013, a janela Autos exibe tipos de retorno e valores para métodos. Estas informações estão disponíveis para aplicações de ambiente de trabalho, Loja Windows e Windows Phone. Para obter mais informações, consulte Examine os valores de retorno das chamadas de método.

  • Edite e continue para aplicativos de 64 bits. O Visual Studio 2013 oferece suporte ao recurso Editar e Continuar para aplicativos gerenciados de 64 bits para área de trabalho, Windows Store e Windows Phone. As limitações existentes permanecem em vigor para aplicações de 32 bits e 64 bits (consulte a última seção do artigo Supported Code Changes (C#)).

  • Depuração com reconhecimento de assíncrono. Para facilitar a depuração de aplicativos assíncronos no Visual Studio 2013, a pilha de chamadas oculta o código de infraestrutura fornecido pelos compiladores para dar suporte à programação assíncrona e também encadeia em quadros pai lógicos para que você possa acompanhar a execução do programa lógico com mais clareza. Uma janela Tarefas substitui a janela Tarefas paralelas e exibe tarefas relacionadas a um ponto de interrupção específico, além de exibir quaisquer outras tarefas que estejam atualmente ativas ou agendadas no aplicativo. Você pode ler sobre essa funcionalidade na seção "Depuração com reconhecimento de assíncrono" no anúncio do .NET Framework 4.5.1 .

  • Melhor suporte a exceções para componentes do Tempo de Execução do Windows. No Windows 8.1, as exceções que surgem de aplicativos da Windows Store preservam informações sobre o erro que causou a exceção, mesmo entre os limites de idioma. Você pode ler sobre esse recurso na seção "Desenvolvimento de aplicativos da Windows Store" do anúncio do .NET Framework 4.5.1.

A partir do Visual Studio 2013, você pode usar o Managed Profile Guided Optimization Tool (Mpgo.exe) para otimizar aplicativos da Windows Store 8.x, bem como aplicativos da área de trabalho.

Para saber mais sobre os novos recursos do ASP.NET 4.5.1, consulte as Notas de versão do ASP.NET e Web Tools for Visual Studio 2013.

O que há de novo no .NET Framework 4.5

Classes de base

  • Capacidade de reduzir as reinicializações do sistema detetando e fechando aplicativos do .NET Framework 4 durante a implantação. Consulte Reduzindo Reinicializações do Sistema Durante Instalações do .NET Framework 4.5.

  • Suporte para arrays maiores que 2 gigabytes (GB) em plataformas de 64 bits. Esse recurso pode ser habilitado no arquivo de configuração do aplicativo. Consulte o elemento><gcAllowVeryLargeObjects, que também lista outras restrições sobre o tamanho do objeto e o tamanho da matriz.

  • Melhor desempenho através da recolha de lixo em segundo plano para servidores. Quando você usa a coleta de lixo do servidor no .NET Framework 4.5, a coleta de lixo em segundo plano é habilitada automaticamente. Consulte a seção Coleta de lixo do servidor em segundo plano do tópico Fundamentos da coleta de lixo.

  • Compilação just-in-time (JIT) em segundo plano, que está disponível opcionalmente em processadores multi-core para melhorar o desempenho da aplicação. Consulte ProfileOptimization.

  • Capacidade de limitar por quanto tempo o mecanismo de expressão regular tentará resolver uma expressão regular antes que ela atinja o tempo limite. Ver a propriedade Regex.MatchTimeout.

  • Capacidade de definir a cultura padrão para um domínio de aplicativo. Veja a aula CultureInfo.

  • Suporte de console para codificação Unicode (UTF-16). Veja a Console classe.

  • Suporte para versionamento de ordenação de cadeia de caracteres culturais e dados de comparação. Veja a classe SortVersion.

  • Melhor desempenho na recuperação de recursos. Consulte Empacotar e implantar recursos.

  • Melhorias na compressão zip para reduzir o tamanho de um ficheiro comprimido. Consulte o namespace System.IO.Compression.

  • Capacidade de personalizar um contexto de reflexão para substituir o comportamento de reflexão padrão através da classe CustomReflectionContext.

  • Suporte para a versão 2008 do padrão IDNA (Internationalized Domain Names in Applications) quando a classe System.Globalization.IdnMapping é usada no Windows 8.

  • Delegação de comparação de cadeia de caracteres para o sistema operacional, que implementa Unicode 6.0, quando o .NET Framework é usado no Windows 8. Quando executado em outras plataformas, o .NET Framework inclui seus próprios dados de comparação de cadeia de caracteres, que implementa Unicode 5.x. Consulte a classe String e a seção Comentários da classe SortVersion.

  • Capacidade de calcular os códigos hash para cadeias de caracteres por domínio de aplicativo. Consulte <UseRandomizedStringHashAlgorithm> Element.

  • Suporte para reflexão de tipo dividido entre classes Type e TypeInfo. Consulte reflexão no .NET Framework para aplicativos da Windows Store.

Estrutura de extensibilidade gerenciada (MEF)

No .NET Framework 4.5, o Managed Extensibility Framework (MEF) fornece os seguintes novos recursos:

  • Suporte para tipos genéricos.

  • Modelo de programação baseado em convenção que permite criar partes com base em convenções de nomenclatura em vez de atributos.

  • Vários escopos.

  • Um subconjunto de MEF que você pode usar ao criar aplicativos da Windows Store 8.x. Esse subconjunto está disponível como um pacote para download na Galeria NuGet. Para instalar o pacote, abra o seu projeto no Visual Studio, escolha Gerir Pacotes NuGet no menu Projeto e pesquise o pacote Microsoft.Composition online.

Para obter mais informações, consulte Managed Extensibility Framework (MEF).

Operações de arquivo assíncronas

No .NET Framework 4.5, novos recursos assíncronos foram adicionados às linguagens C# e Visual Basic. Esses recursos adicionam um modelo baseado em tarefas para executar operações assíncronas. Para usar esse novo modelo, use os métodos assíncronos nas classes de E/S. Consulte Entrada/Saída de arquivo assíncrono.

Ferramentas

No .NET Framework 4.5, o Resource File Generator (Resgen.exe) permite que você crie um arquivo .resw para uso em aplicativos da Windows Store 8.x a partir de um arquivo .resources incorporado em um assembly do .NET Framework. Para obter mais informações, consulte Resgen.exe (Resource File Generator).

A Otimização Guiada por Perfil Gerenciado (Mpgo.exe) permite melhorar o tempo de inicialização do aplicativo, a utilização da memória (tamanho do conjunto de trabalho) e a taxa de transferência otimizando assemblies de imagem nativa. A ferramenta de linha de comando gera dados de perfil para assemblies de aplicativos de imagem nativa. Consulte Mpgo.exe (Ferramenta de Otimização Guiada de Perfil Gerido). A partir do Visual Studio 2013, você pode usar Mpgo.exe para otimizar aplicativos da Windows Store 8.x, bem como aplicativos da área de trabalho.

Computação paralela

O .NET Framework 4.5 fornece vários novos recursos e melhorias para a computação paralela. Isso inclui melhor desempenho, maior controle, suporte aprimorado para programação assíncrona, uma nova biblioteca de fluxo de dados e suporte aprimorado para depuração paralela e análise de desempenho. Consulte a entrada Novidades do paralelismo no .NET Framework 4.5 no blog Programação paralela com .NET.

Sítio Web

ASP.NET 4.5 e 4.5.1 adicionam vinculação de modelo para Web Forms, suporte a WebSocket, manipuladores assíncronos, aprimoramentos de desempenho e muitos outros recursos. Para obter mais informações, consulte os seguintes recursos:

Conectividade

O .NET Framework 4.5 fornece uma nova interface de programação para aplicativos HTTP. Para obter mais informações, consulte os novos namespaces System.Net.Http e System.Net.Http.Headers.

Também está incluído suporte para uma nova interface de programação para aceitar e interagir com uma conexão WebSocket usando o HttpListener existente e classes relacionadas. Para obter mais informações, consulte o novo namespace System.Net.WebSockets e a classe HttpListener.

Além disso, o .NET Framework 4.5 inclui as seguintes melhorias de rede:

  • Suporte a URI compatível com RFC. Para obter mais informações, consulte Uri e classes relacionadas.

  • Suporte para análise de nomes de domínio internacionalizados (IDN). Para obter mais informações, consulte Uri e classes relacionadas.

  • Suporte para Internacionalização de Endereço de Email (EAI). Para obter mais informações, consulte o namespace System.Net.Mail.

  • Suporte IPv6 melhorado. Para obter mais informações, consulte o namespace System.Net.NetworkInformation.

  • Suporte de soquete de modo duplo. Para obter mais informações, consulte as classes Socket e TcpListener.

Windows Presentation Foundation (WPF)

No .NET Framework 4.5, o Windows Presentation Foundation (WPF) contém alterações e melhorias nas seguintes áreas:

  • O novo controle Ribbon, que permite implementar uma interface de usuário da faixa de opções que hospeda uma Barra de Ferramentas de Acesso Rápido, Menu de Aplicativo e guias.

  • A nova interface INotifyDataErrorInfo, que suporta validação de dados síncrona e assíncrona.

  • Novos recursos para as classes VirtualizingPanel e Dispatcher.

  • Desempenho aprimorado ao exibir grandes conjuntos de dados agrupados e ao acessar coleções em threads que não são da interface do usuário.

  • Vinculação de dados a propriedades estáticas, vinculação de dados a tipos personalizados que implementam a interface ICustomTypeProvider e recuperação de informações de vinculação de dados de uma expressão de associação.

  • Reposicionamento de dados à medida que os valores mudam (live shaping).

  • Capacidade de verificar se o contexto de dados de um contêiner de item está desconectado.

  • Capacidade de definir a quantidade de tempo que deve decorrer entre as alterações de propriedade e as atualizações da fonte de dados.

  • Suporte melhorado para a implementação de padrões de eventos fracos. Além disso, os eventos agora podem aceitar extensões de marcação.

Windows Communication Foundation (WCF)

No .NET Framework 4.5, os seguintes recursos foram adicionados para simplificar a escrita e manutenção de aplicativos WCF (Windows Communication Foundation):

  • Simplificação dos arquivos de configuração gerados.

  • Suporte para desenvolvimento orientado a contratos.

  • Capacidade de configurar ASP.NET modo de compatibilidade mais facilmente.

  • Alterações nos valores padrão das propriedades de transporte para reduzir a necessidade de ter que defini-los.

  • Atualizações para a classe XmlDictionaryReaderQuotas para reduzir a probabilidade de que você terá que configurar manualmente cotas para leitores de dicionário XML.

  • Validação de arquivos de configuração do WCF pelo Visual Studio como parte do processo de compilação, para que você possa detetar erros de configuração antes de executar seu aplicativo.

  • Novo suporte de streaming assíncrono.

  • Novo mapeamento de protocolo HTTPS para facilitar a exposição de um ponto de extremidade por HTTPS com o IIS (Serviços de Informações da Internet).

  • Capacidade de gerar metadados em um único documento WSDL anexando ?singleWSDL à URL do serviço.

  • Suporte de Websockets para permitir uma comunicação bidirecional verdadeira através das portas 80 e 443 com as características de desempenho semelhantes ao transporte TCP.

  • Suporte para configuração de serviços em código.

  • Dicas de ferramentas do Editor XML.

  • ChannelFactory suporte para cache.

  • Suporte para compressão por codificação binária.

  • Suporte para um transporte UDP que permite aos programadores escrever serviços que usam mensagens "enviar e esquecer". Um cliente envia uma mensagem para um serviço e não espera nenhuma resposta do serviço.

  • Capacidade de suportar vários modos de autenticação num único ponto de extremidade WCF ao usar transporte HTTP, e segurança de transporte.

  • Suporte para serviços WCF que usam nomes de domínio internacionalizados (IDNs).

Para obter mais informações, consulte Novidades no Windows Communication Foundation.

Windows Workflow Foundation (WF)

No .NET Framework 4.5, vários novos recursos foram adicionados ao Windows Workflow Foundation (WF), incluindo:

  • Fluxos de trabalho de máquina de estado, que foram introduzidos pela primeira vez como parte do .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1). Esta atualização incluiu várias novas classes e atividades que permitiram aos desenvolvedores criar fluxos de trabalho de máquina de estado. Essas classes e atividades foram atualizadas para o .NET Framework 4.5 para incluir:

    • A capacidade de definir pontos de interrupção em estados.

    • A capacidade de copiar e colar transições no designer de fluxo de trabalho.

    • Suporte de designer para criação de transição de gatilho compartilhado.

    • Atividades para criar fluxos de trabalho em máquina de estado, incluindo: StateMachine, Statee Transition.

  • Recursos aprimorados do Designer de Fluxo de Trabalho, como os seguintes:

    • Recursos aprimorados de pesquisa de fluxo de trabalho no Visual Studio, incluindo Quick Find e Find in Files.

    • Capacidade de criar automaticamente uma atividade de Sequência quando uma segunda atividade filho é adicionada a uma atividade de contêiner e de incluir ambas as atividades na atividade de Sequência.

    • Suporte ao movimento panorâmico, que permite alterar a porção visível de um fluxo de trabalho sem usar as barras de deslocamento.

    • Uma nova exibição de de Estrutura de Tópicos de Documento que mostra os componentes de um fluxo de trabalho em uma exibição de estrutura de tópicos em estilo de árvore e permite selecionar um componente na exibição Estrutura de Tópicos do Documento .

    • Capacidade de adicionar anotações às atividades.

    • Capacidade de definir e consumir delegados de atividade usando o designer de fluxo de trabalho.

    • Conexão automática e inserção automática para atividades e transições em fluxos de trabalho de máquinas de estados e fluxogramas.

  • Armazenamento das informações de estado de exibição de um fluxo de trabalho em um único elemento no arquivo XAML, para que você possa localizar e editar facilmente as informações de estado de exibição.

  • Uma atividade de contêiner NoPersistScope para impedir que as atividades filho persistam.

  • Suporte para expressões em C#:

    • Projetos de fluxo de trabalho que usam Visual Basic usarão expressões do Visual Basic e projetos de fluxo de trabalho C# usarão expressões C#.

    • Projetos de fluxo de trabalho C# que foram criados no Visual Studio 2010 e que têm expressões do Visual Basic são compatíveis com projetos de fluxo de trabalho C# que usam expressões C#.

  • Melhorias no controle de versão:

    • A nova classe WorkflowIdentity, que fornece um mapeamento entre uma instância de fluxo de trabalho persistente e sua definição de fluxo de trabalho.

    • Execução lado a lado de várias versões de fluxo de trabalho no mesmo host, incluindo WorkflowServiceHost.

    • Na Atualização Dinâmica, a capacidade de modificar a definição de uma instância de fluxo de trabalho persistente.

  • Desenvolvimento de serviços com abordagem 'contract-first', que fornece suporte para gerar automaticamente atividades que correspondam a um contrato de serviço existente.

Para obter mais informações, consulte O que há de novo no Windows Workflow Foundation.

.NET para aplicativos da Windows Store 8.x

As aplicações da Loja Windows 8.x foram concebidas para formatos de fatores específicos e aproveitam o poder do sistema operativo Windows. Um subconjunto do .NET Framework 4.5 ou 4.5.1 está disponível para criar aplicativos da Windows Store 8.x para Windows usando C# ou Visual Basic. Esse subconjunto é chamado .NET para aplicativos da Windows Store 8.x e é discutido em uma visão geral .

Bibliotecas de classes portáteis

O projeto Biblioteca de Classes Portátil no Visual Studio 2012 (e versões posteriores) permite que você escreva e crie assemblies gerenciados que funcionam em várias plataformas .NET Framework. Usando um projeto de Biblioteca de Classes Portátil, você escolhe as plataformas (como Windows Phone e .NET para aplicativos da Windows Store 8.x) a serem direcionadas. Os tipos e membros disponíveis em seu projeto são automaticamente restritos aos tipos e membros comuns nessas plataformas. Para obter mais informações, consulte Biblioteca de Classes Portátil.

Ver também