Escolha o Gerenciador de Pacotes NuGet Correto e Configure-o com o IIS

Você construiu um aplicativo ou talvez até mesmo um conjunto de scripts importantes e precisa empacotá-lo e implantá-lo. Não procure mais do que o NuGet e os vários gerenciadores de pacotes NuGet disponíveis.

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

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

Configurando um Wrapper 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 wrapper. Um dos wrappers mais populares, chamado nuget-server, é escrito por svenkle e pode ser encontrado em sua página do Github.

Uma das principais diferenças de usar este wrapper em vez de instalar manualmente o servidor web é que ele usa o IIS Express. Você pode ler mais sobre as diferenças no site da Microsoft.

Existem duas diferenças importantes entre configurar um NuGet.Server padrão e com este wrapper:

• 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 certifique-se de ter 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 do Servidor Web

O primeiro passo é criar um novo serviço do Windows. Como este invólucro do NuGet.Server não utiliza o IIS, não é possível aproveitar o IIS.

Com o arquivo NuGetServer.zip baixado da página de lançamentos, descompacte o arquivo no diretório de sua escolha no servidor web. Após descompactar, 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ê instalou o NuGet.Server a partir do pacote e o serviço foi 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 grande diferença com essa implantação é que ela usa a porta 8080 em vez da porta HTTP padrão 80. Isso significa que em qualquer lugar em que você usaria a URL da web, você deve adicionar :8080, como ao 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

Enquanto você estava olhando apenas para versões padrão do NuGet.Server até agora, 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 texto foi escrito, o projeto ainda estava em pré-lançamento e estou usando a versão 0.1.77
• .NET Core Runtime & Hosting Bundle – Isso precisará ser baixado e estar disponível no servidor web posteriormente.
• 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 Pré-requisitos do Servidor Web

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

Instalar o IIS

Como o BaGet roda no .NET Core, não há tantos requisitos como 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 do IIS. Para instalar estes, abra uma sessão do PowerShell em seu servidor web e execute:

Install-WindowsFeature Web-Server -IncludeManagementTools

Instalar o .NET Core

Em seguida, instale o pacote do .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 do .NET Core deve ser instalado após o IIS ser instalado. Se isso não acontecer na ordem correta, você terá que executar novamente o instalador do pacote do .NET Core e selecionar reparar 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 colocar o gerenciador de pacotes NuGet BaGet em funcionamento.

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, pois ele não usará código gerenciado .NET. Você pode nomeá-lo como quiser. Abaixo está como deve ser.

Criando o Site do BaGet

Depois que o pool de aplicativos for criado, crie o site. 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 site separado do Site da Web Padrão. Para fazer isso, clique com o botão direito no folder Sites no Gerenciador do IIS e selecione Adicionar Site.

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

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

Você notará que há uma interface de usuário mais ampla na página da web do BaGet em comparação com a página da web padrão do NuGet.Server. No BaGet, você pode facilmente pesquisar pacotes que foram enviados e também fornece os comandos sobre como fazer 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ê conseguiu personalizar o seu servidor NuGet.Server usando o arquivo web.config. Mas o gerenciador de pacotes NuGet BaGet não usa 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 usa o .NET Core para funcionalidade multiplataforma, todos os caminhos usam barras (/) em vez de barras invertidas (\).

Por exemplo, se você quiser que o caminho dos seus pacotes seja C:\Packages em seu servidor, você precisará ter o seguinte no arquivo appsettings.json.

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

Chave de API do BaGet

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

Como estou usando o PowerShell para gerenciar meus pacotes NuGet, novamente posso registrar um PSRepository. Para o BaGet, acesse a página da web que você criou. A página da web fornecerá o comando a ser executado em 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"

Entendendo os “Forks” do BaGet (LiGet)

Embora o BaGet ofereç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 em uma abordagem voltada para o Linux.

A Chave de API Hashada do LiGet

Uma grande diferença entre LiGet e BaGet é o uso de uma chave de API hashada 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 colocar o LiGet em funcionamento, você precisará criar uma chave de API hashada 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 esteja 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, será necessário criar um novo hash e substituí-lo, pois o hash não é reversível.

Configurando o ProGet no IIS

Todos as opções abordadas até agora são gratuitas e não têm muitas partes móveis depois de configuradas. 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 ambiente 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 já está familiarizado, 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.
• Instalador do ProGet – A versão do ProGet que estou usando é a 5.2.9.
• Instância SQL – Isso é opcional, pois o ProGet tem a opção de 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

Execute o instalador do ProGet em seu servidor web. 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 você pode deixar como padrão, a menos que 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, ela instalará o servidor SQL Express para você.

Assim que a instalação terminar, inicie o site quando solicitado e você deverá 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 antes.

Para configurar o ProGet para um PSRepository, vá até a guia Feeds e crie um novo feed. Você pode dar o nome que quiser ao feed. Em seguida, selecione Formato de pacote de terceiros e PowerShell, conforme mostrado abaixo.

Depois de criar o feed, volte para a guia Feeds, selecione o novo feed e ele mostrará a URL usada para publicar. 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 nas 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 lateral esquerda. Aqui você pode ver as chaves de API existentes e pode 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 muitas chaves de API.

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

Assim que a chave da API for criada, você será redirecionado para a página de chaves de API. A partir daqui, você pode usar a chave da API que visualiza para publicar pacotes em seu feed.

Buscando Pacotes com o ProGet

O ProGet também inclui uma página da web que permite pesquisar 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 de pacotes similares da página de Pacotes conforme 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 detalhar os pacotes individuais para ver as estatísticas e outros detalhes sobre os pacotes conforme mostrado abaixo.

Atualizando o ProGet

Uma das partes boas de usar um produto que foi posicionado 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, basta abrir o Instalador Inedo em seu servidor web. Isso foi instalado quando você instalou o ProGet pela primeira vez. Clique no botão Atualizar e como mostrado abaixo, 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 ainda estiver procurando por qual experimentar, nesta seção, você terá uma visão 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 do BaGet.

Uma vez instalados, o LiGet e o BaGet compartilham algumas funcionalidades, 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 com hash.

Tanto o BaGet quanto o 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 do Docker disponíveis, que, se você já estiver usando um serviço de contêineres, podem tornar a configuração muito mais rápida e portátil.

Com as poucas diferenças entre o LiGet e o 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, permitam a migração para o Linux ou uma imagem do Docker no futuro, sem muito trabalho extra.

BaGet vs ProGet

Se você preferir não criar algo do zero e seguir o caminho mais fácil, sempre há o ProGet. No entanto, existem 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 faz 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 indeciso sobre qual servidor NuGet usar, agora deve ter muito mais conhecimento para ajudar a tomar essa decisão.

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