Uma introdução ao NuGet

Uma ferramenta essencial para qualquer plataforma de desenvolvimento moderna é um mecanismo por meio do qual os desenvolvedores podem criar, compartilhar e consumir código útil. Geralmente, esse código é agrupado em "pacotes" que contêm código compilado (como DLLs) juntamente com outros conteúdos necessários nos projetos que consomem esses pacotes.

Para o .NET (incluindo o .NET Core), o mecanismo compatível com a Microsoft para compartilhar código é NuGet, que define como os pacotes para .NET são criados, hospedados e consumidos e fornece as ferramentas para cada uma dessas funções.

Simplificando, um pacote NuGet é um único arquivo ZIP com a extensão .nupkg que contém DLLs (código compilado), outros arquivos relacionados a esse código e um manifesto descritivo que inclui informações como o número de versão do pacote. Os desenvolvedores com código para compartilhar criar pacotes e publicá-los em um host público ou privado. Os consumidores de pacotes obtêm esses pacotes de hosts apropriados, os adicionam aos seus projetos e, em seguida, utilizam a funcionalidade dos pacotes no código do projeto. O nuGet em si manipula todos os detalhes intermediários.

Como o NuGet dá suporte a hosts privados junto com o host nuget.org público, você pode usar pacotes NuGet para compartilhar código exclusivo para uma organização ou um grupo de trabalho. Você também pode usar pacotes NuGet como uma maneira conveniente de organizar seu próprio código para uso apenas em seus próprios projetos. Em suma, um pacote NuGet é uma unidade de código compartilhável, mas não requer nem implica nenhum meio específico de compartilhamento.

O fluxo de pacotes entre criadores, hosts e consumidores

Em sua função de host público, o próprio NuGet mantém o repositório central de mais de 100.000 pacotes exclusivos em nuget.org. Esses pacotes são empregados por milhões de desenvolvedores do .NET/.NET Core todos os dias. O NuGet também permite hospedar pacotes privadamente na nuvem (como no Azure DevOps), em uma rede privada ou até mesmo apenas em seu sistema de arquivos local. Ao fazer isso, esses pacotes estão disponíveis apenas para os desenvolvedores que têm acesso ao host, oferecendo a capacidade de disponibilizar pacotes para um grupo específico de consumidores. As opções são explicadas em Hospedar seus próprios feeds do NuGet. Por meio de opções de configuração, você também pode controlar exatamente quais hosts podem ser acessados por qualquer computador específico, garantindo assim que os pacotes sejam obtidos de fontes específicas em vez de um repositório público como nuget.org.

Seja qual for sua natureza, um host serve como o ponto de conexão entre os criadores do pacote e os consumidores do pacote . Os criadores criam pacotes NuGet úteis e os publicam em um host. Em seguida, os consumidores procuram pacotes úteis e compatíveis em hosts acessíveis, baixando e incluindo esses pacotes em seus projetos. Depois de instaladas em um projeto, as APIs dos pacotes estão disponíveis para o restante do código do projeto.

Compatibilidade de direcionamento de pacotes

Um pacote "compatível" significa que ele contém assemblies criados para pelo menos uma estrutura do .NET que é compatível com a estrutura de destino do projeto que o utiliza. Os desenvolvedores podem criar pacotes específicos para uma estrutura, como com controles UWP, ou podem dar suporte a uma gama mais ampla de destinos. Para maximizar a compatibilidade de um pacote, os desenvolvedores visam o .NET Standard, consumível por todos os projetos .NET e .NET Core. Esse é o meio mais eficiente para criadores e consumidores, pois um único pacote (geralmente contendo um único assembly) funciona para todos os projetos de consumo.

Os desenvolvedores de pacotes que exigem APIs fora do .NET Standard, por outro lado, criam assemblies separados para os diferentes frameworks de destino que desejam dar suporte e incluem todos esses assemblies no mesmo pacote (que é chamado de "multi-targeting"). Quando um usuário instala esse pacote, o NuGet extrai apenas os conjuntos necessários para o projeto. Isso minimiza o tamanho do pacote no aplicativo final e/ou conjuntos produzidos por este projeto. Um pacote multialvo é, naturalmente, mais difícil para o seu criador manter.

Ferramentas do NuGet

Além de hospedar o suporte, o NuGet também fornece uma variedade de ferramentas usadas por criadores e consumidores. Consulte Instalando ferramentas de cliente do NuGet para saber como obter ferramentas específicas.

Como você pode ver, as ferramentas do NuGet com as quais você trabalha dependem muito se você está criando, consumindo ou publicando pacotes e a plataforma na qual você está trabalhando. Os criadores de pacotes normalmente também são consumidores, pois eles se baseiam na funcionalidade que existe em outros pacotes NuGet. E esses pacotes, é claro, podem, por sua vez, depender de outros.

Para obter mais informações, comece com o artigo sobre o fluxo de trabalho de criação do pacote e o artigo sobre o fluxo de trabalho de consumo de pacotes .

Gerenciando dependências

A capacidade de se basear facilmente no trabalho de outras pessoas é um dos recursos mais poderosos de um sistema de gerenciamento de pacotes. Assim, grande parte do que o NuGet faz é gerenciar essa árvore de dependência ou "grafo" em nome de um projeto. Basta dizer que você só precisa se preocupar com os pacotes que você está usando diretamente em um projeto. Se qualquer um desses pacotes consumir outros pacotes (o que, por sua vez, pode consumir ainda outros), o NuGet cuidará de todas essas dependências de nível inferior.

A imagem a seguir mostra um projeto que depende de cinco pacotes, que, por sua vez, dependem de vários outros.

Observe que alguns pacotes aparecem várias vezes no grafo de dependência. Por exemplo, há três consumidores diferentes do pacote B e cada consumidor também pode especificar uma versão diferente para esse pacote (não mostrado). Essa é uma ocorrência comum, especialmente para pacotes amplamente usados. Felizmente, o NuGet faz todo o trabalho duro para determinar exatamente qual versão do pacote B atende a todos os consumidores. Em seguida, o NuGet faz o mesmo para todos os outros pacotes, independentemente da profundidade do grafo de dependência.

Para obter mais detalhes sobre como o NuGet executa esse serviço, consulte resolução de dependência.

Monitoramento de referências e restauração de pacotes

Como os projetos podem se mover facilmente entre computadores de desenvolvedores, repositórios de controle de código, servidores de build e assim por diante, é altamente impraticável manter os assemblies binários dos pacotes NuGet diretamente associados a um projeto. Isso tornaria cada cópia do projeto desnecessariamente inchada (e, portanto, desperdiçaria espaço em repositórios de controle do código-fonte). Também tornaria muito difícil atualizar binários de pacotes para versões mais recentes, pois as atualizações teriam que ser aplicadas em todas as cópias do projeto.

Em vez disso, o NuGet mantém uma lista de referência simples dos pacotes dos quais um projeto depende, incluindo dependências de nível superior e inferior. Ou seja, sempre que você instala um pacote de algum host em um projeto, o NuGet registra o identificador de pacote e o número de versão na lista de referência. (Desinstalar um pacote, é claro, remove-o da lista.) O NuGet então fornece um meio para restaurar todos os pacotes referenciados mediante solicitação, conforme descrito em restauração de pacote.

Com apenas a lista de referências, o NuGet pode reinstalar — ou seja, restaurar— todos esses pacotes de hosts públicos e/ou privados a qualquer momento posteriormente. Ao comprometer um projeto para o controle do código-fonte ou compartilhá-lo de alguma outra forma, você inclui apenas a lista de referência e exclui todos os binários de pacote (consulte Pacotes e controle do código-fonte.)

O computador que recebe um projeto, como um servidor de build que obtém uma cópia do projeto como parte de um sistema de implantação automatizado, simplesmente solicita ao NuGet que restaure as dependências sempre que forem necessárias. Sistemas de build como o Azure DevOps fornecem etapas de "restauração do NuGet" para essa finalidade exata. Da mesma forma, quando os desenvolvedores obtêm uma cópia de um projeto (como ao clonar um repositório), eles podem invocar comandos como nuget restore (CLI do NuGet), dotnet restore (CLI do dotnet) ou Install-Package (Console do Gerenciador de Pacotes) para obter todos os pacotes necessários. O Visual Studio, por sua vez, restaura automaticamente os pacotes ao criar um projeto (desde que a restauração automática esteja habilitada, conforme descrito na restauração de pacotes ).

Claramente, então, a função principal do NuGet em que os desenvolvedores estão preocupados é manter essa lista de referência em nome do seu projeto e fornecer os meios para restaurar (e atualizar) esses pacotes referenciados com eficiência. Essa lista é mantida em um dos dois formatos de gerenciamento de pacote , como são chamados:

• PackageReference (ou "referências de pacote em arquivos de projeto") | (NuGet 4.0+) mantém uma lista das dependências de nível superior de um projeto diretamente no arquivo de projeto, portanto, nenhum arquivo separado é necessário. Um arquivo associado, obj/project.assets.json, é gerado dinamicamente para gerenciar o grafo de dependência geral dos pacotes que um projeto usa junto com todas as dependências de nível inferior. PackageReference é sempre usado por projetos do .NET Core.

• packages.config: (NuGet 1.0+) um arquivo XML que mantém uma lista simples de todas as dependências do projeto, incluindo as dependências de outros pacotes instalados. Os pacotes instalados ou restaurados são armazenados em uma pasta packages.

Qual formato de gerenciamento de pacotes é empregado em qualquer projeto específico depende do tipo de projeto e da versão disponível do NuGet (e/ou do Visual Studio). Para verificar qual formato está sendo usado, basta procurar packages.config na raiz do projeto depois de instalar seu primeiro pacote. Se você não tiver esse arquivo, procure diretamente um elemento <PackageReference> no arquivo de projeto.

Quando você tem uma opção, é recomendável usar PackageReference. packages.config é mantido para fins herdados e não está mais em desenvolvimento ativo.

O que mais o NuGet faz?

Até agora, você aprendeu as seguintes características do NuGet:

• O NuGet fornece o repositório de nuget.org central com suporte para hospedagem privada.
• O NuGet fornece as ferramentas que os desenvolvedores precisam para criar, publicar e consumir pacotes.
• Mais importante, o NuGet mantém uma lista de referência de pacotes usados em um projeto e a capacidade de restaurar e atualizar esses pacotes dessa lista.

Para fazer com que esses processos funcionem com eficiência, o NuGet faz algumas otimizações nos bastidores. Mais notavelmente, o NuGet gerencia um cache de pacotes e uma pasta de pacotes globais para atalho de instalação e reinstalação. O cache evita baixar um pacote que já foi instalado no computador. A pasta de pacotes globais permite que vários projetos compartilhem o mesmo pacote instalado, reduzindo assim o volume geral do NuGet no computador. O cache e a pasta de pacotes globais também são muito úteis quando você está restaurando frequentemente um número maior de pacotes, como em um servidor de build. Para obter mais detalhes sobre esses mecanismos, consulte Gerenciamento de pacotes globais e pastas de cache.

Em um projeto individual, o NuGet gerencia o grafo de dependência geral, que inclui novamente a resolução de várias referências para versões diferentes do mesmo pacote. É bastante comum que um projeto tenha uma dependência em um ou mais pacotes que têm as mesmas dependências. Alguns dos pacotes utilitários mais úteis em nuget.org são empregados por muitos outros pacotes. Em todo o grafo de dependência, você poderia facilmente ter dez referências diferentes para versões diferentes do mesmo pacote. Para evitar trazer várias versões desse pacote para o próprio aplicativo, o NuGet classifica qual versão única pode ser usada por todos os consumidores. (Para obter mais informações, consulte Resolução de Dependência.)

Além disso, o NuGet mantém todas as especificações relacionadas à forma como os pacotes são estruturados (incluindo localização e símbolos de depuração ) e como eles são referenciados (incluindo intervalos de versões e versões de pré-lançamento ). O NuGet também fornece várias APIs para trabalhar com seus serviços programaticamente e oferece suporte para desenvolvedores que escrevem extensões para o Visual Studio e modelos de projeto.

Reserve um momento para navegar pelo sumário desta documentação e você verá todos esses recursos representados lá, juntamente com notas de versão que remontam ao início do NuGet.

Vídeo relacionado

Encontre vídeos do NuGet no Canal 9 e YouTube.

Comentários, contribuições e problemas

Por fim, damos as boas-vindas aos comentários e contribuições para esta documentação: basta selecionar os comandos Feedback e Editar na parte superior de qualquer página ou visitar o repositório da documentação e lista de issues da documentação no GitHub.

Também damos boas-vindas às contribuições para o NuGet por meio de sua vários repositórios do GitHub; Os problemas do NuGet podem ser encontrados no https://github.com/NuGet/home/issues.

Aproveite sua experiência do NuGet!