.NET

20 set, 2017

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

Publicidade

Neste artigo, estou transcrevendo de forma integral um texto que apresenta os conceitos básicos sobre o .NET Standard e o artigo original pode ser encontrado aqui.

Quando fui escrever um artigo sobre o .NET Standard, encontrei no link acima um texto muito claro sobre o tema que transcrevo a seguir.

Plataformas .NET

No momento em que o .NET Framework foi criado, sua finalidade era ter um framework voltado para desenvolvimento de aplicações desktop no Windows e seu framework era composto por três componentes principais:

  • CLR (Commom Language Runtime) – Basicamente, o CLR é um “Execution Engine”, incluindo 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 arquivos em uma linguagem intermediária, chamada MSIL (Microsofr Intermediate Language). O CLR inclui o compilador JIT, o mecanismo de coleta de lixo. Ele recebe os arquivos em MSIL, utiliza o JIT para transformar em código nativo e permite a execução da aplicação.
    Software de suporte – O que eu chamo software de suporte, inclui o software responsável por inicializar o CLR e também abastece a interface com o Sistema Operacional.
  • 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, e isso deu origem a “novas formas de .NET”. Alguns exemplos são; o Silverlight, aplicativos do Windows Phone 8 e os aplicativos da Windows Store.

Nestes casos, ter todos os complementos .NET era inconveniente, já que ele é muito pesado e acaba gerando muitos gastos para rodar em um navegador ou em um dispositivo móvel. Além disso, para rodar em dispositivos móveis, era necessário um framework otimizado para evitar um consumo elevado 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 necessário e muitas vezes algo só faz sentido em uma única plataforma, como por exemplo, as API’s do Windows Forms não fazem 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 dela mesma.

O problema de compilar para várias plataformas

Apesar da estratégia de ter diversos “tipos de .NET” – cada um adequado para um ambiente – e ter resolvido o problema de otimizar o framework para cada situação, ainda existe 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 sofreremos com esse problema. Mas se quisermos desenvolver para mais de uma plataforma, pode haver a necessidade de compartilharmos código. Se desenvolvermos um software que terá uma versão para Windows Desktop, uma versão Silverlight e uma versão Windows Store, talvez tenhamos que desenvolver bibliotecas de classes que precisam ser utilizadas em mais de uma plataforma.

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

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

Apesar dessa abordagem resolver o problema de uma forma, ela traz outro problema: como o conjunto de plataformas foi “hard-coded”, se uma nova plataforma que suporta API’s usadas é criada, 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 que diz 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, no mínimo, as API’s do contrato daquela versão .NET Platform Standard.

Os desenvolvedores de bibliotecas de classes não desenvolvem entã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 e neste caso, ao desenvolver para uma versão específica do .NET Platform Standard, temos certeza que as API’s daquela versão estarão disponíveis.

A vantagem sobre o PCL ocorre da seguinte forma, caso uma nova plataforma apareça e dê suporte àquelas 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á funcionar na nova plataforma.

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

No início, houve um “versionamento retroativo” das API’s das principais plataformas existentes. 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 atuais disponibilizam.

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

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

Conforme a demanda das plataformas por novas API’s, as versões do .NET Platform irão evoluir. 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 atual.

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 que as bibliotecas de classes que criamos funcionem em todas as plataformas atuais que suportam aquela versão do .NET Platform Standard, assim como em todas as novas plataformas que dão suporte a essa versão.

Para qual versão do .NET Standard direcionar

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

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

Recomendamos que você direcione para a versão menos recente possível do .NET Standard. Portanto, após localizar a versão mais recente do .NET Standard para a qual você pode direcionar, execute as seguintes etapas:

  1. Direcione para a próxima versão menos recente do .NET Standard e compile seu projeto.
  2. Caso seu projeto seja 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ê deverá utilizar.

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, ou seja, versões mais recentes incorporam todas as APIs das versões anteriores e 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 e novas APIs ficarão disponíveis primeiro em plataformas específicas do .NET, como .NET Core e caso a equipe de revisão do .NET Standard acredite 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 se 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, ao contrário dos perfis de PCL, que 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 não depende de plataformas.

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