Notas de versão do NuGet 2.1

Notas de versão do NuGet 2.0 | Notas de versão do NuGet 2.2

O NuGet 2.1 foi lançado em 4 de outubro de 2012.

Nuget.Config hierárquico

O NuGet 2.1 oferece maior flexibilidade no controle das configurações do NuGet por meio de percorrer recursivamente a estrutura de pastas procurando NuGet.Config arquivos e, em seguida, construindo a configuração a partir do conjunto de todos os arquivos encontrados. Como exemplo, considere o cenário em que uma equipe tem um repositório de pacotes interno para compilações de CI de outras dependências internas. A estrutura de pastas de um projeto individual pode ter a seguinte aparência:

C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1

Além disso, se a restauração de pacotes estiver habilitada para a solução, a seguinte pasta também existirá:

C:\myteam\solution1\.nuget

Para ter o repositório de pacotes interno da equipe disponível para todos os projetos em que a equipe trabalha, sem disponibilizá-lo para todos os projetos na máquina, podemos criar um novo arquivo Nuget.Config e colocá-lo na pasta c:\myteam. Não há como especificar uma pasta de pacotes por projeto.

<configuration>
    <packageSources>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </activePackageSource>
</configuration>

Agora podemos ver que a fonte foi adicionada executando o comando 'nuget.exe sources' de qualquer pasta abaixo de c:\myteam, como mostrado abaixo:

NuGet.Config Os arquivos são pesquisados na seguinte ordem:

1. .nuget\Nuget.Config
2. Caminhada recursiva da pasta do projeto para a raiz
3. Global Nuget.Config (%appdata%\NuGet\Nuget.Config)

As configurações são aplicadas na ordem inversa. Isso significa que, com a ordem acima mencionada, o Nuget.Config global seria aplicado primeiro, seguido pelos ficheiros Nuget.Config descobertos, desde a raiz até à pasta do projeto, seguidos por .nuget\Nuget.Config. Isso é particularmente importante se você estiver usando o <clear/> elemento para remover um conjunto de itens da configuração.

Especificar o local da pasta 'pacotes'

No passado, o NuGet gerenciava os pacotes de uma solução a partir de uma pasta conhecida de 'pacotes' localizada abaixo da pasta raiz da solução. Para equipes de desenvolvimento que têm muitas soluções diferentes que têm pacotes NuGet instalados, isso pode resultar na instalação do mesmo pacote em muitos locais diferentes no sistema de arquivos.

O NuGet 2.1 fornece um controle mais granular sobre o local da pasta de pacotes por meio do repositoryPath elemento no NuGet.Config arquivo. Com base no exemplo anterior de suporte hierárquico a Nuget.Config, suponha que desejamos que todos os projetos em C:\myteam\ compartilhem a mesma pasta de pacotes. Para fazer isso, basta adicionar a seguinte entrada ao c:\myteam\Nuget.Config.

<configuration>
    <config>
    <add key="repositoryPath" value="C:\myteam\teampackages" />
    </config>
    ...
</configuration>

Neste exemplo, o arquivo compartilhado Nuget.Config especifica uma pasta de pacotes compartilhados para cada projeto criado abaixo de C:\myteam, independentemente da profundidade. Observe que, se você tiver uma pasta de pacotes existente abaixo da raiz da solução, precisará excluí-la antes que o NuGet coloque os pacotes no novo local.

Suporte para bibliotecas portáteis

As bibliotecas portáteis são um recurso introduzido pela primeira vez com o .NET 4 que permite criar assemblies que podem funcionar sem modificações em diferentes plataformas da Microsoft, desde versões do the.NET Framework até o Silverlight, o Windows Phone e até mesmo o Xbox 360 (embora, no momento, o NuGet não ofereça suporte ao destino da biblioteca portátil do Xbox). Ao estender as convenções de pacote para versões e perfis de estrutura, o NuGet 2.1 agora oferece suporte a bibliotecas portáteis, permitindo que você crie pacotes com pastas de destino lib de estrutura e perfil compostas.

Como exemplo, considere as seguintes plataformas de destino disponíveis da biblioteca de classes portátil.

Depois que a biblioteca é criada e o comando nuget.exe pack MyPortableProject.csproj é executado, a nova estrutura de pastas do pacote de biblioteca portátil pode ser vista examinando o conteúdo do pacote NuGet gerado.

Como você pode ver, a convenção de nome de pasta da biblioteca portátil segue o padrão 'portable-{framework 1}+{framework n}', onde os identificadores de estrutura seguem as convenções de nome e versão da estrutura existentes. Uma exceção às convenções de nome e versão é encontrada no identificador de estrutura usado para o Windows Phone. Este moniker deve usar o nome da estrutura 'wp' (wp7, wp71 ou wp8). Usar 'silverlight-wp7', por exemplo, resultará em um erro.

Ao instalar o pacote criado a partir dessa estrutura de pastas, o NuGet agora pode aplicar suas regras de estrutura e perfil a vários destinos, conforme especificado no nome da pasta. Por trás das regras de correspondência do NuGet está o princípio de que os alvos "mais específicos" terão precedência sobre os "menos específicos". Isso significa que os apelidos direcionados a uma plataforma específica sempre serão preferidos em relação aos portáteis se ambos forem compatíveis com um projeto. Além disso, se vários destinos portáteis forem compatíveis com um projeto, o NuGet preferirá aquele em que o conjunto de plataformas suportadas estiver "mais próximo" do projeto que faz referência ao pacote.

Visando projetos do Windows 8 e do Windows Phone 8

Além de adicionar suporte para direcionar projetos de bibliotecas portáteis, o NuGet 2.1 fornece novos monikers de estrutura para projetos da Windows 8 Store e do Windows Phone 8, bem como alguns novos apelidos gerais para projetos da Windows Store e do Windows Phone que serão mais fáceis de gerenciar em versões futuras das respetivas plataformas.

Para aplicativos da Windows 8 Store, os identificadores têm a seguinte aparência:

Pesquisa melhorada na caixa de diálogo do Gestor de Pacotes

Ao longo das últimas iterações, foram introduzidas alterações na galeria do NuGet que melhoraram consideravelmente a velocidade e a relevância das pesquisas de pacotes. No entanto, essas melhorias foram limitadas ao site nuget.org. O NuGet 2.1 disponibiliza a experiência de pesquisa aprimorada por meio da caixa de diálogo do Gerenciador de Pacotes NuGet. Como exemplo, imagine que você queria encontrar o pacote do Windows Azure Caching Preview. Uma consulta de pesquisa razoável para este pacote pode ser "Azure Cache". Em versões anteriores da caixa de diálogo do gerenciador de pacotes, o pacote desejado nem sequer seria listado na primeira página de resultados. No entanto, no NuGet 2.1, o pacote desejado agora aparece na parte superior dos resultados da pesquisa.

Forçar atualização do pacote

Antes do NuGet 2.1, o NuGet ignorava a atualização de um pacote quando não havia um número de versão alto. Isso introduziu atrito para determinados cenários – particularmente no caso de cenários de compilação ou CI em que a equipe não queria incrementar o número de versão do pacote com cada compilação. O comportamento desejado era forçar uma atualização independentemente disso. O NuGet 2.1 resolve isso com o sinalizador 'reinstalar'. Por exemplo, versões anteriores do NuGet resultariam no seguinte ao tentar atualizar um pacote que não tinha uma versão de pacote mais recente:

PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.

Com o sinalizador de reinstalação, o pacote será atualizado independentemente de haver uma versão mais recente.

PM> Update-Package Moq -Reinstall
Successfully removed 'Moq 4.0.10827' from MySolution.MyConsole.
Successfully uninstalled 'Moq 4.0.10827'.
Successfully installed 'Moq 4.0.10827'.
Successfully added 'Moq 4.0.10827' to MySolution.MyConsole.

Outro cenário em que o sinalizador de reinstalação se mostra benéfico é a reorientação da framework. Ao alterar a estrutura de destino de um projeto (por exemplo, do .NET 4 para o .NET 4.5), Update-Package -Reinstall pode atualizar referências aos assemblies corretos para todos os pacotes NuGet instalados no projeto.

Editar códigos-fonte de pacotes no Visual Studio

Em versões anteriores do NuGet, atualizar uma fonte de pacote de dentro da caixa de diálogo de opções do Visual Studio exigia excluir e adicionar novamente a fonte do pacote. O NuGet 2.1 melhora esse fluxo de trabalho oferecendo suporte à atualização como uma função de primeira classe da interface do usuário de configuração.

Correções de Erros

O NuGet 2.1 inclui muitas correções de bugs. Para obter uma lista completa dos itens de trabalho corrigidos no NuGet 2.0, consulte o [NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Fixed&type=All&priority=All&release=NuGet%202.1&assignedTo=All&component=All&sortField=LastUpdatedDate&sortDirection=Descending&page=0).