Qual é a diferença entre os tipos de projeto do .NET Core e do .NET Standard Class Library?

No Visual Studio, existem pelo menos três tipos diferentes de biblioteca de classes que você pode criar:

• Biblioteca de classes (.NET Framework)
• Biblioteca de classes (.NET Standard)
• Biblioteca de classes (.NET Core)

Enquanto o primeiro é o que usamos há anos, um dos principais pontos de confusão que tenho enfrentado é quando usar os tipos de biblioteca de classes .NET Standard e .NET Core. Fui mordido por isso recentemente ao tentar segmentar diferentes versões de estrutura e criar um projeto de teste de unidade .

Então, qual é a diferença entre a Biblioteca de Classes (.NET Standard) e a Biblioteca de Classes (.NET Core) , por que ambas existem e quando devemos usar uma sobre a outra?

Quando devemos usar um sobre o outro?

A decisão é uma troca entre compatibilidade e acesso à API.

Use uma biblioteca .NET Standard quando desejar aumentar o número de aplicativos que serão compatíveis com sua biblioteca e você concorda com uma diminuição na área de superfície da API .NET que sua biblioteca pode acessar.

Use uma biblioteca .NET Core quando desejar aumentar a área de superfície da API .NET que sua biblioteca pode acessar e você concorda em permitir que apenas aplicativos .NET Core sejam compatíveis com sua biblioteca.

Por exemplo, uma biblioteca direcionada ao .NET Standard 1.3 será compatível com aplicativos direcionados ao .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0 e qualquer outra plataforma que suporte o .NET Standard 1.3. A biblioteca não terá acesso a algumas partes da API do .NET. Por exemplo, o Microsoft.NETCore.CoreCLRpacote é compatível com o .NET Core, mas não com o .NET Standard.

Qual é a diferença entre a Biblioteca de classes (.NET Standard) e a Biblioteca de classes (.NET Core)?

A seção Estruturas Baseadas em Pacotes descreve a diferença.

Compatibilidade: as bibliotecas direcionadas ao .NET Standard serão executadas em qualquer tempo de execução compatível com o .NET Standard, como .NET Core, .NET Framework, Mono / Xamarin. Por outro lado, as bibliotecas direcionadas ao .NET Core só podem ser executadas no tempo de execução do .NET Core.

Área de superfície da API: as bibliotecas .NET Standard vêm com tudo, NETStandard.Libraryenquanto as bibliotecas .NET Core vêm com tudo Microsoft.NETCore.App. O último inclui aproximadamente 20 bibliotecas adicionais, algumas das quais podemos adicionar manualmente à nossa biblioteca .NET Standard (como System.Threading.Thread) e algumas não são compatíveis com o .NET Standard (como Microsoft.NETCore.CoreCLR).

Além disso, as bibliotecas do .NET Core especificam um tempo de execução e vêm com um modelo de aplicativo. Isso é importante, por exemplo, para tornar as bibliotecas de classes de teste de unidade executáveis.

Por que os dois existem?

Ignorando as bibliotecas por um momento, a razão pela qual o .NET Standard existe é a portabilidade; define um conjunto de APIs que as plataformas .NET concordam em implementar. Qualquer plataforma que implemente um .NET Standard é compatível com bibliotecas direcionadas ao .NET Standard. Uma dessas plataformas compatíveis é o .NET Core.

Voltando às bibliotecas, os modelos de biblioteca do .NET Standard existem para execução em vários tempos de execução (às custas da área de superfície da API). Inversamente, os modelos de biblioteca do .NET Core existem para acessar mais área de superfície da API (à custa da compatibilidade) e para especificar uma plataforma na qual construir um executável.

Aqui está uma matriz interativa que mostra qual .NET Standard suporta quais implementações do .NET e quanta área de superfície da API está disponível.

Uma biblioteca de classes do .NET Core é construída sobre o .NET Standard . Se você deseja implementar uma biblioteca que seja portátil para o .NET Framework ,. .NET Core e Xamarin , escolha uma biblioteca padrão do .NET

O .NET Core finalmente implementará o .NET Standard 2 (assim como o Xamarin e o .NET Framework )

O .NET Core , o Xamarin e o .NET Framework podem, portanto, ser identificados como sabores do .NET Standard

Para proteger seus aplicativos para compartilhamento e reutilização de código, você prefere implementar as bibliotecas do .NET Standard.

A Microsoft também recomenda que você use o .NET Standard em vez de Portable Class Libraries .

Para citar o MSDN como uma fonte autorizada, o .NET Standard deve ser uma biblioteca para governar todos eles . Como as imagens valem mais que mil palavras, o seguinte deixará as coisas muito claras:

1. Seu cenário atual de aplicativo (fragmentado)

Como a maioria de nós, você provavelmente está na situação abaixo: (.NET Framework, Xamarin e agora aplicativos com sabor do .NET Core)

2. O que a Biblioteca Padrão do .NET permitirá para você (compatibilidade entre estruturas)

A implementação de uma biblioteca padrão do .NET permite o compartilhamento de código em todos os diferentes tipos:

Para os impacientes:

1. O .NET Standard resolve o problema de compartilhamento de código para desenvolvedores .NET em todas as plataformas, trazendo todas as APIs que você espera e ama nos ambientes que você precisa: aplicativos de desktop, aplicativos e jogos para dispositivos móveis e serviços em nuvem:
2. O .NET Standard é um conjunto de APIs que todas as plataformas .NET precisam implementar . Isso unifica as plataformas .NET e impede a fragmentação futura .
3. O .NET Standard 2.0 será implementado pelo .NET Framework ,. NET Core e Xamarin . Para o .NET Core , isso adicionará muitas das APIs existentes que foram solicitadas.
4. O .NET Standard 2.0 inclui uma correção de compatibilidade para os binários do .NET Framework , aumentando significativamente o conjunto de bibliotecas que você pode consultar nas bibliotecas do .NET Standard.
5. O .NET Standard substituirá as Portable Class Libraries (PCLs) como a história das ferramentas para a criação de bibliotecas .NET de várias plataformas.

Para uma tabela para ajudar a entender qual é a versão mais alta do .NET Standard que você pode segmentar, com base em quais plataformas .NET você pretende executar, vá até aqui .

Fontes: MSDN: Apresentando o .NET Standard

Portanto, a resposta curta seria:

IAnimal == .NetStandard (General)
ICat == .NetCore (Less General)
IDog == .NetFramework (Specific / oldest and has the most features)

.NET e .NET Core são duas implementações diferentes do tempo de execução .NET. O Core e o Framework (mas especialmente o Framework) têm perfis diferentes que incluem seleções maiores ou menores (ou simplesmente diferentes) das muitas APIs e assemblies que a Microsoft criou para o .NET, dependendo de onde elas estão instaladas e em que perfil.

Por exemplo, existem algumas APIs diferentes disponíveis nos aplicativos universais do Windows que no perfil "normal" do Windows. Mesmo no Windows, você pode ter o perfil "Cliente" versus o perfil "Completo". Além disso, e existem outras implementações (como o Mono ) que possuem seus próprios conjuntos de bibliotecas.

O .NET Standard é uma especificação para a qual conjuntos de bibliotecas e assemblies de API devem estar disponíveis. Um aplicativo criado para o .NET Standard 1.0 deve ser capaz de compilar e executar com qualquer versão do Framework, Core, Mono etc. que anuncia suporte para a coleção de bibliotecas do .NET Standard 1.0. Semelhante é verdadeiro para o .NET Standard 1.1, 1.5, 1.6, 2.0, etc. Desde que o tempo de execução for compatível com a versão do Standard direcionada ao seu programa, ele deverá ser executado lá.

Um projeto direcionado a uma versão do Standard não poderá usar recursos que não estão incluídos nessa revisão do padrão. Isso não significa que você não pode aceitar dependências de outros assemblies ou APIs publicadas por outros fornecedores (por exemplo: itens no NuGet). Mas isso significa que todas as dependências adotadas também devem incluir suporte para sua versão do .NET Standard. O .NET Standard está evoluindo rapidamente, mas ainda é novo o suficiente e se preocupa o suficiente com alguns dos perfis de tempo de execução menores, para que essa limitação possa parecer sufocante. (Observe um ano e meio depois: isso está começando a mudar e as versões recentes do .NET Standard são muito melhores e mais completas).

Por outro lado, um aplicativo direcionado ao Standard deve poder ser usado em mais situações de implantação, pois, em teoria, ele pode ser executado com Core, Framework, Mono, etc. Para um projeto de biblioteca de classes que procura ampla distribuição, é uma promessa atraente . Para um projeto de biblioteca de classes usado principalmente para fins internos, pode não ser tão preocupante.

O .NET Standard também pode ser útil em situações em que a equipe de administradores do sistema deseja migrar do ASP.NET no Windows para o ASP.NET for .NET Core no Linux por razões filosóficas ou de custo, mas a equipe de Desenvolvimento deseja continuar trabalhando. NET Framework no Visual Studio no Windows.

.NET Framework e .NET Core são estruturas.

O .NET Standard é um padrão (em outras palavras, uma especificação).

Você pode criar um projeto executável (como um aplicativo de console ou aplicativo ASP.NET) com o .NET Framework e o .NET Core, mas não com o .NET Standard.

Com o .NET Standard, você pode criar apenas um projeto de biblioteca de classes que não pode ser executado de forma independente e deve ser referenciado por outro projeto executável do .NET Core ou .NET Framework.

Espero que isso ajude a entender o relacionamento entre a superfície da API do .NET Standard e outras plataformas .NET . Cada interface representa uma estrutura de destino e os métodos representam grupos de APIs disponíveis nessa estrutura de destino.

namespace Analogy
{
  // .NET Standard

interface INetStandard10
{
    void Primitives();
    void Reflection();
    void Tasks();
    void Xml();
    void Collections();
    void Linq();
}

interface INetStandard11 : INetStandard10
{
    void ConcurrentCollections();
    void LinqParallel();
    void Compression();
    void HttpClient();
}

interface INetStandard12 : INetStandard11
{
    void ThreadingTimer();
}

interface INetStandard13 : INetStandard12
{
    //.NET Standard 1.3 specific APIs
}

// And so on ...


// .NET Framework 

interface INetFramework45 : INetStandard11
{
    void FileSystem();
    void Console();
    void ThreadPool();
    void Crypto();
    void WebSockets();
    void Process();
    void Drawing();
    void SystemWeb();
    void WPF();
    void WindowsForms();
    void WCF();
}

interface INetFramework451 : INetFramework45, INetStandard12
{
    // .NET Framework 4.5.1 specific APIs
}

interface INetFramework452 : INetFramework451, INetStandard12
{
    // .NET Framework 4.5.2 specific APIs
}

interface INetFramework46 : INetFramework452, INetStandard13
{
    // .NET Framework 4.6 specific APIs
}

interface INetFramework461 : INetFramework46, INetStandard14
{
    // .NET Framework 4.6.1 specific APIs
}

interface INetFramework462 : INetFramework461, INetStandard15
{
    // .NET Framework 4.6.2 specific APIs
}

// .NET Core
interface INetCoreApp10 : INetStandard15
{
    // TODO: .NET Core 1.0 specific APIs
}
// Windows Universal Platform
interface IWindowsUniversalPlatform : INetStandard13
{
    void GPS();
    void Xaml();
}

// Xamarin 
interface IXamarinIOS : INetStandard15
{
    void AppleAPIs();
}

interface IXamarinAndroid : INetStandard15
{
    void GoogleAPIs();
}    
// Future platform

interface ISomeFuturePlatform : INetStandard13
{
    // A future platform chooses to implement a specific .NET Standard version.
    // All libraries that target that version are instantly compatible with this new
    // platform
}
}

Fonte

Outra maneira de explicar a diferença poderia ser com exemplos do mundo real, já que a maioria de nós, mortais, usará ferramentas e estruturas existentes (Xamarin, Unity etc.) para fazer o trabalho.

Portanto, com o .NET Framework, você tem todas as ferramentas do .NET para trabalhar, mas só pode segmentar aplicativos do Windows (UWP, Winforms, ASP.NET etc.). Como o .NET Framework é de código fechado, não há muito o que fazer.

Com o .NET Core, você tem menos ferramentas, mas pode segmentar as principais plataformas de desktop (Windows, Linux, Mac). Isso é especialmente útil nos aplicativos ASP.NET Core, já que agora você pode hospedar o Asp.net no Linux (preços de hospedagem mais baratos). Agora, como o .NET Core foi aberto, é tecnicamente possível desenvolver bibliotecas para outras plataformas. Mas como não há estruturas que o suportem, não acho que seja uma boa ideia.

Com o .NET Standard, você tem ainda menos ferramentas, mas pode segmentar todas / a maioria das plataformas. Você pode segmentar os dispositivos móveis graças ao Xamarin e até os consoles de jogos graças ao Mono / Unity. Atualização: Também é possível direcionar clientes da Web com a plataforma UNO e o Blazor (embora ambos sejam um pouco experimentais no momento).

Em um aplicativo do mundo real, você pode precisar usar todos eles. Por exemplo, desenvolvi um aplicativo de ponto de venda que tinha a seguinte arquitetura:

Compartilhado servidor e cliente:

• Uma biblioteca .NET Standard que lida com os modelos do meu aplicativo.
• Uma biblioteca .NET Standard que lida com a validação de dados enviados pelos clientes.

Por ser uma biblioteca .NET Standard, pode ser usada em qualquer outro projeto (cliente e servidor).

Também é uma boa vantagem de ter a validação em uma biblioteca padrão do .NET, pois posso ter certeza de que a mesma validação é aplicada no servidor e no cliente. O servidor é obrigatório, enquanto o cliente é opcional e útil para reduzir o tráfego.

Lado do servidor (Web API):

• Uma biblioteca .NET Standard (também poderia ser Core) que lida com todas as conexões com o banco de dados.

• Um projeto do .NET Core que lida com a API Rest e faz uso da biblioteca de banco de dados.

Como isso é desenvolvido no .NET Core, eu posso hospedar o aplicativo em um servidor Linux.

Lado do cliente (MVVM com WPF + Xamarin.Forms Android / IOS):

• Uma biblioteca .NET Standard que lida com a conexão da API do cliente.

• Uma biblioteca .NET Standard que lida com a lógica ViewModels. Usado em todas as visualizações.

• Um aplicativo .NET Framework WPF que lida com os modos de exibição WPF de um aplicativo do Windows. Atualização: os aplicativos WPF podem ser o núcleo .NET agora, embora funcionem apenas no Windows atualmente. O AvaloniaUI é uma boa alternativa para criar aplicativos Desktop GUI para outras plataformas de desktop.

• Uma biblioteca .NET Standard que lida com as visualizações do Xamarin Forms.

• Um projeto Xamarin Android e Xamarin IOS.

Assim, você pode ver que há uma grande vantagem aqui no lado do cliente do aplicativo, pois posso reutilizar as bibliotecas .NET Standard (Client API e ViewModels) e apenas fazer visualizações sem lógica para os aplicativos WPF, Xamarin e IOS.

.NET Standard: Pense nisso como uma grande biblioteca padrão. Ao usar isso como uma dependência, você só pode criar bibliotecas (.DLLs), não executáveis. Uma biblioteca criada com o padrão .NET como dependência pode ser adicionada a um projeto Xamarin.Android, Xamarin.iOS, .NET Core Windows / OS X / Linux.

.NET Core: Pense nisso como a continuação da antiga estrutura .NET, apenas seu código-fonte aberto e algumas coisas ainda não foram implementadas e outras foram preteridas. Ele estende o padrão .NET com funções extras, mas é executado apenas em desktops . Ao adicionar isso como uma dependência, você pode criar aplicativos executáveis ​​no Windows, Linux e OS X. (Embora o console esteja apenas por enquanto, sem GUIs). Então, .NET Core = .NET Standard + coisas específicas da área de trabalho.

Além disso, o UWP o usa e o novo ASP.NET Core também o usa como dependência.

O .NET Standard existe principalmente para aprimorar o compartilhamento de código e tornar as APIs disponíveis em cada implementação do .NET mais consistentes.

Ao criar bibliotecas, podemos ter o destino como .NET Standard 2.0 para que a biblioteca criada seja compatível com diferentes versões do .NET Framework, incluindo .NET Core, Mono , etc.

As respostas acima podem descrever o melhor entendimento sobre a diferença entre o núcleo da rede, o padrão da rede e o framwork da rede, então eu só quero compartilhar minha experiência ao escolher isso sobre isso.

No projeto que você precisa misturar entre o .NET Framework, o .NET Core e o .NET Standard. Por exemplo, no momento em que construímos o sistema com o .NET Core 1.0, não há suporte para os Serviços de Janela hospedando com o núcleo .net.

O próximo motivo é que estávamos usando o Active Report, que não suporta o .NET Core. Portanto, queremos criar uma biblioteca de infraestrutura que possa ser usada para o .NET Core (asp.net core) e o Windows Service and Reporting (.NET Framework) -> É por isso que escolhemos o .NET Standard para esse tipo de biblioteca. Escolher o padrão .NET significa que você deve considerar cuidadosamente todas as classes da biblioteca devem ser simples e cruzadas com o .NET (núcleo, estrutura, padrão).

Conclusão:

• .NET Standard para a biblioteca de infraestrutura e compartilhada em comum. Essa lib pode ser referenciada pelo .NET Framework e .NET Core.
• .NET Framework para tecnologias não suportadas, como Active Report, Window Services (agora com o .NET 3.0 compatível).
• .NET Core para ASP.NET Core, é claro.

A Microsoft acaba de anunciar o .NET 5: https://devblogs.microsoft.com/dotnet/introducing-net-5/

O aplicativo .NET Framework Windows Form, ASP.NET e WPF deve ser desenvolvido usando a biblioteca .NET Framework

Os aplicativos .NET Standard Xamarin, IOs e MAC OSx devem ser dedicados usando a biblioteca .NET Standard

A Plataforma Universal do Windows .NET Core (UWP) e o aplicativo Linux devem ser desenvolvidos usando a biblioteca .NET Core. A API é implementada em C ++ e você pode usar as linguagens C ++, VB.NET, C #, F # e Javascript.

Uma .Net Core Class Library é construída sobre o .Net Standard. Se você deseja implementar uma biblioteca que seja portátil para o .Net Framework, .Net Core e Xamarin, escolha uma .Net Standard Library