.NET Standard

  • Artigo

O .NET Standard é uma especificação formal de APIs do .NET que estão disponíveis em várias implementações do .NET. A motivação por trás do .NET Standard era estabelecer uma maior uniformidade no ecossistema .NET. O .NET 5 e versões posteriores adotam uma abordagem diferente para estabelecer uniformidade que elimina a necessidade do .NET Standard na maioria dos cenários. No entanto, se você quiser compartilhar código entre o .NET Framework e qualquer outra implementação do .NET, como o .NET Core, sua biblioteca deve ter como destino o .NET Standard 2.0. Nenhuma nova versão do .NET Standard será lançada, mas o .NET 5 e todas as versões posteriores continuarão a oferecer suporte ao .NET Standard 2.1 e versões anteriores.

Para obter informações sobre como escolher entre .NET 5+ e .NET Standard, consulte .NET 5+ e .NET Standard mais adiante neste artigo.

Versões do .NET Standard

O .NET Standard tem versão. Cada nova versão adiciona mais APIs. Quando uma biblioteca é criada em relação a uma determinada versão do .NET Standard, ela pode ser executada em qualquer implementação do .NET que implemente essa versão do .NET Standard (ou superior).

O direcionamento de uma versão superior do .NET Standard permite que uma biblioteca use mais APIs, mas significa que ela só pode ser usada em versões mais recentes do .NET. A segmentação de uma versão inferior reduz as APIs disponíveis, mas significa que a biblioteca pode ser executada em mais locais.

Selecione a versão padrão do .NET

O .NET Standard 1.0 tem 7.949 das 37.118 APIs disponíveis.

Implementação .NET Suporte da versão
.NET e .NET Core 1.0, 1.1, 2.0, 2.1, 2.2, 3.0, 3.1, 5.0, 6.0, 7.0, 8.0
.NET Framework 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1
Mono 4.6, 5.4, 6.4
Xamarin.iOS 10.0, 10.14, 12.16
Xamarin.Mac 3.0, 3.8, 5.16
Xamarin.Android 7.0, 8.0, 10.0
Plataforma Universal do Windows 8.0, 8.1, 10.0, 10.0.16299, TBD
Unity 2018.1

Para obter mais informações, consulte .NET Standard 1.0. Para obter uma tabela interativa, consulte Versões do .NET Standard.

Qual versão do .NET Standard destinar

Recomendamos que você tenha como destino o .NET Standard 2.0, a menos que precise oferecer suporte a uma versão anterior. A maioria das bibliotecas de uso geral não deve precisar de APIs fora do .NET Standard 2.0. O .NET Standard 2.0 é suportado por todas as plataformas modernas e é a maneira recomendada de oferecer suporte a várias plataformas com um destino.

Se você precisar oferecer suporte ao .NET Standard 1.x, recomendamos que você também direcione o .NET Standard 2.0. O .NET Standard 1.x é distribuído como um conjunto granular de pacotes NuGet, o que cria um grande gráfico de dependência de pacotes e faz com que os desenvolvedores baixem muitos pacotes durante a criação. Para obter mais informações, consulte Direcionamento entre plataformas e .NET 5+ e .NET Standard mais adiante neste artigo.

Regras de controle de versão do .NET Standard

Há duas regras principais de controle de versão:

  • Aditivo: as versões padrão do .NET são círculos logicamente concêntricos: as versões superiores incorporam todas as APIs das versões anteriores. Não há alterações de quebra entre as versões.
  • Imutável: Uma vez enviadas, as versões do .NET Standard são congeladas.

Não haverá novas versões do .NET Standard após a 2.1. Para obter mais informações, consulte .NET 5+ e .NET Standard mais adiante neste artigo.

Especificação

A especificação .NET Standard é um conjunto padronizado de APIs. A especificação é mantida por implementadores .NET, especificamente Microsoft (inclui .NET Framework, .NET Core e Mono) e Unity.

Artefatos oficiais

A especificação oficial é um conjunto de arquivos .cs que definem as APIs que fazem parte do padrão. O diretório ref no repositório dotnet/standard (agora arquivado) define as APIs padrão do .NET.

O metapacote NETStandard.Library (origem) descreve o conjunto de bibliotecas que definem (em parte) uma ou mais versões do .NET Standard.

Um determinado componente, como System.Runtime, descreve:

  • Parte do .NET Standard (apenas seu escopo).
  • Várias versões do .NET Standard, para esse escopo.

Artefatos derivados são fornecidos para permitir uma leitura mais conveniente e para habilitar determinados cenários de desenvolvedor (por exemplo, usando um compilador).

Representação do pacote

O principal veículo de distribuição para os assemblies de referência do .NET Standard são os pacotes NuGet. As implementações são entregues de várias maneiras, apropriadas para cada implementação do .NET.

Os pacotes NuGet destinam-se a uma ou mais estruturas. Os pacotes do .NET Standard destinam-se à estrutura ".NET Standard". Você pode direcionar a estrutura .NET Standard usando o TFM compacto netstandard(por exemplo, netstandard1.4). As bibliotecas que se destinam a ser executadas em várias implementações do .NET devem ter como alvo essa estrutura. Para o conjunto mais amplo de APIs, o destino netstandard2.0 já que o número de APIs disponíveis mais do que dobrou entre o .NET Standard 1.6 e 2.0.

O NETStandard.Library metapacote faz referência ao conjunto completo de pacotes NuGet que definem o .NET Standard. A maneira mais comum de segmentar netstandard é fazendo referência a este metapacote. Ele descreve e fornece acesso às ~40 bibliotecas .NET e APIs associadas que definem o .NET Standard. Você pode fazer referência a pacotes adicionais destinados netstandard a obter acesso a APIs adicionais.

Controlo de Versão

A especificação não é singular, mas um conjunto linearmente versionado de APIs. A primeira versão do padrão estabelece um conjunto de linha de base de APIs. As versões subsequentes adicionam APIs e herdam APIs definidas por versões anteriores. Não há nenhuma disposição estabelecida para remover APIs do Padrão.

O .NET Standard não é específico para nenhuma implementação do .NET, nem corresponde ao esquema de controle de versão de qualquer uma dessas implementações.

Como observado anteriormente, não haverá novas versões do .NET Standard após a 2.1.

Padrão .NET de destino

Você pode criar bibliotecas padrão do .NET usando uma combinação da netstandard estrutura e do NETStandard.Library metapacote.

Modo de compatibilidade do .NET Framework

A partir do .NET Standard 2.0, o modo de compatibilidade do .NET Framework foi introduzido. Esse modo de compatibilidade permite que projetos do .NET Standard façam referência a bibliotecas do .NET Framework como se fossem compiladas para o .NET Standard. A referência a bibliotecas do .NET Framework não funciona para todos os projetos, como bibliotecas que usam APIs do Windows Presentation Foundation (WPF).

Para obter mais informações, consulte Modo de compatibilidade do .NET Framework.

Bibliotecas do .NET Standard e Visual Studio

Para criar bibliotecas do .NET Standard no Visual Studio, verifique se você tem o Visual Studio 2022, Visual Studio 2019 ou Visual Studio 2017 versão 15.3 ou posterior instalado no Windows ou o Visual Studio para Mac versão 7.1 ou posterior instalado no macOS.

Se você só precisa consumir bibliotecas do .NET Standard 2.0 em seus projetos, você também pode fazer isso no Visual Studio 2015. No entanto, você precisa do cliente NuGet 3.6 ou superior instalado. Você pode baixar o cliente NuGet para Visual Studio 2015 na página de downloads do NuGet.

.NET 5+ e .NET Standard

.NET 5, .NET 6, .NET 7 e .NET 8 são produtos únicos com um conjunto uniforme de recursos e APIs que podem ser usados para aplicativos de área de trabalho do Windows e aplicativos de console de plataforma cruzada, serviços de nuvem e sites. Os TFMs do .NET 8, por exemplo, refletem essa ampla gama de cenários:

  • net8.0

    Este TFM é para código que é executado em todos os lugares. Com algumas exceções, inclui apenas tecnologias que funcionam entre plataformas. Para o código .NET 8, net8.0 substitui ambos e netcoreappnetstandard TFMs.

  • net8.0-windows

    Este é um exemplo de um TFM específico do sistema operacional que adiciona funcionalidade específica do sistema operacional a tudo o que net8.0 se refere.

Quando segmentar net8.0 vs. netstandard

Para o código existente destinado ao netstandard, não há necessidade de alterar o TFM para net8.0 ou um TFM posterior. O .NET 8 implementa o .NET Standard 2.1 e versões anteriores. A única razão para redirecionar do .NET Standard para o .NET 8+ seria obter acesso a mais recursos de tempo de execução, recursos de linguagem ou APIs. Por exemplo, para usar C# 9, você precisa direcionar o .NET 5 ou uma versão posterior. Você pode multidestino .NET 8 e .NET Standard para obter acesso a recursos mais recentes e ainda ter sua biblioteca disponível para outras implementações .NET.

Aqui estão algumas diretrizes para o novo código para .NET 5+:

  • Componentes da aplicação

    Se você estiver usando bibliotecas para dividir um aplicativo em vários componentes, recomendamos que você segmente net8.0o . Para simplificar, é melhor manter todos os projetos que compõem seu aplicativo na mesma versão do .NET. Então você pode assumir os mesmos recursos BCL em todos os lugares.

  • Bibliotecas reutilizáveis

    Se você estiver criando bibliotecas reutilizáveis que planeja enviar no NuGet, considere a compensação entre alcance e conjunto de recursos disponíveis. O .NET Standard 2.0 é a versão mais recente suportada pelo .NET Framework, por isso oferece um bom alcance com um conjunto de recursos bastante grande. Não recomendamos segmentar o .NET Standard 1.x, pois você limitaria o conjunto de recursos disponíveis para um aumento mínimo no alcance.

    Se você não precisa oferecer suporte ao .NET Framework, você pode usar o .NET Standard 2.1 ou o .NET 8. Recomendamos que você ignore o .NET Standard 2.1 e vá direto para o .NET 8. As bibliotecas mais usadas terão destinos múltiplos para o .NET Standard 2.0 e o .NET 5+. O suporte ao .NET Standard 2.0 oferece o maior alcance, enquanto o suporte ao .NET 5+ garante que você possa aproveitar os recursos mais recentes da plataforma para clientes que já estão no .NET 5+.

Problemas do .NET Standard

Aqui estão alguns problemas com o .NET Standard que ajudam a explicar por que o .NET 5 e versões posteriores são a melhor maneira de compartilhar código entre plataformas e cargas de trabalho:

  • Lentidão para adicionar novas APIs

    O .NET Standard foi criado como um conjunto de APIs que todas as implementações do .NET teriam que suportar, portanto, houve um processo de revisão para propostas para adicionar novas APIs. O objetivo era padronizar apenas APIs que pudessem ser implementadas em todas as plataformas .NET atuais e futuras. O resultado foi que, se um recurso perdeu uma versão específica, você pode ter que esperar por alguns anos antes de ser adicionado a uma versão do Standard. Então você esperaria ainda mais para que a nova versão do .NET Standard fosse amplamente suportada.

    Solução no .NET 5+: Quando um recurso é implementado, ele já está disponível para todos os aplicativos e bibliotecas do .NET 5+ porque a base de código é compartilhada. E como não há diferença entre a especificação da API e sua implementação, você pode aproveitar os novos recursos muito mais rapidamente do que com o .NET Standard.

  • Controle de versão complexo

    A separação da especificação da API de suas implementações resulta em um mapeamento complexo entre as versões de especificação da API e as versões de implementação. Essa complexidade é evidente na tabela mostrada anteriormente neste artigo e nas instruções de como interpretá-la.

    Solução no .NET 5+: Não há separação entre uma especificação de API do .NET 5+ e sua implementação. O resultado é um regime simplificado de GFT. Há um prefixo TFM para todas as cargas de trabalho: net8.0 é usado para bibliotecas, aplicativos de console e aplicativos Web. A única variação é um sufixo que especifica APIs específicas da plataforma para uma plataforma específica, como net8.0-windows. Graças a esta convenção de nomenclatura do TFM, você pode facilmente saber se um determinado aplicativo pode usar uma determinada biblioteca. Nenhuma tabela equivalente de número de versão, como a do .NET Standard, é necessária.

  • Exceções sem suporte de plataforma em tempo de execução

    O .NET Standard expõe APIs específicas da plataforma. Seu código pode ser compilado sem erros e parecer portátil para qualquer plataforma, mesmo que não seja portátil. Quando ele é executado em uma plataforma que não tem uma implementação para uma determinada API, você recebe erros em tempo de execução.

    Solução no .NET 5+: Os SDKs do .NET 5+ incluem analisadores de código habilitados por padrão. O analisador de compatibilidade de plataforma deteta o uso não intencional de APIs que não são suportadas nas plataformas em que você pretende executar. Para obter mais informações, consulte Analisador de compatibilidade de plataforma.

.NET Standard não preterido

O .NET Standard ainda é necessário para bibliotecas que podem ser usadas por várias implementações .NET. Recomendamos que você direcione o .NET Standard nos seguintes cenários:

  • Use netstandard2.0 para compartilhar código entre o .NET Framework e todas as outras implementações do .NET.
  • Use netstandard2.1 para compartilhar código entre Mono, Xamarin e .NET Core 3.x.

Consulte também