Escolha o Gerenciador de Pacotes NuGet adequado e configure-o com o IIS

Construiu uma aplicação ou talvez até um conjunto de scripts importantes e precisa empacotá-los e implantá-los. Não procure mais do que o NuGet e os vários gestores de pacotes NuGet disponíveis.

Neste artigo, você vai aprender como configurar vários gestores de pacotes NuGet pela primeira vez, para que possa começar a usá-los imediatamente.

Relacionado: Configurando o Servidor NuGet no Windows (Guia Completo)

Configurando um Invólucro NuGet.Server

Embora configurar um NuGet.Server do zero não seja muito complicado, pode levar um tempo para alguém novo no Visual Studio e IIS. Uma maneira de acelerar o processo de configuração e atualização é com um invólucro. Um dos invólucros mais populares, chamado nuget-server, é escrito por svenkle e pode ser encontrado na página do Github deles.

Uma das principais diferenças ao usar este invólucro em vez de instalar manualmente o servidor web é que ele usa o IIS Express. Você pode ler mais sobre as diferenças na página da Microsoft.

Há duas diferenças importantes entre configurar um NuGet.Server comum e com este invólucro:

• você deve criar um serviço do Windows para iniciar o servidor web
• você não pode usar o Gerenciador do IIS para a configuração

A principal desvantagem de usar um invólucro para instalar o NuGet.Server é que você não pode facilmente atualizar a versão até que o invólucro seja atualizado.

Pré-requisitos

Se você deseja aprender como configurar este invólucro do NuGet.Server, primeiro você precisará garantir que tenha o seguinte:

• Instalador para o invólucro do NuGet.Server de svenkle
• Windows Server – Qualquer versão atualmente suportada do Windows Server funcionará, mas todas as capturas de tela foram feitas no Windows Server 2019 Standard

Instalando o Serviço de Servidor Web

O primeiro passo é criar um novo serviço do Windows. Como este invólucro do NuGet.Server não usa o IIS, você não pode aproveitar o IIS.

Com o arquivo NuGetServer.zip baixado da página de lançamentos, descompacte o arquivo para o diretório de sua escolha no servidor web. Depois de descompactado, crie o serviço do Windows para iniciar automaticamente a página da web quando você iniciar o servidor. Abaixo, você encontrará um comando do PowerShell para fazer isso por você.

New-Service -Name NuGetServer -BinaryPathName '<UnzipPath>\Svenkle.NuGetServer.Service.exe' -StartupType Automatic
Start-Service -Name NuGetServer

Personalizando o Servidor Web

Agora que você tem o NuGet.Server instalado a partir do wrapper e o serviço está criado e iniciado, é hora de personalizar o arquivo web.config. Você pode fazer as mesmas alterações que faria no arquivo web.config com a implantação manual, se desejar.

O arquivo web.config está localizado na pasta <UnzipPath>\Host\Website. A diferença principal desta implantação é que ela usa a porta 8080 em vez da porta HTTP padrão 80. Isso significa que em qualquer lugar onde você usaria a URL da web, você deve acrescentar :8080, por exemplo, quando acessar a página da web, seria http://localhost:8080/nuget.

Tudo pronto. Isso foi muito mais fácil do que usar o Visual Studio!

Configurando o BaGet no IIS

Até agora, você só viu as versões padrão do NuGet.Server, mas existem muitas outras versões disponíveis por aí. Um gerenciador de pacotes NuGet popular é um projeto de código aberto chamado BaGet.

Vamos ver o que é necessário para instalar e executar o BaGet em um servidor Windows com o IIS.

Pré-requisitos

Antes de começar, verifique se você atende a alguns pré-requisitos.

• BaGet.zip – No momento em que este guia foi escrito, o projeto ainda está em pré-lançamento e estou usando a versão 0.1.77.
• Pacote de tempo de execução e hospedagem do .NET Core – Isso precisará ser baixado e disponível no servidor da web posteriormente.
• Windows Server – Qualquer versão atualmente suportada da versão do Windows Server funcionará, mas todas as capturas de tela foram feitas no Windows Server 2019 Standard

Instalando Pré-requisitos do Servidor Web

Embora as etapas abaixo possam ser executadas no Linux com o .NET Core ou em uma imagem Docker, estas instruções serão usadas para instalar o BaGet em um servidor Windows. Dessa forma, você pode aproveitar o IIS para iniciar e parar o seu servidor.

Instale o IIS

Dado que o BaGet roda no .NET Core, não há tantos requisitos quanto o NuGet.Server básico para o qual você instalou o IIS anteriormente. Você só precisa de um servidor web IIS padrão e do gerenciador IIS. Para instalá-los, abra uma sessão do PowerShell em seu servidor web e execute:

Install-WindowsFeature Web-Server -IncludeManagementTools

Instale o .NET Core

Em seguida, instale o pacote .NET Core no servidor web. Para fazer isso, execute o arquivo exe que você baixou anteriormente. Você pode deixar todas as opções como padrão para esta instalação.

O pacote .NET Core deve ser instalado após a instalação do IIS. Se isso não acontecer na ordem correta, será necessário executar novamente o instalador do pacote .NET Core e selecionar a opção de reparo para adicionar os requisitos ausentes para um aplicativo web.

Agora que você tem os componentes do servidor web prontos, descompacte o arquivo BaGet.zip baixado anteriormente e coloque-o na pasta C:\inetpub\wwwroot em seu servidor web.

Configurando a Aplicação do Servidor Web

Similar ao NuGet.Server, você precisará configurar alguns componentes do IIS para fazer o gerenciador de pacotes NuGet, o BaGet, funcionar.

Criando o Pool de Aplicativos do BaGet no IIS

Abra o Gerenciador do IIS no servidor web e vá para os Pools de Aplicativos. Crie um novo pool de aplicativos para o BaGet, já que ele não usará código gerenciado .NET. Você pode nomeá-lo como desejar. Abaixo está como deveria ficar.

Criando o Website do BaGet

Depois que o pool de aplicativos for criado, crie o website. Como o BaGet usa uma porta HTTP não padrão e um pool de aplicativos não padrão, é mais fácil criar um website separado do Site da Web Padrão. Para fazer isso, clique com o botão direito no diretório Sites no Gerenciador do IIS e selecione Adicionar Website.

Abaixo estão as configurações que você precisa ajustar para o BaGet.

Depois de configurar o site, ele deve iniciar automaticamente. Você pode dar uma olhada nele acessando http://localhost:5000/ do seu servidor.

Você notará que há uma interface de usuário mais completa na página do BaGet em comparação com a página padrão do NuGet.Server. No BaGet, você pode facilmente buscar pacotes que foram enviados e ele também fornece os comandos sobre como fazer o upload de várias maneiras, em vez de usar as opções de linha de comando do NuGet.

Personalizando o Servidor Web do BaGet

Lembre-se de que você foi capaz de personalizar o seu servidor NuGet usando o arquivo web.config. Mas o gerenciador de pacotes NuGet BaGet não utiliza o arquivo web.config. Em vez disso, como o BaGet também pode ser usado no Linux, os desenvolvedores optaram por um formato mais multiplataforma com um arquivo JSON chamado appsettings.json. Ele está localizado na pasta C:\inetpub\wwwroot\BaGet.

Observe que, como o BaGet utiliza o .NET Core para funcionalidade multiplataforma, todos os caminhos usam barras diagonais para frente.

Por exemplo, se você quiser que o caminho do seu pacote seja C:\Packages no seu servidor, você precisará ter o que está mostrado abaixo no arquivo appsettings.json.

"Storage": {
    "Type": "FileSystem",
    "Path": "C://Packages"
}

Chave da API BaGet

Para proteger seu servidor NuGet de usuários não autorizados que publicam ou excluem pacotes, você ainda vai querer definir uma chave da API. A configuração da chave da API também está localizada no arquivo appsettings.json, então você pode configurá-la enquanto estiver lá.

Como estou usando o PowerShell para gerenciar meus pacotes NuGet, posso registrar novamente um PSRepository. Para o BaGet, vá para a página da web que você criou. A página da web fornecerá o comando a ser executado na sua sessão do PowerShell. Por exemplo:

Register-PSRepository -Name "BaGet" -SourceLocation "http://<WebServer>:5000/v3/index.json" -PublishLocation "http://<WebServer>:5000/api/v2/package" -InstallationPolicy "Trusted"

Compreendendo os Forks do BaGet (LiGet)

Embora o BaGet forneça muitas opções de uso, existem outros forks do BaGet que foram criados para se especializar em outras áreas do NuGet. Um dos forks mais populares é o LiGet. O LiGet é diferente porque se especializa com uma visão voltada para o Linux.

LiGet é um fork do gerenciador de pacotes NuGet do projeto original para o BaGet. Houve algumas razões pelas quais os desenvolvedores decidiram fazer isso, mas principalmente foi feito para focar em algumas características específicas do NuGet, incluindo o suporte ao feed v3. O suporte ao feed v3 não afeta o caso de uso com o PowerShell. Mas se você estiver hospedando um servidor NuGet para outros casos de uso, pode gostar da funcionalidade adicional.

A Chave de API Hashed do LiGet

Uma grande diferença entre o LiGet e o BaGet é o uso de uma chave de API hash em vez de texto simples. Com uma chave de texto simples, alguém com acesso ao arquivo web.config no NuGet.Server ou ao appsettings.json no BaGet poderia publicar no servidor. Isso não poderia acontecer com o LiGet.

Para configurar o LiGet e fazê-lo funcionar, você precisará criar uma chave de API hash e colocá-la no arquivo appsettings.json na pasta C:\inetpub\wwwroot\LiGet.

Para criar o hash, você pode usar o PowerShell ou qualquer outro método de hash com o qual se sinta confortável. Abaixo está um exemplo do que você executaria em sua estação de trabalho para criar um hash.

([System.Security.Cryptography.HashAlgorithm]::Create('SHA256').ComputeHash([System.Text.Encoding]::UTF8.GetBytes(<apikey>)) | 
Foreach-Object { $_.ToString('x2')}) -join ''

Você também pode usar um gerador de hash online para criar o hash.

A desvantagem deste método é que se você esquecer a chave da API, precisará criar um novo hash e substituí-lo, já que o hash não é reversível.

Configurando o ProGet no IIS

Todas as opções cobertas até agora são gratuitas e não têm muitas partes móveis após a configuração. Embora isso seja bom para experimentar o NuGet, se você deseja integrar com outras ferramentas ou se precisa de suporte do fornecedor para um sistema no local de trabalho, uma opção melhor pode ser o gerenciador de pacotes NuGet ProGet.

Pré-requisitos

Para configurar o ProGet, você precisará de alguns pré-requisitos comuns com os quais você provavelmente está acostumado, mas com a adição de um banco de dados SQL opcional.

• Windows Server – Qualquer versão atualmente suportada do Windows Server funcionará, mas todas as capturas de tela foram feitas no Windows Server 2019 Standard
• ProGet Installer – A versão do ProGet que estou usando é a 5.2.9.
• Instância SQL – Isso é opcional, pois o ProGet tem uma opção para instalar o SQL Express a partir do instalador, embora isso exija uma conexão com a Internet do seu servidor para o download inicial

Instalando o ProGet

A partir do seu servidor web, execute o instalador do ProGet. Como você está configurando o IIS, selecione a opção Servidor web IIS ao instalar o ProGet. Se você ainda não tiver o IIS instalado, ele cuidará da instalação durante a instalação do ProGet.

O restante das opções pode ser deixado como padrão, a menos que você queira hospedar o banco de dados do ProGet em um servidor SQL separado. Nesse caso, você precisará especificar a instância SQL a ser usada.

Se você deixar a opção SQL Server como Instalar instância Inedo, ele instalará o servidor SQL Express para você.

Após a conclusão da instalação, inicie o site quando solicitado e você verá uma página da web que se parece com a captura de tela abaixo.

Configurando um PSRepository no ProGet

Neste ponto, o ProGet está instalado. É bastante fácil. Como estamos usando o PowerShell para trabalhar com pacotes NuGet, precisaremos configurar um PSRepository, como já fizemos anteriormente.

Para configurar o ProGet para um PSRepository, navegue até a guia Feeds e crie um novo feed. Você pode nomear o feed como quiser. Em seguida, selecione Formato de pacote de terceiros e PowerShell, como mostrado abaixo.

Depois de criar o feed, volte para a guia Feeds, selecione seu novo feed e ele mostrará a URL usada para publicação. Isso é o que você precisaria executar no PowerShell em um dispositivo para publicar ou baixar deste PSRepository.

Abaixo está o que foi mostrado com o exemplo acima:

Register-PSRepository -Name ProGet -SourceLocation http://<WebServer>:8624/nuget/PSRepository/ -PublishLocation http://<WebServer>:8624/nuget/PSRepository/ -InstallationPolicy Trusted

Adicionando uma chave de API

Assim como as outras opções, você precisa gerar uma chave de API. Para fazer isso, clique no ícone de engrenagem no canto superior direito e selecione Chaves de API na barra de ferramentas esquerda. Aqui você pode ver as chaves de API existentes e criar novas. Você verá imediatamente uma diferença principal entre o ProGet de código aberto e o ProGet empresarial. Com o ProGet, você pode ter várias chaves de API.

Na tela de Chaves da API, clique em Criar Chave da API. A partir daqui, marque a caixa para Feed da API e clique em Salvar Chave da API.

Uma vez que a chave da API for criada, você será levado de volta à página de chaves da API. A partir daqui, você pode usar a chave da API que você vê para publicar pacotes no seu feed.

Procurando Pacotes com o ProGet

O ProGet também inclui uma página da web que permite buscar todos os pacotes NuGet no feed, ver sua contagem de downloads, o nome dos módulos PowerShell, em qual feed um pacote foi enviado e outras estatísticas similares de pacotes na página de Pacotes, como mostrado abaixo.

Alternativamente, você pode ir para a página de Feeds e selecionar um feed para ver apenas os pacotes desse feed. Lá, você pode aprofundar nos pacotes individuais para ver as estatísticas e outros detalhes sobre os pacotes, como mostrado abaixo.

Atualizando o ProGet

Uma das partes boas de usar um produto que se posicionou para uma empresa é que algumas das tarefas administrativas mais demoradas são muito mais rápidas. Um exemplo disso é atualizar o ProGet.

Para atualizar o ProGet para a versão mais recente, simplesmente abra o Instalador da Inedo no seu servidor web. Isso foi instalado quando você instalou o ProGet pela primeira vez. Clique no botão Atualizar e mostrado abaixo, e o instalador fará o resto para você.

Comparação de Gerenciadores de Pacotes NuGet

Você aprendeu muito sobre várias ferramentas NuGet neste artigo. Se você ainda está procurando qual experimentar, nesta seção, você terá um vislumbre do que torna cada uma diferente.

BaGet vs. LiGet

Como o LiGet é um fork do BaGet, eles compartilham muitas semelhanças, incluindo a maioria do processo de configuração. Na verdade, você pode seguir exatamente o mesmo procedimento de configuração que o BaGet.

Uma vez instalados, o LiGet e o BaGet compartilham algumas características, mas diferem em outros aspectos.

Embora a maioria dessas diferenças não afete o uso com o PowerShell, a configuração muda um pouco devido ao uso de uma chave de API hash.

Ambos BaGet e LiGet são construídos no .NET Core, o que os torna multiplataforma e utilizáveis em sistemas operacionais Linux, bem como no Windows. Ambos também têm imagens Docker disponíveis, o que, se você já estiver usando um serviço de contêiner, pode acelerar e tornar o processo mais portátil.

Com as poucas diferenças entre LiGet e BaGet, qualquer um deles é uma ótima opção para um servidor NuGet de código aberto e compatível com contêineres. Ambas as opções permitem que você experimente um servidor NuGet no Windows e, ao mesmo tempo, facilitem a transição para o Linux ou uma imagem Docker no futuro sem muito trabalho adicional.

BaGet vs ProGet

Se preferir não criar o seu próprio, em algum grau, e seguir o caminho mais fácil, há sempre o ProGet. No entanto, há desvantagens. O ProGet não é de código aberto e não é gratuito de forma alguma. Mas é mais fácil de configurar e trabalhar.

Há algumas diferenças importantes entre o ProGet e o BaGet.

A Inedo também tem uma análise de todas as diferenças de recursos entre as versões do ProGet.

Resumo

Neste artigo, você aprendeu muito sobre várias ferramentas e tecnologias do NuGet. Se você estava em dúvida sobre qual servidor NuGet usar, agora deve ter muito mais conhecimento para ajudá-lo a tomar essa decisão.

Você aprendeu sobre como configurar cada ferramenta NuGet para funcionar com o Windows e cobrimos muitos dos recursos de cada uma.