O que há de novo no SDK e nas ferramentas do .NET 8

Este artigo descreve novos recursos no SDK do .NET e ferramentas para .NET 8.

SDK

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

• Avaliação de projetos baseada na CLI
• Saída de construção do terminal
• Caminhos de saída simplificados
• Comando 'dotnet workload clean'
• Ativos 'dotnet publish' e 'dotnet pack'
• Mecanismo de modelo
• Link de origem
• SDK de compilação de origem

Avaliação de projetos baseada na 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 dotnet publishing , para obter dados para uso em pipelines de CI e em outros lugares.

Sinalizador	Description
--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 são gerados como 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 construção do terminal

dotnet build tem uma nova opção para produzir resultados de construção mais modernizados. Essa saída do registrador de terminais agrupa erros com o projeto de onde vieram, diferencia melhor as diferentes estruturas de destino para projetos com vários destinos e fornece informações em tempo real sobre o que a compilação está fazendo. Para optar pela nova saída, use a --tl opção. Para obter mais informações sobre essa opção, consulte dotnet build options.

Caminhos de saída simplificados

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

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

Comando dotnet workload clean

O .NET 8 introduz um novo comando para limpar pacotes de carga de trabalho que podem sobrar por meio de várias atualizações do .NET SDK 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 para o pacote 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 na máquina que são do tipo de instalação de carga de trabalho SDK atual (e isso não é do Visual Studio). Ele também remove todos os registros de instalação de carga de trabalho para a banda de recursos do SDK do .NET em execução e abaixo.

dotnet publish e dotnet pack ativos

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

A saída a seguir mostra o comportamento diferente entre dotnet build e e dotnet publishcomo você pode reverter para ativos de publicação Debug definindo a PublishRelease propriedade 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, consulte 'dotnet pack' usa Release config e 'dotnet publish' usa Release config.

dotnet restore Auditoria de Segurança

A partir do .NET 8, você pode optar por verificações de segurança para vulnerabilidades conhecidas quando os pacotes de dependência forem 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 comunicado para obter mais detalhes. Quando você executa dotnet add ou dotnet restore, avisos NU1901-NU1904 aparecerão para quaisquer vulnerabilidades encontradas. Para obter mais informações, consulte Auditoria de 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. Os melhoramentos incluem:

• Evite o download de pacotes de http:// feeds por padrão. Por exemplo, o comando a seguir falhará ao 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"

  Você pode substituir essa limitação usando o --force sinalizador.

• Para dotnet new, dotnet new installe dotnet new update, verifique se há vulnerabilidades conhecidas no pacote de modelos. Se forem encontradas vulnerabilidades e você quiser continuar, você deve usar a --force bandeira.

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

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

Link de origem

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

Nota

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

SDK de compilação de origem

O SDK construído para distribuição Linux (source-build) agora tem a capacidade de criar aplicativos independentes usando os pacotes de tempo de execução source-build. O pacote de tempo de execução específico da distribuição é empacotado com o SDK de compilação de origem. Durante a implantação independente, esse pacote de tempo de execução incluído será referenciado, habilitando assim o recurso para os usuários.

Suporte nativo a AOT

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 tempo de execução — tudo é incluído em um único arquivo. O .NET 8 traz as seguintes melhorias para a publicação AOT nativa:

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

• Reduz os tamanhos dos aplicativos AOT nativos no Linux em até 50%. A tabela a seguir mostra o tamanho de um aplicativo "Hello World" publicado com AOT nativo que inclui todo o tempo de execução do .NET no .NET 7 vs. .NET 8:

  Sistema operativo	.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 enquanto está ciente do tamanho do aplicativo. No entanto, você pode usar a <OptimizationPreference> propriedade MSBuild para otimizar especificamente para um ou outro. Para obter mais informações, consulte Otimizar implantações de 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 dotnet publish ou Visual Studio.
• Permite analisadores de compatibilidade para corte, AOT e arquivo único. Estes analisadores alertam-no para partes potencialmente problemáticas do seu projeto (se existirem).
• Permite a emulação de AOT em tempo de depuração para que, ao depurar seu projeto sem compilação AOT, você 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 quando tentar publicar o projeto com AOT.

Segmente plataformas semelhantes ao iOS com AOT nativo

O .NET 8 inicia o trabalho para habilitar o suporte AOT nativo para plataformas semelhantes ao iOS. Agora você pode criar 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 no disco diminui em cerca de 35% para aplicativos .NET iOS que usam AOT nativo em vez de Mono. O tamanho do aplicativo no disco para aplicativos .NET MAUI iOS diminui 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, consulte a postagem do blog Melhorias de desempenho do .NET 8 no .NET MAUI.

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

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

Quando você define a propriedade necessária e executa dotnet publish como mostrado no exemplo a seguir, o aplicativo será implantado usando 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 a AOT nativa. Da mesma forma, nem todas as bibliotecas comumente usadas no iOS são compatíveis com o NativeAOT. E, além das limitações existentes da implantação de AOT nativo, a lista a seguir mostra algumas das outras limitações ao segmentar plataformas semelhantes ao iOS:

• O uso da AOT nativa só é habilitado durante a implantação do aplicativo (dotnet publish).
• A depuração de código gerenciado só é suportada 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 destinados ao Android usam o modo de compilação AOT (profiled ahead-of-time) quando são criados no modo de versão. A compilação AOT com perfil afeta menos métodos do que a compilação AOT regular. O .NET 8 apresenta a propriedade que permite que você opte por mais compilação AOT para aplicativos Android para diminuir ainda mais o <AndroidStripILAfterAOT> 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 que foram compilados pela AOT sejam cortados. Você também pode usar AOT e IL com perfil juntos definindo explicitamente ambas as propriedades como true:

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

Aplicativos do Windows criados entre si

Quando você cria aplicativos destinados ao Windows em plataformas que não são do Windows, o executável resultante agora é atualizado com quaisquer recursos Win32 especificados — por exemplo, ícone de 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 de construção cruzada tem sido uma solicitação popular, pois era um ponto problemático significativo que afetava a complexidade da infraestrutura e o uso de recursos.

.NET no Linux

Linhas de base mínimas de suporte para Linux

As linhas de base de suporte mínimo para Linux foram atualizadas para .NET 8. O .NET é construído visando o Ubuntu 16.04, para todas as arquiteturas. Isso é importante principalmente para definir a versão mínima glibc do .NET 8. O .NET 8 falhará ao iniciar em versões de distribuição que incluam um glibc mais antigo, como o Ubuntu 14.04 ou o Red Hat Enterprise Linux 7.

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

Crie seu próprio .NET no Linux

Em versões anteriores do .NET, você podia criar o .NET a partir do código-fonte, mas era necessário criar um "tarball de origem" a partir da confirmação de repositório dotnet/installer que correspondia a uma versão. No .NET 8, isso não é mais necessário e você pode criar o .NET no Linux diretamente do repositório dotnet/dotnet . Esse repositório usa dotnet/source-build para criar tempos de execução, ferramentas e SDKs do .NET. Esta é a mesma compilação que a Red Hat e a Canonical usam para criar o .NET.

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

Verificação de assinatura NuGet

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

A maioria dos usuários não deve notar 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 pelo aviso NU3042.

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

Análise de código

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

ID da Regra	Categoria	Description
CA1856	Desempenho	É acionado quando o ConstantExpectedAttribute atributo 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 chamar String.IndexOf e, em seguida, comparar o resultado com zero.
CA1859	Desempenho	Esta 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 algum elemento, é melhor usar Length, Countou IsEmpty do que chamar Enumerable.Any.
CA1861	Desempenho	Matrizes constantes passadas como argumentos não são reutilizadas quando chamadas repetidamente, o que implica que uma nova matriz é criada a cada vez. Para melhorar o desempenho, considere extrair a matriz para um campo estático somente leitura.
CA1865-CA1867	Desempenho	A sobrecarga char é uma sobrecarga de melhor desempenho para uma string com um único char.
CA2021	Fiabilidade	Enumerable.Cast<TResult>(IEnumerable) e Enumerable.OfType<TResult>(IEnumerable) requerem tipos compatíveis para funcionar corretamente. A ampliação e as conversões definidas pelo usuário não são suportadas com tipos genéricos.
CA1510-CA1513	Capacidade de Manutenção	Os auxiliares de lançamento são mais simples e eficientes do que um if bloco construindo uma nova instância de exceção. Esses quatro analisadores foram criados para as seguintes exceções: ArgumentNullException, ArgumentExceptionArgumentOutOfRangeException e ObjectDisposedException.

Diagnóstico

O C# Hot Reload suporta a modificação de genéricos

A partir do .NET 8, o C# Hot Reload oferece suporte à modificação de tipos e métodos genéricos. Ao depurar aplicativos de console, desktop, dispositivos móveis ou WebAssembly com o Visual Studio, você pode aplicar alterações a classes genéricas e métodos genéricos em código C# ou páginas Razor. Para obter mais informações, consulte a lista completa de edições suportadas por Roslyn.

Consulte também

• O que há de novo no .NET 8