NuGet

Gerencie as bibliotecas de projetos com o NuGet

Phil Haack

Por mais que tente, a Microsoft não consegue atender a todas as necessidades possíveis de biblioteca dos desenvolvedores. Embora a Microsoft empregue quase 90.000 pessoas no mundo todo, o mundo possui milhões de desenvolvedores. Não faz sentido para a Microsoft tentar preencher cada nicho, nem ela está dimensionada para isso. Portanto, os desenvolvedores frequentemente assumem a responsabilidade para “se virarem sozinhos” e escrevem milhares e milhares de bibliotecas úteis que são distribuídas em toda a Web.

O problema com tantas bibliotecas é compartilhá-las. Compartilhar e reutilizar código é um grande desafio. Não acredita? Entre em qualquer loja de médio a grande porte e pergunte quantas bibliotecas de registro em log eles possuem. Visite empresas suficientes e você encontrará uma alta porcentagem de bibliotecas de registro em log internas quando já existem boas bibliotecas, como Log4Net, NLog e ELMAH (módulos e manipuladores de log de erros).

Quando um desenvolvedor inicia um novo projeto, ele enfrenta o problema da tela vazia. Como encontrar essas bibliotecas úteis? Como incorporar uma biblioteca no projeto atual e gerenciar suas dependências e atualizações?

O ELMAH é um ótimo exemplo de uma biblioteca útil que os desenvolvedores assumiram a responsabilidade de escrever. O ELMAH registra em log todas as exceções sem tratamento de um aplicativo Web, juntamente com todas as informações da solicitação, como cabeçalhos, variáveis do servidor, etc., quando uma exceção é gerada. Suponha que você acabou de ouvir falar do ELMAH e deseja usá-lo em seu próximo projeto.

Aqui estão as etapas que você deve executar:

1. Localize o ELMAH. Devido ao seu nome exclusivo, uma pesquisa no Bing localiza a página de código do ELMAH no Google como o primeiro resultado.
2. Baixe o pacote zip correto. A página de download do site possui vários pacotes zip. Pense e escolha o pacote correto. Às vezes a opção correta não é intuitiva.
3. “Desbloqueie” o pacote. Depois de baixar o pacote da Web, clique com o botão direito do mouse no arquivo, abra a caixa de diálogo Propriedades e clique no botão Desbloquear para remover a “marca da Web” do arquivo.
4. Verifique o hash em relação ao fornecido pelo ambiente de hospedagem. O site de código do Google exibe um código QR que representa o arquivo zip. Quantos desenvolvedores você conhece que se preocupam em verificar o arquivo em relação ao código QR?
5. Descompacte o conteúdo do pacote em um local específico na solução. A maioria dos desenvolvedores evita desempacotar assemblies no diretório bin, porque o diretório se destina à saída da compilação, não à entrada, e não é acompanhado pelo controle de versão. É importante adicionar a dependência a uma pasta confirmada para o controle de versão e referenciar o assembly a partir desse local.
6. Adicione ao projeto uma referência ao assembly. O assembly não é utilizável enquanto você não adicionar uma referência a ele no projeto do Visual Studio.
7. Atualize o web.config com as configurações corretas. Isso pode significar mais do que pesquisar usando o Bing ou o Google enquanto você tenta encontrar as configurações corretas necessárias para o arquivo de configuração.

Que dificuldade! Agora, suponha que você precise fazer isso para 10 a 15 dependências. Quando chega a hora de lançar a versão seguinte do seu aplicativo, você gasta um tempo significativo procurando atualizações para as suas dependências.

Aquela noção frequentemente difamada, NIH (“não inventado aqui”), começa a soar como uma boa ideia.

Salvação com o NuGet

O NuGet é uma extensão do Visual Studio que facilita a adição, atualização e remoção de bibliotecas (implantadas como pacotes) em um projeto do Visual Studio. Um pacote do NuGet é um conjunto de arquivos empacotados em um único arquivo com a extensão .nupkg e usando o formato OPC (Open Packaging Conventions).

O OPC é apenas um acrônimo sofisticado para um arquivo zip com alguns metadados. De fato, provavelmente você já está familiarizado com o OPC, pois esse é o formato usado em documentos do Word e do Excel. Se você alguma vez alterou a extensão de um arquivo .docx para .zip, sabe que pode abri-lo e esquadrinhar o seu interior. O mesmo acontece com os arquivos .nupkg.

O produto NuGet também fornece utilitários para criar e publicar pacotes com facilidade. Por enquanto, vou abordar o uso do NuGet para descobrir e instalar pacotes. Posteriormente, falaremos sobre como criar e publicar pacotes.

Instalando o NuGet

Para instalar o NuGet, inicie o Gerenciador de Extensões do Visual Studio por meio da opção de menu Ferramentas | Gerenciador de Extensões. Clique na guia Galeria Online para exibir as extensões do Visual Studio disponíveis, como mostra a Figura 1. Como pode ver, o NuGet é o pacote com a melhor classificação, o que o coloca na primeira tela. Se isso mudar, você poderá usar a caixa de pesquisa na parte superior direita para encontrá-lo. Clique no botão Download para instalar o NuGet.

Figura 1 Gerenciador de Extensões do Visual Studio

Se você instalou o ASP.NET MVC 3, o NuGet já está instalado. O ASP.NET MVC 3 inclui o NuGet, e a Microsoft planeja incluir o NuGet na próxima versão do Visual Studio.

Instalando um pacote

Vamos começar com a caixa de diálogo do NuGet, amigável para o usuário, para instalar pacotes. O NuGet também apresenta um console baseado no Windows PowerShell, destinado aos usuários avançados, e que eu abordarei posteriormente.

Para iniciar o NuGet, clique com o botão direito do mouse no nó de referências do projeto e selecione a opção Manage NuGet Packages (esta opção tinha um rótulo diferente antes do NuGet 1.4). Isso abre a caixa de diálogo Manage NuGet Packages, mostrada na Figura 2.

Figura 2 Caixa de diálogo de gerenciamento de pacotes do NuGet

Verifique se a guia Online está selecionada e digite um termo de pesquisa no canto superior direito (por exemplo, procure o MiniProfiler, uma biblioteca útil do pessoal da StackOverflow.com).

Quando localizar um pacote, clique no botão Install para instalá-lo. O NuGet então baixa o pacote e suas dependências e aplica ao seu projeto as alterações necessárias especificadas pelos pacotes.

O NuGet executa as seguintes etapas para instalar um pacote:

1. Baixa o arquivo de pacote e todas as suas dependências. Alguns pacotes requerem a aceitação explícita da licença e pedem que o usuário aceite os termos da licença do pacote. A maioria dos pacotes se limita à aceitação implícita da licença e não faz a solicitação. Se o pacote já existir na solução ou no cache do computador local, o NuGet irá ignorar o download do pacote.
2. Extrai o conteúdo do pacote. O NuGet extrai o conteúdo na pasta de pacotes, criando a pasta se necessário. Essa pasta está localizada próxima ao arquivo da sua solução (.sln). Se o mesmo pacote for instalado em vários projetos de uma solução, ele só será extraído uma vez e será compartilhado pelos projetos.
3. Referencia assemblies no pacote. Por convenção, o NuGet atualiza o projeto para referenciar um ou mais assemblies apropriados na pasta lib de pacotes. Por exemplo, ao instalar um pacote em um projeto destinado ao Microsoft .NET Framework 4, o NuGet adicionará referências aos assemblies da pasta lib/net40.
4. Copia o conteúdo no projeto. Por convenção, o NuGet copia o conteúdo da pasta de conteúdo do pacote no projeto. Esse procedimento é útil para os pacotes que contêm arquivos ou imagens JavaScript.
5. Aplica transformações de pacote. Se qualquer pacote contiver arquivos de transformação, como app.config.transform ou web.config.transform para configuração, o NuGet aplicará essas transformações antes de copiar o conteúdo. Alguns pacotes podem conter código-fonte que pode ser transformado para incluir o namespace do projeto atual no arquivo de origem. O NuGet transforma esses arquivos também.
6. Executa scripts associados do Windows PowerShell no pacote. Alguns pacotes podem conter scripts do Windows PowerShell que automatizam o Visual Studio usando DTE (Ambiente em tempo de design) para manipular tarefas para as quais o NuGet não foi projetado.

Depois que o NuGet executar todas essas etapas, a biblioteca estará pronta para uso. Muitos pacotes se conectam usando o pacote WebActivator para minimizar qualquer configuração necessária após a instalação.

Um pacote pode ser desinstalado, fazendo com que o seu projeto retorne ao estado anterior à instalação do pacote.

Atualizando pacotes

Em seu livro “Facts and Fallacies of Software Engineering” (Addison-Wesley Professional, 2002), Robert L. Glass diz: “A manutenção geralmente consome cerca de 40% a 80% (em média 60%) dos custos do software. Portanto, é provavelmente a fase mais importante do ciclo de vida”.

A instalação de um pacote é apenas o início da história. Com o tempo, à medida que for feita a manutenção dessas bibliotecas, será importante manter o seu aplicativo atualizado com as correções de bugs mais recentes para as bibliotecas. Isso requer uma resposta sua à pergunta “Quais dependências deste projeto possuem novas atualizações disponíveis?”

Como mencionei anteriormente, a resposta a essa pergunta sempre exigiu um grande esforço. Porém, com o NuGet, basta abrir a caixa de diálogo e clicar na guia Updates para ver uma lista de pacotes com atualizações disponíveis, como mostra a Figura 3. Clique no botão Update para atualizar o pacote para a versão mais recente.

Figura 3 Atualizações disponíveis para o projeto atual

O comando de atualização desinstala o pacote antigo e instala o novo, garantindo que todas as dependências sejam atualizadas adequadamente, se necessário.

O NuGet fornece comandos no Package Manager Console para melhor controlar as atualizações — como atualizar todos os pacotes da solução ou executar uma atualização “segura”, por exemplo.

NuGet para usuários avançados

Embora eu seja um grande fã de boas caixas de diálogo da GUI, conheço muitos desenvolvedores que desdenham pessoas que arrastam o mouse, como eu. Esse pessoal prefere um shell da linha de comando como a interface do usuário para sua capacidade de compor conjuntos de comandos.

O NuGet preenche essa necessidade com uma janela de console baseada no Windows PowerShell, chamada Package Manager Console, bem como um conjunto de comandos do Windows PowerShell para interação com o NuGet. O Windows PowerShell, um shell de linguagem de script e linha de comando baseado no .NET, é bem adequado para compor conjuntos de comandos e trabalhar com objetos.

Para iniciar o Package Manager Console, navegue até a opção de menu Tools | Library Package Manager | Package Manager Console.

Listando e instalando pacotes

Para listar e procurar pacotes, use o comando Get-Package. Por padrão, o comando lista pacotes instalados no projeto atual. Você pode procurar pacotes online especificando o sinalizador ListAvailable combinado com o sinalizador Filter. O comando a seguir procura todos os pacotes que mencionam “MVC”:

Get-Package -ListAvailable -Filter Mvc

Quando encontrar um pacote para instalar, use o comando Install-Package. Por exemplo, para instalar o ELMAH no projeto atual:

Install-Package Elmah

Como o Windows PowerShell é uma linguagem dinâmica, ele pode fornecer expansões de guias para ajudar você a inserir corretamente os argumentos de comando. As expansões de guias são equivalentes ao IntelliSense para C#, porém, ao contrário do IntelliSense, que se baseia em informações em tempo de compilação, as expansões de guias podem ser populadas em tempo de execução.

Por exemplo, se você digitar Install-Package Mvc{guia}, verá uma lista de possíveis nomes de pacotes da origem do pacote, como mostra a Figura 4.

Figura 4 Uma lista de pacotes de guia expandida

Atualizando pacotes

O Package Manager Console também inclui um comando que permite maior controle das atualizações do que a caixa de diálogo. Por exemplo, chame este comando, sem nenhum argumento, para atualizar todos os pacotes de todos os projetos da solução:

Update-Package

Esse comando tenta atualizar cada pacote para a versão mais recente. Portanto, se você tiver a versão 1.0 de um pacote e as versões 1.1 e 2.0 estiverem disponíveis na origem do pacote, esse comando atualizará o pacote para a versão 2.0, porque ela é a mais recente.

Essa ação poderá ser drástica se algum pacote contiver alterações de quebra. Em muitos casos, você deseja apenas atualizar cada pacote para a versão de correção de bug mais recente. Essa atualização é chamada de “segura” e pressupõe que os pacotes com um número de compilação ou revisão maior (porém com os mesmos números principal e secundário) sejam compatíveis com versões anteriores. Basta adicionar o sinalizador Safe para executar uma atualização segura, desta forma:

Update-Package -Safe

Nesse caso, se você tiver a versão 1.0.0 de um pacote instalada e as versões 1.0.1 e 1.1 estiverem disponíveis na origem do pacote, ele será atualizado com segurança para a versão 1.0.1 e não para a versão 1.1.

O comando Update-Package também fornece mais granularidade, como a atualização de um pacote para uma versão específica, em vez da versão mais recente.

Estendendo o Visual Studio com novos comandos

Embora a capacidade de usar o Windows PowerShell para instalar pacotes seja boa, ela não é o motivo mais atrativo para escolher o Windows PowerShell. Um dos motivos mais atrativos é que os pacotes podem adicionar novos comandos ao Package Manager Console. Esses comandos podem interagir com o DTE do Visual Studio para executar várias tarefas.

Por exemplo, instale o pacote MvcScaffolding e ele adicionará um novo comando Scaffold Controller ao console. Dado um objeto Code First do Entity Framework (EF), esse comando gera um controlador, ações do controlador e exibições correspondentes às operações básicas CRUD (Create, Read, Update e Delete) do objeto do EF, como se vê na Figura 5.

Figura 5 Comando Scaffold personalizado MvcScaffolding em ação

NuGet na sua organização

Com todo esse foco sobre como o NuGet facilita o compartilhamento de bibliotecas com a comunidade pública de desenvolvedores, é fácil deixar passar a utilidade do NuGet na empresa.

Afinal, não há nada especial nas empresas que as torne imunes aos mesmos desafios enfrentados por toda a comunidade de software ao compartilhar código. À medida que uma empresa cresce com o passar do tempo, a entropia se estabelece. Diferentes grupos na mesma empresa utilizam suas próprias versões particulares de bibliotecas “padrão” da empresa. Alguns grupos podem ir tão longe, a ponto de ignorar completamente essas bibliotecas e escrever suas próprias a partir do zero.

Com frequência, o problema não são as bibliotecas em si, mas a dificuldade de compartilhá-las com outras equipes e manter essas equipes notificadas das alterações. Parece familiar?

Origens dos pacotes

Até agora, abordei como instalar pacotes, mas não respondi à pergunta óbvia: Onde se encontram esses pacotes? Eles estão localizados na galeria oficial de pacotes do NuGet, em nuget.org. Essa galeria expõe um feed OData: packages.nuget.org/v1/FeedService.svc.

O formato OData permite que o cliente do NuGet gere consultas ad hoc para pesquisar a origem do pacote no cliente, mas execute essas consultas no servidor.

Para adicionar mais origens de pacotes ao NuGet, navegue para a opção de menu Tools | Library Package Manager | Package Manager Settings e clique no nó Package Sources, como se vê na Figura 6.

Figura 6 Configurações do Package Manager

A origem de pacote padrão é um ponto de extremidade OData na Web, mas a captura de tela de exemplo também mostra uma pasta local como uma origem de pacote. O NuGet trata as pastas (locais ou em um compartilhamento de rede) como uma origem de pacote e lista cada pacote da pasta no painel Online. Isso torna o compartilhamento de código com outras pessoas tão fácil quanto colocá-lo em uma pasta, além de ser útil quando você testa pacotes que você mesmo criou.

Hospedando o seu próprio servidor do NuGet

Além de hospedar pacotes em um compartilhamento de rede, você também pode configurar um site como uma origem de pacote e usá-lo para compartilhar pacotes com outras pessoas na sua organização.

Assim como em muitas tarefas, existe um pacote que fornece ajuda aqui. Primeiro, crie um aplicativo Web ASP.NET vazio no Visual Studio (objetivando o ASP.NET 4). Use o NuGet para instalar o pacote NuGet.Server. Esse pacote adiciona um simples ponto de extremidade OData ao aplicativo Web vazio.

Em seguida, adicione arquivos de pacote à pasta de pacotes do aplicativo Web para publicá-los e implante o site. Para obter mais detalhes sobre como fazer essa configuração, consulte o site de documentação do NuGet, bit.ly/jirmLO.

Para aqueles que desejam implantar uma experiência completa de galeria como o nuget.org, o código de galeria do NuGet também está disponível como um projeto de software livre, por meio do projeto nugetgallery.codeplex.com.

Hospedar um servidor do NuGet ou uma implementação de galeria particular é uma maneira fácil de compartilhar código proprietário em uma empresa, sem precisar publicá-lo para o público.

Criando um pacote

O NuGet não seria útil sem pacotes para instalar em primeiro lugar. Quanto mais pacotes úteis estiverem disponíveis no NuGet, mais valioso o NuGet se tornará para os desenvolvedores. É por isso que a equipe do NuGet faz todo o possível para simplificar e facilitar ao máximo a criação de pacotes. Embora seja fácil criar um pacote, a equipe do NuGet continua investindo em recursos para simplificá-la ainda mais. Eles desenvolveram várias ferramentas para criar pacotes do NuGet. Por exemplo, o Package Explorer é um aplicativo ClickOnce escrito por um desenvolvedor da equipe do NuGet, que fornece uma maneira visual de criar ou examinar um pacote. Ele está disponível em npe.codeplex.com.

NuGet.exe

Como a maioria dos autores de pacotes deseja integrar a criação do pacote aos seus processos de criação, vejamos outra abordagem que utiliza o utilitário de linha de comando do NuGet. Você precisará baixar o utilitário apenas uma vez em bit.ly/gmw54b. Depois de baixar o NuGet.exe, coloque-o em uma pasta que seja adicionada à variável de ambiente PATH. Eu tenho uma pasta chamada “utils” para utilitários como esse.

O motivo de eu dizer que você só precisa baixar o NuGet.exe uma vez (uma vez por computador) é que ele é um executável autoatualizável. Basta executar o seguinte comando para que o NuGet verifique online e se atualize para a versão mais recente, se existir uma mais nova disponível:

nuget update –self

A ferramenta da linha de comando pode consultar o feed online como o Package Manager Console. Por exemplo, para procurar todos os pacotes com “MVC”, use o seguinte comando:

nuget list Mvc

O NuGet.exe pode até baixar um pacote e as dependências, e desempacotá-los, mas não pode modificar um projeto para que referencie os assemblies do pacote baixado ou execute quaisquer scripts do Windows PowerShell incluídos em um pacote.

Criando um pacote em um projeto

Os pacotes contêm um único assembly 90% do tempo (uma estatística que eu fiz). Esta seção aborda um fluxo de trabalho simples para criar esses pacotes usando o NuGet.exe em um arquivo de projeto (como um arquivo .csproj ou .vbproj).

Para obter detalhes sobre a criação de pacotes mais complexos, como um único pacote direcionado a diferentes versões do .NET Framework, consulte o site de documentação do NuGet em docs.nuget.org.

As etapas básicas para criar um pacote são:

1. Criar um projeto de biblioteca de classes.
2. Gerar um manifesto NuSpec no projeto.
3. Atualizar os metadados de assembly do projeto.
4. Usar o NuGet.exe para criar o pacote.

Criar um projeto de biblioteca de classes Para compartilhar um assembly, inicie com um projeto de biblioteca de classes. O NuGet pode empacotar vários tipos de projetos, mas o caso mais comum ao compartilhar código é usar uma biblioteca de classes. Depois que você criar o pacote, abra o arquivo AssemblyInfo.cs para atualizar os metadados do assembly.

Criar um manifesto NuSpec O arquivo NuSpec é um manifesto de pacote com metadados importantes sobre o pacote, como autor, descrição e dependências do pacote. O formato do NuSpec é simples de ser criado à mão, mas convém deixar que o comando spec gere o arquivo para você. Execute o comando no mesmo diretório do arquivo de projeto:

nuget spec

Neste caso em particular, como o comando spec gerou o NuSpec a partir de um arquivo de projeto, ele contém espaços reservados para alguns metadados, como mostra a Figura 7.

Figura 7 O arquivo NuSpec gerado

<?xml version="1.0"?>
<package xmlns=
  "https://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>$id$</id>
    <version>$version$</version>
    <title>$title$</title>
    <authors>$author$</authors>
    <owners>$author$</owners>
    <licenseUrl>http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE</licenseUrl>
    <projectUrl>http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE</projectUrl>
    <iconUrl>http://ICON_URL_HERE_OR_DELETE_THIS_LINE</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>$description$</description>
    <copyright>Copyright 2011</copyright>
    <tags>Tag1 Tag2</tags>
  </metadata>
</package>

Não edite os campos com os espaços reservados, mas preencha com os valores corretos para os outros campos, como licenseUrl, projectUrl, iconUrl e tags.

Atualizar os metadados de assembly do projeto Cada assembly possui seus metadados relacionados. O NuGet pode ler esses metadados do assembly e mesclá-los no manifesto NuSpec quando ele criar um pacote, o que garante que essas informações nunca fiquem fora de sincronização entre o pacote e o assembly.

Como mencionei anteriormente, essas informações geralmente estão localizadas em um arquivo chamado AssemblyInfo.cs. A tabela da Figura 8 mostra os mapeamentos entre os metadados do assembly e os valores de espaço reservado do NuSpec.

Figura 8 Metadados do assembly mapeados para o NuSpec

Ao contrário dos outros campos, o campo $id$ não é extraído de um atributo do assembly, mas é definido com o nome do assembly.

Criar o pacote No mesmo diretório do arquivo de projeto e do arquivo NuSpec, execute o seguinte comando para criar um pacote:

nuget pack ProjectName.csproj

Se houver um arquivo de projeto no mesmo diretório, você poderá omitir o nome do arquivo de projeto ao executar o comando.

Se você ainda não tiver compilado o projeto, poderá usar o sinalizador Build para compilar o projeto primeiro, antes de empacotá-lo. Este comando compilará o projeto primeiro, antes de executar o comando pack:

nuget pack ProjectName.csproj -Build

Esse comando resulta em um arquivo chamado ProjectName.{version}.nupkg, onde {version} é o mesmo valor especificado no AssemblyVersionAttribute. Por exemplo, se a versão for 1.0.0, o pacote receberá o nome ProjectName.1.0.0.nupkg. É possível usar o Package Explorer para examinar o pacote depois do fato, para garantir que ele tenha sido criado corretamente.

Como cortesia para os desenvolvedores que irão instalar o seu pacote, considere o uso do sinalizador Symbols para criar um pacote com símbolos de depurador:

nuget pack ProjectName.csproj -Build -Symbols

Esse comando cria um pacote de símbolos além do pacote principal. Esse procedimento permite que outras pessoas instalem o seu pacote para entrar no código do pacote quando depurarem seus aplicativos.

Publicando um pacote

Depois de criar um pacote, você provavelmente vai querer compartilhá-lo com o mundo. O NuGet.exe possui um comando de publicação exatamente para essa finalidade. Antes de publicar, você precisará criar uma conta em nuget.org.

Quando estiver registrado para uma conta, clique no link da sua conta para ver a sua chave de acesso. Essa chave é importante, pois ela identifica o comando nuget.exe para a galeria e é uma senha irrevogável.

Quando tiver a sua chave, armazene-a em um local seguro usando o seguinte comando:

nuget setApiKey b688a925-0956-40a0-8327-ff2251cf5f9a

Isso feito, use o comando push para publicar o pacote na galeria:

nuget push ProjectName.1.0.0.nupkg

O comando valida a sua chave de API com a galeria, antes de carregar o pacote. Se você criou um pacote de símbolos, conforme discutimos anteriormente, especifique o sinalizador Symbols quando enviar por push o seu pacote:

nuget push ProjectName.1.0.0.nupkg -Symbols

Especifique o nome do pacote principal e não o nome do pacote de símbolos. O comando localiza o pacote de símbolos apropriado por convenção. O comando envia por push o pacote principal para a galeria do NuGet e o pacote de símbolos para o repositório symbolsource.org do parceiro.

O que vem a seguir?

Neste artigo, demonstrei como o NuGet efetua pull em bibliotecas úteis da galeria do NuGet para dar início ao desenvolvimento de novo projeto. Nas empresas, o NuGet é útil para compartilhar código entre vários desenvolvedores de uma organização.

Porém, há uma percepção errada persistente sobre o NuGet que eu preciso mencionar: que o NuGet é somente para desenvolvedores da Web. Essa percepção errada provavelmente se deve à sua inclusão com o ASP.NET MVC versão 3, mas isso não é verdade. O NuGet não é só para desenvolvedores da Web, é para todos os desenvolvedores. O NuGet dá suporte para o Windows Phone, o Silverlight e o Windows Presentation Foundation, entre outros tipos de projeto, e dará suporte para novos tipos de projeto no futuro.

O NuGet é um projeto de software livre orientado à comunidade, licenciado sob a licença do Apache 2. O projeto pertence à Outercurve Foundation, mas é incorporado em produtos da Microsoft e conta com vários desenvolvedores e principais colaboradores da Microsoft.

Para ajudar no desenvolvimento do NuGet, visite o site nuget.codeplex.com para saber como participar e, talvez, até contribuir com o NuGet.

Este artigo apenas aborda superficialmente as possibilidades do NuGet. Para saber mais, visite o site de documentação do NuGet em docs.nuget.org (a equipe trabalha duro para manter o site e aceita contribuições para essa documentação). A equipe é ativa no fórum de discussões CodePlex do projeto NuGet e suas dúvidas serão bem-vindas.    

Phil Haack trabalha na Microsoft como gerente de programas sênior na equipe do ASP.NET, com o objetivo de criar excelentes produtos para os desenvolvedores. Embora investigue muitas áreas do ASP.NET, seus principais projetos são o ASP.NET MVC e o NuGet Package Manager, ambos lançados sob uma licença OSS. Nas horas livres, ele escreve sobre software em seu blog, haacked.com, e trabalha no mecanismo do blog de software livre Subtext.

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: David Fowler