.NET Core -  Criando um biblioteca compartilhada

Hoje veremos como criar uma biblioteca compartilhada (shared library) no .NET Core.

O compartilhamento de bibliotecas entre projetos pode ser um requisito fundamental em muitos aplicativos, com exceção dos aplicativos mais simples.

Neste artigo veremos como as coisas mudaram com o .NET Core; veremos os diferentes tipos de biblioteca de classes disponíveis, como criar uma biblioteca simples e a melhor maneira de referenciar bibliotecas compartilhadas de outros aplicativos.

Escolhendo o tipo de projeto

Se você decidir criar uma biblioteca de classes para o .NET Core, pode ficar um pouco confuso pois vai encontrar duas opções que parecem atender ao mesmo propósito.

Abrindo o VS 2017 e clicando em New Project, ao selecionar a opção .NET Core você tem o template:
Class Library(.NET Core)



Na opção .NET Standard temos disponível o template :  Class Library (.NET Standard)

E agora ?  Qual você deve escolher ?

Ambas as opções produzem projetos de biblioteca de classes que podem ser referenciados a partir de aplicativos .NET Core, mas as bibliotecas .NET Standard podem ser compatíveis com aplicativos .NET Framework, bem como com Xamarin e qualquer outra coisa que adere ao .NET Standard.

Por esse motivo, é recomendável escolher a opção .NET Standard, a menos que você precise de acesso a funcionalidades que não façam parte do .NET Standard e estejam disponíveis apenas no .NET Core.

Se você precisar alternar entre os dois, só precisará alterar o TargetFramework no arquivo csproj. Abrindo um arquivo .csproj temos que:

As bibliotecas de classes .NET Standard fazem referência ao netstandard:

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>

</Project>
 

As bibliotecas de classes .NET Core referenciam netcoreapp:

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
</PropertyGroup>

</Project>
 

Usando a ferramenta de linha de comando NET CLI

Se você estiver usando as ferramentas de linha de comando do dotnet ao invés do Visual Studio, as coisas serão menos confusas.

Abrindo um prompt de comandos e visualizando os templates de projetos disponíveis usando o comando :
 dotnet new

Temos o resultado exibido abaixo:



Observe que temos apenas a opção classlib.

Vamos criar um novo projeto com esta opção via comando : dotnet new classlib

Após criar o projeto usando o template classlib, ao examinarmos o contéudo do arquivo de projeto demo.csproj usando o comando :  type demo.csproj

Veremos que o resultado obtido é um projeto do tipo .NET Standard class library.

Esse é o único template disponível para criar uma biblioteca de classes usando a NET CLI.

Escolhendo a versão do Framework de destino

A .NET Standard é essencialmente uma especificação com versão, com versões posteriores adicionando mais APIs. Versões superiores não têm permissão para remover funcionalidades, portanto, se a biblioteca funcionar com a versão 1.3, ela também funcionará com versões 1.4, 1.6, 2.0 etc. Se você especificar uma versão do .NET Standard com sua biblioteca, todas as plataformas que implementarem essa versão serão capaz de executar sua biblioteca.

Resumindo:

Escolher uma versão superior dá a você acesso a mais APIs em detrimento de menos compatibilidade. Portanto, o conselho recomendado é escolher a versão mais antiga que contém tudo o que você precisa. Dito isto, se a sua biblioteca é apenas para uso interno, então a compatibilidade pode não ser um quesito a ser considerado como crítico.

Alterar o framework de destino é tão simples quanto editar o arquivo csproj.

Você pode fazer isso manualmente:

ou por meio da interface GUI :

Muito simples.

Adicionando código à sua biblioteca

Após criar a sua biblioteca você inclui código como em qualquer outro projeto, inclusive pacotes Nuget.

Se você achar que existem tipos ou métodos que não serão reconhecidos pelo compilador, vale a pena verificar a versão do .NET Standard para a qual você está direcionando.

Por padrão, sua biblioteca de classes irá ser orientada para a versão 1.4, mas talvez você tenha que passar para a versão 1.5 ou superior. O repositório github do .NET Standard é muito útil quando você se depara com problemas.

Usando a sua biblioteca de classes

Agora, supondo que criamos nossa biblioteca de classes vejamos como referenciá-la a partir de outra aplicação.

A maneira mais simples de usar nossa biblioteca de classes é adicioná-la como uma referência de projeto.

Isso resulta na compilação da biblioteca junto com o aplicativo. Sempre que uma alteração é feita na biblioteca de classes, ela é automaticamente selecionada pelo aplicativo (localmente) e será incluída quando o aplicativo for publicado.

Se a biblioteca de classes é usada apenas por um aplicativo, faz sentido incluir o projeto da biblioteca na mesma solução que o aplicativo, e fazer referência à biblioteca de classes como uma referência de projeto. Se a biblioteca for compartilhada, esse método pode trazer problemas.

Referência de DLL

Outra abordagem comum é adicionar referências diretas aos arquivos DLL. Sua biblioteca compartilhada é completamente separada do seu código de aplicativo e você tem controle total sobre o lançamento de novas versões (com números de versão apropriados).

Para permitir que o aplicativo seja construído em servidores de IC, etc., você pode ficar tentado a criar uma pasta lib em seu aplicativo e copiar em DLLs.

Essa abordagem era bastante comum antes do advento do NuGet, mas em versões atuais do Net Core (<versão 2), isso não é possível. O conjunto de ferramentas do Visual Studio permitirá adicionar a referência, mas você receberá erros de tempo de execução semelhantes a:

FileNotFoundException: não foi possível carregar o arquivo ou assembly 'ClassLibStd, versão = 1.0.1.0, Culture = neutral, PublicKeyToken = null'. O sistema não pode encontrar o arquivo especificado.

ou

Os projetos .NET Core suportam apenas referência a assemblies de estrutura .NET nesta versão. Para fazer referência a outros conjuntos, eles precisam ser incluídos em um pacote NuGet

Referência de Pacote(Nuget)

O NuGet é o melhor método para compartilhar bibliotecas no .NET Core. Isto se refere apenas sobre o uso de pacotes NuGet, em vez de publicar todo o código da sua biblioteca privada no feed público do nuget.org.

Criar um pacote NuGet a partir de uma biblioteca de classes no VS 2017 é muito simples.

Basta clicar com o botão direito do mouse no projeto, escolher Propriedades e ir para a guia Package (pacote).

Marque a caixa na parte superior e preencha as informações do pacote conforme necessário:

Isso modificará o csproj com as informações que você inseriu (você também pode editar o arquivo manualmente):

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <Description>Meu pacote nuget</Description>
    <Copyright>Macoratti</Copyright>
  </PropertyGroup>
</Project>

Após isso se você dar um build no seu projeto e verificar a pasta bin, você encontrará um pacote NuGet que foi criado automaticamente.

Para fazer referência ao seu pacote NuGet você precisa copiar o pacote para um local conhecido antes de adicionar o local como uma fonte de pacote. Isso nos permite duas opções:

  1. Usar uma unidade compartilhada que é acessível a todos os desenvolvedores e todas as ferramentas de compilação;
  2. Partindo da estrutura de pastas do projeto, referenciar a pasta como um caminho relativo;

Adicionar uma fonte de pacote NuGet (caminho fixo) adicional no Visual Studio é muito simples.

Você até pode adicionar fontes de pacotes adicionais diretamente ao Visual Studio, mas isso significa que todos os desenvolvedores precisam fazer isso para criar o projeto o que não é ideal.

Uma abordagem melhor seria adicionar um arquivo NuGet.config à pasta que contém o arquivo da solução. Isso pode ser verificado no repositório de controle de versão, configurando automaticamente a origem do pacote para todos.

A principal desvantagem dessa abordagem é o fato de que você provavelmente precisará comitar seus pacotes NuGet no controle de versão se tiver ferramentas de criação baseadas na nuvem ou se os desenvolvedores e o servidor de criação não tiverem acesso a um local comum onde você possa armazenar seus pacotes.

E era isso....

Espero que essas informações possam te ajudar a criar código compartilhado.

"Sujeitai-vos, pois, a Deus, resisti ao diabo, e ele fugirá de vós." Tiago 4:7

Veja os Destaques e novidades do SUPER DVD Visual Basic (sempre atualizado) : clique e confira !

Quer migrar para o VB .NET ?

Quer aprender C# ??

Quer aprender os conceitos da Programação Orientada a objetos ?

Quer aprender o gerar relatórios com o ReportViewer no VS 2013 ?

Quer aprender a criar aplicações Web Dinâmicas usando a ASP .NET MVC 5 ?

Referências:

José Carlos Macoratti