Notas sobre a versão do NuGet 2.1
Notas sobre a versão do NuGet 2.0 | Notas sobre a 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 subir recursivamente a estrutura de pastas procurando arquivos NuGet.Config e, em seguida, criando 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 para um projeto individual pode parecer com o seguinte:
C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1
Além disso, se a restauração do pacote 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, enquanto não o disponibiliza 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 o código fonte foi adicionado executando o comando “nuget.exe sources” de qualquer pasta abaixo de c:\myteam, conforme mostrado abaixo:
Os arquivos NuGet.Config são pesquisados na seguinte ordem:
.nuget\Nuget.Config- Caminhada recursiva da pasta do projeto para a raiz
- Global
Nuget.Config(%appdata%\NuGet\Nuget.Config)
As configurações são aplicadas na ordem inversa, o que significa que, com base na ordem acima, o Nuget.Config global seria aplicado primeiro, seguido pelos arquivos Nuget.Config descobertos da raiz para a pasta do projeto, seguido por .nuget\Nuget.Config. Isso é particularmente importante se você estiver usando o elemento <clear/> para remover um conjunto de itens da configuração.
Especificar o local da pasta de pacotes
No passado, o NuGet gerenciava os pacotes de uma solução a partir de uma pasta de pacotes conhecida encontrada 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 lugares diferentes no sistema de arquivos.
O NuGet 2.1 fornece controle mais granular sobre o local da pasta de pacotes por meio do elemento repositoryPath no arquivo NuGet.Config. 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 a c:\myteam\Nuget.Config.
<configuration>
<config>
<add key="repositoryPath" value="C:\myteam\teampackages" />
</config>
...
</configuration>
Nesse 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, será necessário excluí-la antes que o NuGet coloque os pacotes no novo local.
Suporte para bibliotecas portáveis
As bibliotecas portáveis são um recurso introduzido pela primeira vez com o .NET 4 que permite criar montagens que podem funcionar sem modificações em diferentes plataformas da Microsoft, de versões do .NET Framework ao Silverlight, ao Windows Phone e até mesmo ao Xbox 360 (embora, no momento, o NuGet não ofereça suporte ao destino da biblioteca portável 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áveis, 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ável.
Depois que a biblioteca é criada e o comando nuget.exe pack MyPortableProject.csproj é executado, a nova estrutura de pastas de pacotes de bibliotecas portáveis pode ser vista examinando o conteúdo do pacote NuGet gerado.
Como você pode ver, a convenção de nome de pasta de biblioteca portável segue o padrão “portable-{framework 1}+{framework n}”, onde os identificadores de estrutura seguem as convenções de nome e de versão da estrutura existentes. Uma exceção às convenções de nome e de versão é encontrada no identificador de estrutura usado para o Windows Phone. Esse moniker deve usar o nome de estrutura “wp” (wp7, wp71 ou wp8). Por exemplo, usar “silverlight-wp7” 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 de 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 alvos "mais específicos" terão precedência sobre alvos "menos específicos". Isso significa que os monikers direcionados a uma plataforma específica sempre serão preferidos em relação aos portáteis, se os dois forem compatíveis com um projeto. Além disso, se vários destinos portáveis 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áveis, o NuGet 2.1 fornece novos monikers de estrutura para projetos da Windows 8 Store e do Windows Phone 8, bem como alguns novos monikers gerais para projetos da Windows Store e do Windows Phone que serão mais fáceis de gerenciar em versões futuras das respectivas plataformas.
Para aplicativos da Windows 8 Store, os identificadores se parecem com o seguinte:
| NuGet 2.0 e versões anteriores | NuGet 2.1 |
|---|---|
| winRT45, . NETCore45 | Windows, Windows8, win, win8 |
Para projetos do Windows Phone, os identificadores têm a seguinte aparência:
| SO do telefone | NuGet 2.0 e versões anteriores | NuGet 2.1 |
|---|---|---|
| Windows Phone 7 | silverlight3-wp | wp, wp7, WindowsPhone, WindowsPhone7 |
| Windows Phone 7.5 (Mango) | silverlight4-wp71 | wp71, WindowsPhone71 |
| Windows Phone 8 | (sem suporte) | wp8, WindowsPhone8 |
Em todas as alterações acima, os nomes de estrutura antigos continuarão a ser totalmente suportados pelo NuGet 2.1. No futuro, os novos nomes devem ser usados, pois serão mais estáveis em versões futuras das respectivas plataformas. Os novos nomes *não* serão suportados em versões do NuGet anteriores à 2.1, no entanto, então, planeje de quando fazer a troca.
Pesquisa aprimorada na caixa de diálogo Gerenciador de pacotes
Ao longo das últimas várias iterações, foram introduzidas mudanças na galeria NuGet que melhoraram muito 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 Gerenciador de pacotes do NuGet. Como exemplo, imagine que você queria localizar o pacote de cache do Windows Azure Preview. Uma consulta de pesquisa razoável para esse pacote pode ser "Cache do Azure". 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 a cada compilação. O comportamento desejado era forçar uma atualização independentemente disso. O NuGet 2.1 aborda isso com o sinalizador “reinstall”. Por exemplo, as versões anteriores do NuGet resultariam no seguinte ao tentar atualizar um pacote que não tivesse 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 é o de redirecionamento de estrutura. 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 às montagens corretas para todos os pacotes NuGet instalados no projeto.
Editar origens de pacotes no Visual Studio
Em versões anteriores do NuGet, a atualização de uma origem de pacote de dentro da caixa de diálogo de opções do Visual Studio exigia excluir e adicionar novamente a origem 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 bugs
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).