.NET Standard - Uma introdução

.NET Standard - Uma introdução básica

Neste artigo estou transcrevendo um texto que apresenta os conceitos básicos sobre o .NET Standard.

Esta artigo é uma transcrição integral do original encontrado neste link: https://goo.gl/jzgksg

Quando fui escrever um artigo sobre o .NET Standard encontrei no link acima um texto muito claro sobre o tema que transcrevo a seguir. (Os grifos, itálicos e destaques foram incluídos ao texto)

Plataformas .NET

Quando o .NET Framework foi criado a ideia era ter um framework para desenvolvimento de aplicações desktop no Windows. Podemos falar que o framework em si era composto por três componentes principais:

O CLR (Commom Language Runtime) - De forma resumida é um "Execution Engine" contendo tudo que é necessário para executar as aplicações .NET compiladas em IL. Quando a aplicação .NET é compilada o compilador não gera diretamente um executável nativo em linguagem de máquina, mas sim, arquivos em uma linguagem intermediária chamada MSIL (Microsoft Intermediate Language). O CLR inclui o compilador JIT, o mecanismo de coleta de lixo, etc. Ele recebe os arquivos em MSIL, utiliza o JIT para transformar em código nativo e permite a execução da aplicação.
A BCL (Base Class Library) - É a biblioteca básica de classes incluída com o Framework. Quando o .NET Framework é instalado na máquina toda a BCL é copiada para o GAC (Global Assembly Cache). As aplicações .NET quando dependem de um Assembly básico procuram no GAC e assim tem acesso a versão da BCL instalada com o Framework.
Software de suporte - O que eu chamo aqui de software de suporte inclui o software responsável por inicializar o CLR, prover a interface com o Sistema Operacional, etc.

Apesar disso funcionar bem no Desktop, com o passar do tempo surgiu a necessidade de se utilizar o .NET em novos ambientes. Isso deu origem a "novas formas de .NET". Alguns exemplos são o Silverlight, os aplicativos do Windows Phone 8 e os aplicativos da Windows Store.

Nesses casos, ter todos o .NET completos era inconveniente. O .NET é muito pesado e, portanto, muito custoso para rodar em um navegador ou então em um celular. Além disso, para rodar, por exemplo em celulares era necessário um framework otimizado para evitar, por exemplo, um gasto absurdo de bateria.

Cada um desses novos ambientes fez com que a partir do .NET original, se criasse um "framework especializado". Cada framework especializado possuía seu próprio runtime, sua própria biblioteca básica de classes e seu próprio software de suporte.

A biblioteca básica de cada uma dessas plataformas incluía aquilo que era considerado o necessário para a plataforma. E muitas vezes algo só faz sentido em uma plataforma: por exemplo as API's do Windows Forms não faz sentido no Silverlight nem no Windows Phone da mesma forma que as API's para interagir com um celular não fazem sentido no Desktop.

Em resumo, uma plataforma é constituída por um runtime, uma biblioteca básica e o software de suporte. O código que construímos é executado em cima de uma plataforma específica pelo runtime da mesma.

O Problema de compilar para várias plataformas

Apesar da estratégia de ter diversos "tipos de .NET", cada qual adequado a um ambiente, ter resolvido o problema de otimizar o framework para cada situação, isso introduz um problema: codificar uma biblioteca de classes que funcione em mais de uma plataforma.

Se escolhermos desenvolver somente em uma plataforma específica (por exemplo o .NET para Windows Desktop), não sofremos com esse problema. Mas se quisermos desenvolver para mais de uma plataforma, podemos precisar compartilhar código. Se desenvolvermos um software que terá uma versão para Windows Desktop, uma versão Silverlight e uma versão Windows Store, podemos acabar precisando desenvolver bibliotecas de classes que precisam ser usadas em mais de uma plataforma.

O problema disso é que uma vez que cada plataforma tem sua própria biblioteca básica, não podemos garantir que as API's que usamos na nossa biblioteca de classes vá funcionar em todas as plataformas.

O PCL (Portable Class Libraries) resolvia esse problema identificando conjuntos de plataformas. Isso significa que desenvolvíamos as bibliotecas de classes para um conjunto fixo de plataformas e sabíamos que teríamos acesso somente as API's disponíveis simultaneamente em todas as plataformas do conjunto.

Apesar dessa abordagem resolver o problema de uma forma, ela introduz outro problema: como o conjunto de plataformas foi "hard-coded", se uma nova plataforma é criada que suporta as API's usadas, a biblioteca não pode ser usada nela.

Como o .NET Platform Standard resolve o problema?

O .NET Platform Standard é a nova solução proposta para esse problema. A ideia é termos um único TFM (Target Framework Moniker) que identifica um padrão. Esse TFM possui uma versão que identifica um conjunto de API's disponíveis. É algo parecido com o API Level do Android.

A ideia por trás disso é: cada versão do .NET Platform Standard estabelece um contrato. Esses contratos dizem quais API's devem estar disponíveis.

Cada plataforma então "assina o contrato" de uma versão do .NET Platform Standard. Isso significa que a biblioteca básica dessa plataforma apresenta com certeza no mínimo as API's daquele contrato, daquela versão do .NET Platform Standard.

Os desenvolvedores de bibliotecas de classes então desenvolvem não para uma plataforma específica, ou conjunto de plataformas, mas para uma versão específica do .NET Platform Standard. É como usar uma interface em código: sabemos que os métodos estarão disponíveis. No caso, ao desenvolver para uma versão específica do .NET Platform Standard temos certeza que as API's daquela versão estão disponíveis.

A vantagem sobre o PCL é exatamente que se uma nova plataforma aparece e dá suporte aquelas API's, basta ela assinar o contrato daquela versão do .NET Platform Standard e o código das bibliotecas construídas para aquela versão irá funciona na nova plataforma.

Na prática o TFM do .NET Platform Standard é netstandardX sendo X a versão do .NET Platform Standard.

Agora no início houve um "versionamento retroativo" das API's das plataformas principais que existem hoje. Isso significa que a Microsoft já definiu simultaneamente as versões 1.0 até 1.4 do .NET Platform Standard pensando nas API's que as plataformas de hoje disponibilizam.

As API's da versão 1.0 foram escolhidas com base nas plataformas que disponibilizam menos API's hoje, enquanto que a versão 1.4 é a versão com todas as API's.

O documento oficial mostra como esse versionamento retroativo funciona, com uma tabela que permite mapear as versões do .NET Platform Standard para as plataformas concretas. Basta olhar na tabela para ver, por exemplo, que ao desenvolver para o .NET Platform Standard 1.3 a biblioteca vai funcionar, por exemplo, no .NET Framework 4.6 e no Universal Windows Platform 10.

Conforme novas plataformas precisam de novas API's as versões do .NET Platform vão acabar evoluindo. Cada versão nova inclui todas as API's das versões anteriores e as novas API's que foram escolhidas para a versão.

Em resumo, ao desenvolver para uma versão do .NET Platform Standard e não para uma plataforma específica temos a disponibilidade garantida das API's daquela versão nas plataformas que dão suporte para a mesma. Isso permite as bibliotecas de classes que criamos funcionarem em todas as plataformas atuais que suportam aquela versão do .NET Platform Standard assim como funcionar em todas as novas plataformas que dêm suporte a essa versão.

Para qual versão do .NET Standard direcionar

Ao escolher uma versão do .NET Standard, você deve considerar a seguinte compensação:

Quanto mais recente a versão, mais APIs estarão disponíveis para você.
Quanto menos recente a versão, mais plataformas a implementarão.

Em geral, recomendamos que você direcione para a versão menos recente possível do .NET Standard. Portanto, depois de localizar a versão mais recente do .NET Standard para a qual você pode direcionar, execute estas etapas:

Direcione para a próxima versão menos recente do .NET Standard e compile seu projeto.
Se seu projeto for compilado com êxito, repita a etapa 1. Caso contrário, redirecione para a próxima versão mais recente, e essa será a versão que você deve usar.

Regras de controle de versão do .NET Standard

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

Aditiva: As versões do .NET Standard são círculos logicamente concêntricos: versões mais recentes incorporam todas as APIs das versões anteriores. Não há alterações significativas entre as versões.
Imutável. Após a disponibilização, as versões do .NET Standard são congeladas. Novas APIs ficarão disponíveis primeiro em plataformas específicas do .NET, como .NET Core. Se a equipe de revisão do .NET Standard acreditar que as novas APIs devem ser disponibilizadas em qualquer lugar, elas serão adicionadas em uma nova versão do .NET Standard.

Comparação com bibliotecas de classes portáteis

O .NET Standard pode ser pensado como a próxima geração de PCLs (Bibliotecas de Classes Portáteis). O .NET Standard aprimora a experiência de criar bibliotecas portáteis, coletando um BCL padrão e estabelecendo maior uniformidade nos tempos de execução do .NET como resultado. Uma biblioteca direcionada ao .NET Standard é uma PCL ou uma “PCL baseada no .NET Standard”. PCLs existentes são "PCLs baseadas em perfil".

Os perfis do .NET Standard e da PCL foram criados para finalidades semelhantes, mas também diferem de maneiras básicas.

Semelhanças:

Define as APIs que podem ser usadas para compartilhamento de código binário.

Diferenças:

O .NET Standard é um conjunto estruturado de APIs, enquanto os perfis de PCL são definidos por interseções de plataformas existentes.
O .NET Standard tem versões lineares, ao passo que os perfis de PCL não.
Os perfis de PCL representam plataformas da Microsoft enquanto o .NET Standard é independente de plataforma.

fonte : https://docs.microsoft.com/pt-br/dotnet/standard/library

Todo aquele que crê que Jesus é o Cristo, é nascido de Deus; e todo aquele que ama ao que o gerou também ama ao que dele é nascido. 2 Nisto conhecemos que amamos os filhos de Deus, quando amamos a Deus e guardamos os seus mandamentos.
1 João 5:1,2

Referências:

José Carlos Macoratti