Share via

Novidades do SDK e das ferramentas do .NET 8

  • Artigo

Este artigo descreve os novos recursos do SDK do .NET e as ferramentas do .NET 8.

.

Esta seção contém os seguintes subtópicos:

Avaliação de projeto baseados em CLI

O MSBuild inclui um novo recurso que facilita a incorporação de dados do MSBuild em seus scripts ou ferramentas. Os novos sinalizadores a seguir estão disponíveis para comandos da CLI, como o dotnet publish, para obter dados para uso em pipelines de CI e em outros lugares.

Sinalizador Descrição
--getProperty:<PROPERTYNAME> Recupera a propriedade MSBuild com o nome especificado.
--getItem:<ITEMTYPE> Recupera itens do MSBuild do tipo especificado.
--getTargetResults:<TARGETNAME> Recupera as saídas da execução do destino especificado.

Os valores são gravados na saída padrão. Valores múltiplos ou complexos têm saída JSON, conforme mostrado nos exemplos a seguir.

>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\

>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
{
  "Properties": {
    "GeneratedContainerDigest": "sha256:ef880a503bbabcb84bbb6a1aa9b41b36dc1ba08352e7cd91c0993646675174c4",
    "GeneratedContainerConfiguration": "{\u0022config\u0022:{\u0022ExposedPorts\u0022:{\u00228080/tcp\u0022:{}},\u0022Labels\u0022...}}"
  }
}

>dotnet publish -p PublishProfile=DefaultContainer --getItem:ContainerImageTags
{
  "Items": {
    "ContainerImageTags": [
      {
        "Identity": "latest",
        ...
    ]
  }
}

Saída de build do terminal

O dotnet build tem uma nova opção para produzir uma saída de build mais modernizada. Essa saída do agente de terminal agrupa erros com o projeto de onde eles vieram, diferencia melhor as estruturas de destino para projetos de vários destinos e fornece informações em tempo real sobre o que o build está fazendo. Para aceitar a nova saída, use a opção --tl. Para obter mais informações sobre essa opção, confira opções de build dotnet.

Caminhos de saída simplificados

O .NET 8 apresenta uma opção para simplificar o caminho de saída e a estrutura de pastas para saídas de build. Anteriormente, aplicativos .NET produziam um conjunto profundo e complexo de caminhos de saída para diferentes artefatos de build. A nova estrutura de caminho de saída simplificada reúne todas as saídas de build em um local comum, o que facilita a previsão pelas ferramentas.

Para obter mais informações, confira Layout de saída de artefatos.

Comando dotnet workload clean

O .NET 8 apresenta um novo comando para limpar pacotes de carga de trabalho que podem ser deixados por várias atualizações do SDK do .NET ou do Visual Studio. Se você encontrar problemas ao gerenciar cargas de trabalho, considere usar workload clean para restaurar com segurança para um estado conhecido antes de tentar novamente. O comando tem dois modos:

  • dotnet workload clean

    Executa a coleta de lixo de carga de trabalho para cargas de trabalho baseadas em arquivo ou MSI, o que limpa pacotes órfãos. Os pacotes órfãos são de versões desinstaladas do SDK do .NET ou pacotes em que os registros de instalação não existem mais.

    Se o Visual Studio estiver instalado, o comando também listará todas as cargas de trabalho que você deve limpar manualmente usando o Visual Studio.

  • dotnet workload clean --all

    Esse modo é mais agressivo e limpa todos os pacotes no computador do tipo de instalação de carga de trabalho atual do SDK (que não é do Visual Studio). Ele também remove todos os registros de instalação de carga de trabalho para a faixa de recursos do SDK do .NET em execução e abaixo.

Ativos dotnet publish e dotnet pack

Como os comandos dotnet publish e dotnet pack destinam-se a produzir ativos de produção, eles agora produzem ativos Release por padrão.

A saída a seguir mostra o comportamento diferente entre dotnet build e dotnet publish, e como você pode revertê-lo para ativos Debug de publicação definindo a propriedade PublishRelease como false.

/app# dotnet new console
/app# dotnet build
  app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
  app -> /app/bin/Release/net8.0/app.dll
  app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
  app -> /app/bin/Debug/net8.0/app.dll
  app -> /app/bin/Debug/net8.0/publish/

Para obter mais informações, confira 'dotnet pack' usa configuração de versão e 'dotnet publish' usa configuração de versão.

Auditoria de segurança do dotnet restore

A partir do .NET 8, você pode optar por verificações de segurança para vulnerabilidades conhecidas quando os pacotes de dependência são restaurados. Essa auditoria produz um relatório de vulnerabilidades de segurança com o nome do pacote afetado, a gravidade da vulnerabilidade e um link para o aviso para obter mais detalhes. Quando você executar dotnet add ou dotnet restore, os avisos NU1901-NU1904 serão exibidos para quaisquer vulnerabilidades encontradas. Para obter mais informações, confira Auditar vulnerabilidades de segurança.

Mecanismo de modelo

O mecanismo de modelo fornece uma experiência mais segura no .NET 8 integrando alguns dos recursos relacionados à segurança do NuGet. As melhorias incluem:

  • Evite baixar pacotes de feeds http:// por padrão. Por exemplo, o comando a seguir não instalará o pacote de modelo porque a URL de origem não usa HTTPS.

    dotnet new install console --add-source "http://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json"

    É possível substituir essa limitação usando-se o sinalizador --force.

  • Para dotnet new, dotnet new install e dotnet new update, verifique se há vulnerabilidades conhecidas no pacote de modelo. Se forem encontradas vulnerabilidades e você quiser continuar, use o sinalizador --force.

  • Para dotnet new, forneça informações sobre o proprietário do pacote de modelo. A propriedade é verificada pelo portal do NuGet e pode ser considerada uma característica confiável.

  • Para dotnet search e dotnet uninstall, indique se um modelo está instalado de um pacote "confiável", ou seja, ele usa um prefixo reservado.

O Source Link agora está incluído no SDK do .NET. A meta é que, agrupando o Source Link no SDK, em vez de exigir um <PackageReference> separado para o pacote, mais pacotes incluirão essas informações por padrão. Essas informações melhorarão a experiência do IDE para desenvolvedores.

Observação

Como efeito colateral dessa alteração, as informações de confirmação são incluídas no valor InformationalVersion de bibliotecas e aplicativos criados, mesmo aqueles destinados ao .NET 7 ou a uma versão anterior. Para obter mais informações, consulte Source Link incluído no SDK do .NET.

SDK do build de origem

O SDK da distribuição do Linux (build de origem) agora tem a capacidade de criar aplicativos autossuficientes usando os pacotes de runtime de build de origem. O pacote de runtime específico da distribuição é agrupado com o SDK do build de origem. Durante a implantação autocontida, esse pacote de runtime empacotado será referenciado, habilitando assim o recurso para os usuários.

Suporte a AOT nativo

A opção de publicar como AOT nativo foi introduzida pela primeira vez no .NET 7. A publicação de um aplicativo com AOT nativo cria uma versão totalmente independente do seu aplicativo que não precisa de um runtime, já que tudo está incluso em um arquivo. O .NET 8 traz as seguintes melhorias para a publicação nativa de AOT:

  • Adiciona suporte para as arquiteturas x64 e Arm64 no macOS.

  • Reduz os tamanhos de aplicativos AOT nativos no Linux em até 50%. A tabela a seguir mostra o tamanho de um aplicativo "Olá, Mundo" publicado com AOT nativo que inclui todo o runtime do .NET no .NET 7 em relação ao .NET 8:

    Sistema operacional .NET 7 .NET 8
    Linux x64 (com -p:StripSymbols=true) 3,76 MB 1,84 MB
    Windows x64 2,85 MB 1,77 MB

  • Permite especificar uma preferência de otimização: tamanho ou velocidade. Por padrão, o compilador escolhe gerar código rápido estando atento ao tamanho do aplicativo. No entanto, você pode usar a propriedade MSBuild <OptimizationPreference> para otimizar especificamente para um ou outro. Para obter mais informações, confira Otimizar implantações do AOT.

Modelo de aplicativo de console

O modelo de aplicativo de console padrão agora inclui suporte para AOT pronto para uso. Para criar um projeto configurado para compilação AOT, basta executar dotnet new console --aot. A configuração do projeto adicionada por --aot tem três efeitos:

  • Gera um executável autônomo nativo com AOT nativo quando você publica o projeto, por exemplo, com o dotnet publish ou Visual Studio.
  • Habilita analisadores de compatibilidade para corte, AOT e arquivo único. Esses analisadores alertam você para partes potencialmente problemáticas do seu projeto (se houver alguma).
  • Habilita a emulação de tempo de depuração do AOT para que, quando você depurar seu projeto sem compilação AOT, obtenha uma experiência semelhante à AOT. Por exemplo, se você usar System.Reflection.Emit em um pacote NuGet que não foi anotado para AOT (e, portanto, foi perdido pelo analisador de compatibilidade), a emulação significa que você não terá surpresas ao tentar publicar o projeto com a AOT.

Focar em plataformas semelhantes a iOS com AOT nativo

O .NET 8 inicia o trabalho para habilitar o suporte do AOT nativo para plataformas semelhantes a iOS. Agora você pode compilar e executar aplicativos .NET iOS e .NET MAUI com AOT nativo nas seguintes plataformas:

  • ios
  • iossimulator
  • maccatalyst
  • tvos
  • tvossimulator

Testes preliminares mostram que o tamanho do aplicativo em disco diminui cerca de 35% para os aplicativos .NET iOS que usam o AOT nativo em vez do Mono. O tamanho do aplicativo em disco para os aplicativos .NET MAUI iOS diminui em até 50%. Além disso, o tempo de inicialização também é mais rápido. Os aplicativos .NET iOS têm um tempo de inicialização cerca de 28% mais rápido, enquanto os aplicativos .NET MAUI iOS têm um desempenho de inicialização cerca de 50% melhor em comparação com o Mono. O suporte ao .NET 8 é experimental e apenas a primeira etapa para o recurso como um todo. Para obter mais informações, confira a postagem no blog Aprimoramentos de desempenho do .NET 8 no .NET MAUI.

O suporte AOT nativo está disponível como um recurso de aceitação destinado à implantação do aplicativo; o Mono ainda é o runtime padrão para desenvolvimento e implantação de aplicativos. Para compilar e executar um aplicativo MAUI do .NET com AOT nativo em um dispositivo iOS, use dotnet workload install maui para instalar a carga de trabalho MAUI do .NET e dotnet new maui -n HelloMaui para criar o aplicativo. Em seguida, defina a propriedade PublishAot do MSBuild como true no arquivo de projeto.

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

Quando você definir a propriedade obrigatória e executar dotnet publish conforme mostrado no exemplo a seguir, o aplicativo será implantado por meio do AOT nativo.

dotnet publish -f net8.0-ios -c Release -r ios-arm64  /t:Run

Limitações

Nem todos os recursos do iOS são compatíveis com o AOT nativo. Da mesma forma, nem todas as bibliotecas comumente usadas no iOS são compatíveis com o NativeAOT. Além das limitações existentes na implantação nativa do AOT, a lista a seguir mostra algumas das outras limitações ao focar em plataformas semelhantes a iOS:

  • O uso de AOT nativo só é habilitado durante a implantação do aplicativo (dotnet publish).
  • A depuração de código gerenciado só tem suporte com Mono.
  • A compatibilidade com a estrutura .NET MAUI é limitada.

Compilação AOT para aplicativos Android

Para diminuir o tamanho do aplicativo, os aplicativos .NET e .NET MAUI voltados para o Android usam o modo de compilação AOT (ahead-of-time) com perfil quando são criados no modo Release. A compilação AOT com perfil afeta menos métodos do que a compilação AOT regular. O .NET 8 apresenta a propriedade <AndroidStripILAfterAOT> que permite que você opte pela compilação AOT adicional para aplicativos Android para diminuir ainda mais o tamanho do aplicativo.

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>

Por padrão, a configuração AndroidStripILAfterAOT para true substituir a configuração padrão AndroidEnableProfiledAot, permitindo que (quase) todos os métodos compilados por AOT sejam cortados. Você também pode usar a remoção de perfil de AOT e IL definindo explicitamente ambas as propriedades como true:

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
  <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

Aplicativos do Windows integrados

Quando você cria aplicativos destinados ao Windows em plataformas que não são do Windows, o executável resultante agora é atualizado com todos os recursos—do Win32 especificados, por exemplo, ícone do aplicativo, manifesto, informações de versão.

Anteriormente, os aplicativos tinham que ser criados no Windows para ter esses recursos. Corrigir essa lacuna no suporte entre construções tem sido uma solicitação popular, pois foi um ponto de dor significativo que afeta a complexidade da infraestrutura e o uso de recursos.

.NET no Linux

Linhas de base de suporte mínimas para Linux

As linhas de base de suporte mínimas para Linux foram atualizadas para o .NET 8. O .NET é criado visando o Ubuntu 16.04, para todas as arquiteturas. Isso é importante principalmente para definir a versão mínima de glibc para o .NET 8. O .NET 8 não será iniciado em versões de distribuição que incluem um glibc mais antigo, como o Ubuntu 14.04 ou o Red Hat Enterprise Linux 7.

Para obter mais informações, confira Suporte à família Red Hat Enterprise Linux.

Compilar o próprio .NET no Linux

Em versões anteriores do .NET, você poderia compilar o .NET por meio da origem, mas isso exigia a criação de um "tarball de origem" do commit do repositório dotnet/installer que correspondia a uma versão. No .NET 8, isso não é mais necessário e você pode compilar o .NET no Linux diretamente no repositório dotnet/dotnet. Esse repositório usa dotnet/source-build para compilar runtimes, ferramentas e SDKs do .NET. Esse é o mesmo build que o Red Hat e a Canonical usam para compilar o .NET.

A compilação em um contêiner é a abordagem mais fácil para a maioria das pessoas, já que as imagens de contêiner dotnet-buildtools/prereqs contêm todas as dependências necessárias. Para obter mais informações, confira as instruções de build.

Verificação de assinatura do NuGet

A partir do .NET 8, o NuGet verifica os pacotes assinados no Linux por padrão. O NuGet continua a verificar os pacotes assinados no Windows também.

A maioria dos usuários não deve observar a verificação. No entanto, se você tiver um pacote de certificado raiz existente localizado em /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem, poderá ver falhas de confiança acompanhadas do aviso NU3042.

Você pode recusar a verificação definindo a variável de ambiente DOTNET_NUGET_SIGNATURE_VERIFICATION como false.

Análise de código

O .NET 8 inclui vários novos analisadores de código e reparadores para ajudar a verificar se você está usando APIs de biblioteca do .NET de maneira correta e eficiente. A tabela a seguir resume os novos analisadores.

ID da regra Categoria Descrição
CA1856 Desempenho É acionado quando o atributo ConstantExpectedAttribute não é aplicado corretamente em um parâmetro.
CA1857 Desempenho É acionado quando um parâmetro é anotado com ConstantExpectedAttribute, mas o argumento fornecido não é uma constante.
CA1858 Desempenho Para determinar se uma cadeia de caracteres começa com um determinado prefixo, é melhor chamar String.StartsWith do que String.IndexOf e comparar o resultado com zero.
CA1859 Desempenho Essa regra recomenda atualizar o tipo de variáveis locais específicas, campos, propriedades, parâmetros de método e tipos de retorno de método de tipos de interface ou abstratos para tipos concretos quando possível. O uso de tipos concretos leva a um código gerado de maior qualidade.
CA1860 Desempenho Para determinar se um tipo de coleção tem elementos, é melhor usar Length, Count ou IsEmpty do que chamar Enumerable.Any.
CA1861 Desempenho Matrizes constantes passadas como argumentos não são reutilizados quando chamados repetidamente, o que implica que uma nova matriz é criada a cada vez. Para aprimorar o desempenho, extraia a matriz para um campo estático somente leitura.
CA1865-CA1867 Desempenho A sobrecarga de char é uma sobrecarga de melhor desempenho para uma cadeia de caracteres com um único char.
CA2021 Confiabilidade Enumerable.Cast<TResult>(IEnumerable) e Enumerable.OfType<TResult>(IEnumerable) exigem tipos compatíveis para funcionar corretamente. Não há suporte para a ampliação e conversões definidas pelo usuário com tipos genéricos.
CA1510-CA1513 Facilidade de manutenção Auxiliares de lançamento são mais simples e eficientes do que um bloco if que constrói uma nova instância de exceção. Esses quatro analisadores foram criados para as seguintes exceções: ArgumentNullException, ArgumentException, ArgumentOutOfRangeException e ObjectDisposedException.

Diagnósticos

A Recarga Dinâmica do C# dá suporte para a modificação de genéricos

Iniciando no .NET 8, a Recarga Dinâmica do C# dá suporte para a modificação de tipos genéricos e métodos genéricos. Ao depurar aplicativos de console, área de trabalho do Windows, aplicativos para dispositivos móveis ou WebAssembly com o Visual Studio, será possível aplicar alterações a classes e métodos genéricos no código C# ou nas páginas do Razor. Para obter mais informações, confira a lista completa de edições com suporte do Roslyn.

Confira também