Novidades do .NET Core 2.1

  • Artigo

O .NET Core 2.1 contém melhorias e novos recursos nas seguintes áreas:

Ferramentas

O SDK do .NET Core 2.1 (v 2.1.300), o conjunto de ferramentas incluído no .NET Core 2.1, inclui as seguintes alterações e aprimoramentos:

Melhorias de desempenho de build

Um dos principais focos do .NET Core 2.1 é melhorar o desempenho de tempo de build, especialmente para builds incrementais. Essas melhorias de desempenho se aplicam a ambos os builds de linha de comando que usam dotnet build e a builds no Visual Studio. Algumas áreas individuais de melhoria incluem:

  • Na resolução de ativos de pacote, resolução somente de ativos usados por um build, em vez de todos os ativos.

  • Armazenamento em cache de referências de assembly.

  • Uso de servidores de build do SDK de longa execução, que são processos que se estendem por chamadas individuais de dotnet build. Eles eliminam a necessidade de compilação JIT de grandes blocos de código toda vez que dotnet build é executado. Os processos do servidor de build podem ser finalizados automaticamente com o seguinte comando:

    dotnet buildserver shutdown

Novos comandos da CLI

Várias ferramentas que estavam disponíveis apenas por projeto usando DotnetCliToolReference agora estão disponíveis como parte do SDK do .NET Core. Essas ferramentas incluem:

  • dotnet watch fornece um observador do sistema de arquivos que aguarda que um arquivo seja alterado antes de executar um conjunto designado de comandos. Por exemplo, o comando a seguir recria automaticamente o projeto atual e gera uma saída detalhada sempre que um arquivo é alterado nele:

    dotnet watch -- --verbose build

    Observe a opção -- que precede a opção --verbose. Isso delimita as opções passadas diretamente para o comando dotnet watch dos argumentos que são passados para o processo dotnet filho. Sem isso, a opção --verbose se aplica ao comando dotnet watch, não ao comando dotnet build.

    Para saber mais, confira Desenvolver aplicativos ASP.NET Core usando dotnet watch.

  • dotnet dev-certs gera e gerencia os certificados usados durante o desenvolvimento de aplicativos do ASP.NET Core.

  • dotnet user-secrets gerencia os segredos em um repositório de segredos do usuário em aplicativos do ASP.NET Core.

  • dotnet sql-cache cria uma tabela e índices em um banco de dados do Microsoft SQL Server a serem usados para armazenamento em cache distribuído.

  • dotnet ef é uma ferramenta para gerenciar bancos de dados, objetos DbContext e migrações em aplicativos Entity Framework Core. Para saber mais, confira Ferramentas da linha de comando do .NET EF Core.

Ferramentas Globais

O .NET Core 2.1 oferece suporte a Ferramentas Globais, ou seja, ferramentas personalizadas que estão disponíveis globalmente a partir da linha de comando. O modelo de extensibilidade em versões anteriores do .NET Core disponibilizava ferramentas personalizadas apenas por projeto usando DotnetCliToolReference.

Para instalar uma Ferramenta Global, use o comando dotnet tool install. Por exemplo:

dotnet tool install -g dotnetsay

Uma vez instalada, a ferramenta pode ser executada a partir da linha de comando, especificando o nome da ferramenta. Para saber mais, confira Visão geral das Ferramentas Globais do .NET Core.

Gerenciamento de ferramentas com o comando dotnet tool

No SDK do .NET Core 2.1, todas as operações de ferramentas usam o comando dotnet tool. As seguintes opções estão disponíveis:

Efetuar roll forward

Do .NET Core 2.0 em diante, todos os aplicativos .NET Core efetuam roll forward automaticamente para a última versão secundária instalada em um sistema.

A partir do .NET Core 2.0, se a versão do .NET Core com a qual um aplicativo foi criado não estiver presente no tempo de execução, o aplicativo será executado automaticamente com a versão secundária do .NET Core mais recente instalada. Em outras palavras, se um aplicativo for criado com o .NET Core 2.0, e o .NET Core 2.0 não estiver presente no sistema do host, mas o .NET Core 2.1 estiver, o aplicativo será executado com o .NET Core 2.1.

Importante

Esse comportamento de roll-forward não se aplica a versões prévias. Por padrão, ele também não se aplica a versões principais, mas isso pode ser alterado com as configurações abaixo.

Modifique esse comportamento alterando a configuração de roll forward em nenhuma estrutura compartilhada candidata. As configurações disponíveis são:

  • 0 – desabilitar o comportamento de roll forward da versão secundária. Com essa configuração, um aplicativo criado para o .NET Core 2.0.0 efetuará roll forward para o .NET Core 2.0.1, mas não para o .NET Core 2.2.0 ou o .NET Core 3.0.0.
  • 1 – habilitar o comportamento de roll forward da versão secundária. Esse é o valor padrão para a configuração. Com essa configuração, um aplicativo criado para o .NET Core 2.0.0 efetuará roll forward para o .NET Core 2.0.1 ou o .NET Core 2.2.0, dependendo de qual estiver instalado, mas não efetuará roll forward para o .NET Core 3.0.0.
  • 2 – habilitar o comportamento de roll forward das versões secundária e principal. Se essa opção estiver definida, até mesmo versões principais diferentes serão consideradas e, portanto, um aplicativo criado para o .NET Core 2.0.0 efetuará roll forward para o .NET Core 3.0.0.

Modifique essa configuração de uma das três maneiras:

  • Defina a variável de ambiente DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX com o valor desejado.

  • Adicione a seguinte linha com o valor desejado ao arquivo .runtimeconfig.json:

    "rollForwardOnNoCandidateFx" : 0

  • Ao usar o .NET Core CLI, adicione a seguinte opção com o valor desejado a um comando do .NET Core como run:

    dotnet run --rollForwardOnNoCandidateFx=0

O roll forward da versão de patch é independente dessa configuração e é feito após a aplicação de qualquer roll forward potencial da versão secundária ou principal.

Implantação

Serviço de aplicativo autocontido

dotnet publish agora publica aplicativos autocontidos com uma versão de runtime atendido. Quando você publica um aplicativo autocontido com o SDK do .NET Core 2.1 (v 2.1.300), seu aplicativo inclui a versão mais recente de runtime atendido conhecida por esse SDK. Quando você atualizar para o SDK mais recente, publicará com a versão mais recente de runtime do .NET Core. Isso se aplica aos runtimes do .NET Core 1.0 e posteriores.

A publicação autocontida depende de versões de runtime em NuGet.org. Você não precisa ter o runtime atendido no seu computador.

Com o uso do SDK do .NET Core 2.0, os aplicativos autocontidos são publicados com o runtime do .NET Core 2.0.0, a menos que uma versão diferente seja especificada por meio da propriedade RuntimeFrameworkVersion. Com esse novo comportamento, você não precisará mais definir essa propriedade para selecionar uma versão de runtime superior para um aplicativo autocontido. A abordagem mais fácil daqui para frente é sempre publicar com o SDK do .NET Core 2.1 (v 2.1.300).

Veja mais informações em Efetuar roll forward de runtime de implantação autossuficiente.

Pacote de Compatibilidade do Windows

Ao transmitir código existente do .NET Framework para o .NET Core, você pode usar o Pacote de Compatibilidade do Windows. Ele fornece acesso 20.000 APIs a mais do que as disponíveis no .NET Core. Essas APIs incluem tipos no namespace System.Drawing, a classe EventLog, WMI, contadores de desempenho, Windows Services e os tipos de registro e membros do Windows.

Melhorias do compilador JIT

O .NET Core incorpora uma nova tecnologia de compilador JIT chamada de compilação em camadas (também conhecida como otimização adaptativa) que pode melhorar significativamente o desempenho. A compilação em camadas é uma configuração opcional.

Uma das tarefas importantes executadas pelo compilador JIT é otimizar a execução de código. No entanto, para caminhos de código pouco usados, o compilador pode gastar mais tempo otimizando o código do que o runtime gasta executando código não otimizado. A compilação em camadas introduz dois estágios na compilação JIT:

  • Uma primeira camada, que gera código o mais rápido possível.

  • Uma segunda camada, que gera código otimizado para os métodos executados com frequência. A segunda camada de compilação é executada em paralelo para melhorar o desempenho.

Você pode optar pela compilação em camadas de duas maneiras.

  • Para usar a compilação em camadas em todos os projetos que usam o SDK do .NET Core 2.1, defina a seguinte variável de ambiente:

    COMPlus_TieredCompilation="1"

  • Para usar a compilação em camadas por projeto, adicione a propriedade <TieredCompilation> à seção <PropertyGroup> do arquivo de projeto MSBuild, como mostra o exemplo a seguir:

    <PropertyGroup>
    <!-- other property definitions -->

    <TieredCompilation>true</TieredCompilation>
</PropertyGroup>

Alterações de API

Span<T> e Memory<T>

O .NET Core 2.1 inclui alguns novos tipos de tornam o trabalho com matrizes e outros tipos de memória muito mais eficiente. Os novos tipos incluem:

Sem esses tipos, ao transmitir esses itens como parte de uma matriz ou seção de um buffer de memória, você precisará fazer uma cópia de uma parte dos dados antes de transmiti-los a um método. Esses tipos fornecem uma visão virtual desses dados, o que elimina a necessidade de alocação de memória adicional e operações de cópia.

O exemplo a seguir usa uma instância Span<T> e Memory<T> para fornecer uma visão virtual de 10 elementos de uma matriz.

using System;

class Program
{
    static void Main()
    {
        int[] numbers = new int[100];
        for (int i = 0; i < 100; i++)
        {
            numbers[i] = i * 2;
        }

        var part = new Span<int>(numbers, start: 10, length: 10);
        foreach (var value in part)
            Console.Write($"{value}  ");
    }
}
// The example displays the following output:
//     20  22  24  26  28  30  32  34  36  38

Module Program
    Sub Main()
        Dim numbers As Integer() = New Integer(99) {}

        For i As Integer = 0 To 99
            numbers(i) = i * 2
        Next

        Dim part = New Memory(Of Integer)(numbers, start:=10, length:=10)

        For Each value In part.Span
            Console.Write($"{value}  ")
        Next
    End Sub
End Module
' The example displays the following output:
'     20  22  24  26  28  30  32  34  36  38

Compactação Brotli

O .NET Core 2.1 adiciona suporte para compactação e descompactação Brotli. Brotli é um algoritmo de compactação sem perda, de uso geral, que é definido em RFC 7932 e é compatível com a maioria dos navegadores da Web e com os principais servidores Web. Você pode usar a classe System.IO.Compression.BrotliStream baseada em fluxo ou as classes System.IO.Compression.BrotliEncoder e System.IO.Compression.BrotliDecoder baseadas em span de alto desempenho. O exemplo a seguir ilustra a compactação com a classe BrotliStream:

public static Stream DecompressWithBrotli(Stream toDecompress)
{
    MemoryStream decompressedStream = new MemoryStream();
    using (BrotliStream decompressionStream = new BrotliStream(toDecompress, CompressionMode.Decompress))
    {
        decompressionStream.CopyTo(decompressedStream);
    }
    decompressedStream.Position = 0;
    return decompressedStream;
}

Public Function DecompressWithBrotli(toDecompress As Stream) As Stream
    Dim decompressedStream As New MemoryStream()
    Using decompressionStream As New BrotliStream(toDecompress, CompressionMode.Decompress)
        decompressionStream.CopyTo(decompressedStream)
    End Using
    decompressedStream.Position = 0
    Return decompressedStream
End Function

O comportamento BrotliStream é o mesmo de DeflateStream e GZipStream, o que facilita a conversão de código que chame essas APIs para BrotliStream.

Novas APIs de criptografia e aprimoramentos de criptografia

O .NET Core 2.1 inclui vários aprimoramentos para a APIs de criptografia:

Aperfeiçoamentos de soquetes

O .NET Core inclui um novo tipo, System.Net.Http.SocketsHttpHandler, e um System.Net.Http.HttpMessageHandler reescrito, que formam a base de APIs de rede de nível superior. System.Net.Http.SocketsHttpHandler, por exemplo, é a base da implementação HttpClient. Nas versões anteriores do .NET Core, as APIs de nível superior eram baseadas em implementações de redes nativas.

A implementação de soquetes introduzida no .NET Core 2.1 tem várias vantagens:

  • Uma melhoria de desempenho significativa quando comparada com a implementação anterior.

  • Eliminação das dependências da plataforma, o que simplifica a implantação e a manutenção.

  • Comportamento consistente em todas as plataformas .NET Core.

SocketsHttpHandler é a implementação padrão do .NET Core 2.1. No entanto, você pode configurar seu aplicativo para usar a classe HttpClientHandler mais antiga chamando o método AppContext.SetSwitch:

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", False)

Também é possível usar uma variável de ambiente para desativar o uso de implementações de soquetes com base em SocketsHttpHandler. Para fazer isso, defina DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER para false ou 0.

No Windows, você também pode escolher usar System.Net.Http.WinHttpHandler, que depende de uma implementação nativa, ou a classe SocketsHttpHandler transmitindo uma instância da classe para o construtor HttpClient.

No Linux e no macOS, só é possível configurar HttpClient por processo. No Linux, você precisa implantar libcurl se quiser usar a implementação HttpClient antiga. (Ele é instalado com .NET Core 2.0.)

Alterações da falha

Para obter informações sobre alterações interruptivas, confira Alterações interruptivas para a migração da versão 2.0 para a 2.1.

Confira também