Entendendo Nuget package

Você que trabalha com dotnet provavelmente já consome essa feature a séculos, mas entende exatamente como ela funciona? Conhecer o funcionamento dela por trás dos bastidores, provavelmente vai evitar ter grandes dores de cabeça nas adversidades do dia a dia.

Mas afinal, o que é o nuget

Pra quem está iniciando com DotNet, nuget packages pode ser explicado como um provedor de pacote(s)* que pode(m) ser incorporado(s) no seu projeto. Esse provedor pode disponibilizar pacotes online e offline. Esses pacotes são disponibilizados principalmente por 2 arquivos, com as extensões nupkg e nuspec.

• Nuspec — Este arquivo de metadados no formato de XML, tem como objeto de descrever o pacote que está sendo disponibilizado
• Nupkg — Este arquivo é o resultado da compactação da dll e arquivos de configurações da feature que estará sendo disponibilizada.(Confirme isso abrindo com alguma ferramenta de compactação)

No Visual Studio você pode facilmente consumir desde provedor através da própria IDE ou por linha de comando. Algo importante antes de consumir, é entender que a Microsoft tem entrado num movimento de transição (já sendo resolvido a partir do .net 5), onde temos plataformas distintas de desenvolvimento com .Net Standard, Core, Framework e Xamarin.

• Framework — Esta plataforma é direcionada a implementação clássica voltadas para o SO windows.
• Core — Essa está vinculada ao movimento de cross plataform ao qual o seu código pode ser compilado e executado em outros SOs como linux, IOS.
• Xamarin — Essa está direcionada a implementação voltada a mobile.
• Standard — Tem como objetivo trabalhar com BLC(Base Class Library), com isso essas implementações podem ser usadas em qualquer das plataformas acima.

Existe 2 formas de adicionar um pacote no seu projeto. Um via comando e um usando a IDE. Explicarei aqui pelo modo mais fácil no Visual Studio, para simplificar o entendimento. Para conseguir chegar na tela, basta clicar com o direito onde aparecerá a opção como a seguir.

Com isso você terá acesso a essa tela abaixo. Aqui você terá as abas:

• Browser — Para buscar novos pacotes para o projeto
• Installed — Vai exibir todos os pacotes instalados
• Updates — Vai de mostrar todos os pacotes que podem ser atualizados

Quando um pacote é selecionado, no lado direito é exibido os metadados descritos pelo nuspec. Aqui é importante olhar para saber se conseguirá usar no seu projeto. Caso o pacote for incompatível (Por exemplo usar pacote .Net Framework no Projeto .Net Core), este pacote ficará sendo sinalizado.

Aqui termina a parte básica que já conhecemos. Olhando agora para a parte de configuração, no lado superior direito da tela você terá um ícone de engrenagem ao qual levará você para a parte de configurações.

Aqui você conseguirá adicionar repositórios (online ou local) para usar no seu sistema. Repare que por default já vem o repositório público online do nuget e um local, que vem junto com o SDK. A partir daqui podemos perceber que podemos customizar e criar nosso próprio repositório customizado e privado. Conforme esses itens forem adicionados eles serão listados no package source da tela principal. Importante aqui é que toda essa parametrização na realidade é vinculada a um arquivo de configuração global(em xml) localizado em %AppData%\NuGet\NuGet.Config.

Você também pode ter essa configuração customizada para um projeto. Basta ter uma versão deste arquivo com as informações que necessita na pasta root do projeto.

Repositórios online

O repositório online pode ser desde o servidor público nuget ou até um servidor privado hospedado, oferecendo pacotes. Não é algo tão difícil de se montar, e existe solução como por exemplo nuget.server.

Nessa abordagem podemos observar como vantagem a resolução de pacotes, que é feita no momento que o projeto é compilado e caso não tenha, é feito o download. Outra vantagem é que caso surja uma nova versão do pacote, você poderá saber pela tela principal e atualizar. As desvantagens se encontram bem próximo disso pois um servidor online como qualquer outro, pode haver instabilidade e sem ele não conseguirá compilar o projeto.

Repositórios Locais

Repositório locais podemos classificar por pacotes hospedados em pastas na máquina ou rede. Você pode criar os pacotes nupkg dentro de uma pasta e indicar este endereço como repositório, com isso automaticamente ele será considerado como servidor. Se usar numa rede poderá compartilhar com a equipe. Algo interessante que já cheguei a adotar é versionar isso em um repositório git. Isso ajudou a gerenciar a adição de novos pacotes e no processo de CD pois bastaria clonar este diretório.

Cache do Nuget

Como havia falado usar um repositório online temos o problema de indisponibilidade, pra resolver isso a microsoft adota o esquema de cache. Toda a referência de pacote é feita dentro desta pasta (C:\Users\<usuario>\.nuget\packages) e caso o pacote naquela versão não exista, é baixado. Esse esquema de cache minimiza o problema de indisponibilidade do servidor além de minimizar o tempo de resolução de pacotes.

Resolução de pacotes em múltiplos servidores

A resolução de pacotes com múltiplos servidores ocorre na ordem que eles são definidos na configuração. Isso é importante ser citado pois quando você criar um pacote customizado, caso exista um pacote de mesmo nome vai ter problemas em referenciar . Já passei por esse problema, onde tive o azar de criar um pacote com o mesmo nome de um existente servidor do nuget org. Como na ordem de declaração estava o servidor do nuget org primeiro, o provedor resolvia com este publico, ao invés do que eu criei customizado. Para resolver de forma fácil bastou mudar a ordem, definindo na configuração o servidor privado primeiro.

Conclusão

Apesar do assunto ser ainda mais longo eu vou fechar com algumas dicas. Em algum post futuro com posso complementar com mais informações pouco conhecidas. Então segue as dicas:

• Sempre defina na configuração os servidores privados da empresa primeiro, isso evitará pegar um pacote errado caso exista algum no público com o mesmo nome.
• Apesar de ser difícil haver um indisponibilidade no nuget.org, não é impossível, então se previna tendo um diretório privado com os pacotes usados no projeto.
• Se caso não queira subir um serviço para disponibilizar pacotes, você pode disponibilizar através de um diretório na rede. Terá praticamente o mesmo efeito para equipe
• Conforme for organizando o projeto e tendo novas configurações prefira ter um arquivo nuget.config versionado dentro do projeto. Com isso não vai depender de cada dev ter que incluir esses servidores na configuração local.
• Sempre altere o número de versão ao publicar pois caso seja modificado e sobrescrito, provavelmente vai ter uma grande dor de cabeça nos projetos que o consome.