Notas sobre a versão do NuGet 2.8

Notas sobre a versão do NuGet 2.7.2 | Notas sobre a versão do Nuget 2.8.1

O NuGet 2.8 foi lançado em 29 de janeiro de 2014.

Confirmações

1. [Llewellyn Pritchard](https://www.codeplex.com/site/users/view/leppie) (@leppie)
   • [#3466](https://nuget.codeplex.com/workitem/3466) - Ao embalar pacotes, verificar o ID dos pacotes de dependência.
2. [Maarten Balliauw](https://www.codeplex.com/site/users/view/maartenba) (@maartenballiauw)
   • [#2379](https://nuget.codeplex.com/workitem/2379) - Remova o sufixo $metadata ao persistir com credenciais de feed.
3. [Filip De Vos](https://www.codeplex.com/site/users/view/FilipDeVos) (@foxtricks)
   • [#3538](http://nuget.codeplex.com/workitem/3538) - Suporte para especificar arquivo de projeto para o comando nuget.exe update.
4. [Juan Gonzalez](https://www.codeplex.com/site/users/view/jjgonzalez)
   • [#3536](http://nuget.codeplex.com/workitem/3536) - Tokens de substituição não passados com -IncludeReferencedProjects.
5. [David Poole](https://www.codeplex.com/site/users/view/Sarkie) (@Sarkie_Dave)
   • [#3677](http://nuget.codeplex.com/workitem/3677) - Corrija nuget.push jogando OutOfMemoryException ao transmitir pacote grande.
6. [Wouter Ouwens](https://www.codeplex.com/site/users/view/Despotes)
   • [#3666](http://nuget.codeplex.com/workitem/3666) - Corrija o caminho de destino incorreto quando o projeto faz referência a outro projeto CLI/C++.
7. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
   • [#3639](https://nuget.codeplex.com/workitem/3639) - Permitir que pacotes sejam instalados como dependências de desenvolvimento por padrão
8. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
   • [#3717](https://nuget.codeplex.com/workitem/3717) - Remover atualizações implícitas para a versão mais recente do patch
9. [Gregory Vandenbrouck](https://www.codeplex.com/site/users/view/vdbg)
   • Várias correções de bugs e melhorias para o NuGet.Server, o comando nuget.exe mirror e outros.
   • Este trabalho foi feito ao longo de vários meses, com Gregory trabalhando conosco no momento certo para se integrar ao master para 2.8.

Resolução de patches para dependências

Ao resolver dependências de pacote, o NuGet tem historicamente implementado uma estratégia de selecionar a versão mais baixa dos pacotes principal e secundário que satisfaz as dependências no pacote. Ao contrário da versão principal e secundária, no entanto, a versão do patch sempre foi resolvida para a versão mais alta. Embora o comportamento tenha sido bem intencionado, criou uma falta de determinismo para instalar pacotes com dependências. Considere o seguinte exemplo:

PackageA@1.0.0 -[ >=1.0.0 ]-> PackageB@1.0.0

Developer1 installs PackageA@1.0.0: installed PackageA@1.0.0 and PackageB@1.0.0

PackageB@1.0.1 is published

Developer2 installs PackageA@1.0.0: installed PackageA@1.0.0 and PackageB@1.0.1

Neste exemplo, mesmo que Developer1 e Developer2 tenham instalado o PackageA@1.0.0, cada um acabou com uma versão diferente do PackageB. O NuGet 2.8 altera esse comportamento padrão de forma que o comportamento de resolução de dependência para versões de patches seja consistente com o comportamento para versões principais e secundárias. No exemplo acima, então, o PackageB@1.0.0 seria instalado como resultado da instalação do PackageA@1.0.0, independentemente da versão mais recente do patch.

-DependencyVersion Switch

Embora o NuGet 2.8 altere o comportamento padrão para resolver dependências, ele também adiciona um controle mais preciso sobre o processo de resolução de dependências por meio da comutação -DependencyVersion no console do gerenciador de pacotes. A comutação permite resolver dependências para a versão mais baixa possível (comportamento padrão), a versão mais alta possível ou a versão secundária ou de patch mais alta. Essa comutação só funciona para install-package no comando powershell.

Atributo DependencyVersion

Além da comutação -DependencyVersion detalhada acima, o NuGet também permitiu a capacidade de definir um novo atributo no arquivo Nuget.Config, definindo qual é o valor padrão, se a comutação -DependencyVersion não for especificada em uma invocação de install-package. Esse valor também será respeitado pela caixa de diálogo Gerenciador de Pacotes NuGet para quaisquer operações de install-package. Para definir esse valor, adicione o atributo abaixo ao arquivo Nuget.Config:

<config>
    <add key="dependencyversion" value="Highest" />
</config>

Visualizar operações NuGet com -whatif

Alguns pacotes NuGet podem ter gráficos de dependência profunda e, assim, pode ser útil durante uma operação de instalação, desinstalação ou atualização para ver primeiro o que acontecerá. O NuGet 2.8 adiciona a comutação padrão do PowerShell -whatif aos comandos install-package, uninstall-package e update-package para permitir a visualização de todo o fechamento de pacotes aos quais o comando será aplicado. Por exemplo, a execução de install-package Microsoft.AspNet.WebApi -whatif em um aplicativo Web ASP.NET vazio produz o seguinte.

PM> install-package Microsoft.AspNet.WebApi -whatif
Attempting to resolve dependency 'Microsoft.AspNet.WebApi.WebHost (≥ 5.0.0)'.
Attempting to resolve dependency 'Microsoft.AspNet.WebApi.Core (≥ 5.0.0)'.
Attempting to resolve dependency 'Microsoft.AspNet.WebApi.Client (≥ 5.0.0)'.
Attempting to resolve dependency 'Newtonsoft.Json (≥ 4.5.11)'.
Install Newtonsoft.Json 4.5.11
Install Microsoft.AspNet.WebApi.Client 5.0.0
Install Microsoft.AspNet.WebApi.Core 5.0.0
Install Microsoft.AspNet.WebApi.WebHost 5.0.0
Install Microsoft.AspNet.WebApi 5.0.0

Fazer downgrade de pacote

Não é incomum instalar uma versão de pré-lançamento de um pacote para investigar novos recursos e, em seguida, decidir reverter para a última versão estável. Antes do NuGet 2.8, esse era um processo de várias etapas de desinstalação do pacote de pré-lançamento e suas dependências e, em seguida, a instalação da versão anterior. Com o NuGet 2.8, no entanto, o pacote de atualização agora reverterá todo o fechamento do pacote (por exemplo, a árvore de dependências do pacote) para a versão anterior.

Dependências de desenvolvimento

Muitos tipos diferentes de recursos podem ser entregues como pacotes NuGet, inclusive ferramentas que são usadas para otimizar o processo de desenvolvimento. Esses componentes, embora possam ser instrumentais no desenvolvimento de um novo pacote, não devem ser considerados uma dependência do novo pacote quando ele for publicado posteriormente. O NuGet 2.8 permite que um pacote se identifique no arquivo .nuspec como developmentDependency. Quando instalados, esses metadados também serão adicionados ao arquivo packages.config do projeto no qual o pacote foi instalado. Quando esse arquivo packages.config for analisado posteriormente para dependências do NuGet durante nuget.exe pack, ele excluirá as dependências marcadas como dependências de desenvolvimento.

Arquivos packages.config individuais para diferentes plataformas

Ao desenvolver aplicativos para várias plataformas de destino, é comum ter arquivos de projeto diferentes para cada um dos respectivos ambientes de compilação. Também é comum consumir diferentes pacotes NuGet em diferentes arquivos de projeto, pois os pacotes têm níveis variados de suporte para diferentes plataformas. O NuGet 2.8 fornece suporte aprimorado para esse cenário, criando arquivos packages.config diferentes para diferentes arquivos de projeto específicos da plataforma.

Fallback para cache local

Embora os pacotes NuGet sejam normalmente consumidos de uma galeria remota, como a galeria NuGet, usando uma conexão de rede, há muitos cenários em que o cliente não está conectado. Sem uma conexão de rede, o cliente NuGet não conseguiu instalar pacotes com êxito, mesmo quando esses pacotes já estavam na máquina do cliente no cache local do NuGet. O NuGet 2.8 adiciona fallback automático de cache ao console do gerenciador de pacotes. Por exemplo, ao desconectar o adaptador de rede e instalar o jQuery, o console mostra o seguinte:

PM> Install-Package jquery
The source at nuget.org [https://www.nuget.org/api/v2/] is unreachable. Falling back to NuGet Local Cache at C:\Users\me\AppData\Local\NuGet\Cache
Installing 'jQuery 2.0.3'.
Successfully installed 'jQuery 2.0.3'.
Adding 'jQuery 2.0.3' to WebApplication18.
Successfully added 'jQuery 2.0.3' to WebApplication18.

O recurso de fallback de cache não requer nenhum argumento de comando específico. Além disso, o fallback de cache atualmente funciona apenas no console do gerenciador de pacotes: o comportamento não funciona atualmente na caixa de diálogo do gerenciador de pacotes.

Atualizações do cliente NuGet do WebMatrix

Junto com o NuGet 2.8, a extensão do NuGet para WebMatrix também foi atualizada para incluir muitos dos principais recursos fornecidos com o NuGet 2.5. Os novos recursos incluem aqueles como “Atualizar tudo”, “Versão mínima do NuGet” e permitir a substituição de arquivos de conteúdo.

Para atualizar sua extensão do Gerenciador de pacotes NuGet no WebMatrix 3:

1. Abrir WebMatrix 3
2. Clique no ícone de extensões na faixa
3. Selecione a guia Atualizações
4. Clique para atualizar o Gerenciador de Pacotes NuGet para a versão 2.5.0
5. Feche e reinicie o WebMatrix 3

Esta é a primeira versão da extensão do Gerenciador de pacotes do NuGet para WebMatrix. O código foi recentemente contribuído pela Microsoft para o projeto NuGet de código aberto. Anteriormente, a integração do NuGet era incorporada ao WebMatrix e não podia ser atualizada fora da faixa do WebMatrix. Agora temos a capacidade de atualizá-lo ainda mais junto com o resto das ferramentas do cliente do NuGet.

Correções de bugs

Uma das principais correções de bugs feitas foi a melhoria de desempenho no comando update-package -reinstall.

Além desses recursos e da correção de desempenho mencionada, esta versão do NuGet também inclui muitas outras correções de bugs. Foram 181 problemas totais resolvidos na versão. Para obter uma lista completa dos itens de trabalho corrigidos no NuGet 2.8, consulte o [NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.8&status=all).