Notas sobre a versão do NuGet 2.7
Notas sobre a versão do NuGet 2.6.1 para WebMatrix | Notas sobre a versão do NuGet 2.7.1
O NuGet 2.7 foi lançado em 22 de agosto de 2013.
Gostaríamos de agradecer aos seguintes colaboradores externos por suas contribuições significativas para o NuGet 2.7:
[Mike Roth](http://www.codeplex.com/site/users/view/mxrss)
(@mxrss)- Mostrar url de licença ao listar pacotes e detalhamento é detalhado.
[Adam Ralph](http://www.codeplex.com/site/users/view/adamralph)
(@adamralph)[#1956](http://nuget.codeplex.com/workitem/1956)
- Adicionar o atributo developmentDependency apackages.config
e usar no comando pack para incluir somente pacotes de runtime
[Rafael Nicoletti](http://www.codeplex.com/site/users/view/tkrafael)
(@tkrafael)- Evite duplicar a chave Properties no comando do pacote nuget.exe.
[Ben Phegan](http://www.codeplex.com/site/users/view/benphegan)
(@BenPhegan)[#2610](http://nuget.codeplex.com/workitem/2610)
- Aumentar o tamanho do cache do computador para 200.
[Slava Trenogin](http://www.codeplex.com/site/users/view/derigel)
(@derigel)[#3217](http://nuget.codeplex.com/workitem/3217)
- Corrigir caixa de diálogo NuGet mostrando atualizações na guia errada- Corrigir Project.TargetFramework pode ser nulo no ProjectManager
[#3248](http://nuget.codeplex.com/workitem/3248)
- Corrigir SharedPackageRepository FindPackage/FindPackagesById falhará em packageId inexistente
[Kevin Boyle](http://www.codeplex.com/site/users/view/KevinBoyleRG)
(@kevfromireland)[#3234](http://nuget.codeplex.com/workitem/3234)
- Habilitar suporte ao projeto Nomad
[Corin Blaikie](http://www.codeplex.com/site/users/view/corinblaikie)
(@corinblaikie)[#3252](http://nuget.codeplex.com/workitem/3252)
- Corrigir o comando push falha com o código de saída 0 quando o arquivo não existe.
[Martin Veselý](http://www.codeplex.com/site/users/view/veselkamartin)
[#3226](http://nuget.codeplex.com/workitem/3226)
- Corrigir o bug com o comando Add-BindingRedirect quando um projeto faz referência a um projeto de banco de dados.
[Miroslav Bajtos](http://www.codeplex.com/site/users/view/miroslavbajtos)
(@bajtos)[#2891](http://nuget.codeplex.com/workitem/2891)
- Corrigir o bug de nuget.pack analisando curinga no atributo 'exclude' incorretamente.
[Justin Dearing](http://www.codeplex.com/site/users/view/zippy1981)
(@zippy1981)[#3307](http://nuget.codeplex.com/workitem/3307)
- Corrigir bugNuGet.targets
não passa $(Platform) para nuget.exe ao restaurar pacotes.
[Brian Federici](http://www.codeplex.com/site/users/view/benerdin)
[#3294](http://nuget.codeplex.com/workitem/3294)
- Corrigir o bug no comando do pacote nuget.exe que permitiria adicionar arquivos com o mesmo nome, mas com caixa diferente, consequentemente causando exceção "Item já existe".
[Daniel Cazzulino](http://www.codeplex.com/site/users/view/dcazzulino)
(@kzu)[#2990](http://nuget.codeplex.com/workitem/2990)
- Adicionar propriedade Version à classe NetPortableProfile.
[David Simner](https://www.codeplex.com/site/users/view/DavidSimner)
[#3460](https://nuget.codeplex.com/workitem/3460)
- Corrigir o bug NullReferenceException se requireApiKey = true, mas o cabeçalho X-NUGET-APIKEY não estiver presente
[Michael Friis](https://www.codeplex.com/site/users/view/friism)
(@friism)[#3278](https://nuget.codeplex.com/workitem/3278)
- Corrigir o arquivo de destino NuGet.Build para que ele funcione corretamente no MonoDevelop
[Pranav Krishnamoorthy](https://www.codeplex.com/site/users/view/pranavkm)
(@pranav_km)- Melhore o desempenho do comando Restore aumentando a paralelização
O NuGet 2.7 introduz uma nova abordagem para a restauração de pacotes e também supera um grande obstáculo: o consentimento de restauração de pacotes agora está ativado por padrão! A combinação da nova abordagem e do consentimento implícito simplificará drasticamente os cenários de restauração de pacotes.
Com as versões 2.0, 2.1, 2.2, 2.5 e 2.6 do NuGet, os usuários precisavam permitir explicitamente que o NuGet baixasse pacotes ausentes durante a compilação. Se esse consentimento não tivesse sido explicitamente concedido, as soluções que haviam habilitado a restauração de pacotes falhariam ao compilar até que o usuário tivesse concedido consentimento.
A partir do NuGet 2.7, o consentimento de restauração de pacote é ATIVADO por padrão, permitindo que os usuários desativem explicitamente a restauração de pacotes, se desejarem, usando a caixa de seleção nas configurações do NuGet no Visual Studio. Essa alteração para consentimento implícito afeta o NuGet nos seguintes ambientes:
- Visual Studio 2013 Preview
- Visual Studio 2012
- Visual Studio 2010
- nuget.exe Utilitário de Linha de Comando
A partir do NuGet 2.7, o NuGet baixará automaticamente pacotes ausentes durante a compilação no Visual Studio, mesmo que a restauração do pacote não tenha sido explicitamente habilitada para a solução. Essa restauração automática de pacote acontece no Visual Studio quando você cria um projeto ou a solução, mas antes do MSBuild é chamado. Isso gera alguns benefícios significativos:
- Não é mais necessário usar o gesto "Ativar restauração de pacotes NuGet" em sua solução
- Os projetos não precisam ser modificados e o NuGet não fará alterações no seu projeto para garantir que a restauração do pacote esteja habilitada
- Todos os pacotes NuGet, incluindo aqueles que incluíam importações do MSBuild para arquivos de propriedades/destinos, serão restaurados antes que o MSBuild seja invocado, garantindo que essas propriedades/destinos sejam reconhecidas corretamente durante a compilação
Para usar a restauração automática de pacotes no Visual Studio, você só precisa executar uma (in)ação:
- Não faça check-in da pasta
packages
Há várias maneiras de omitir a pasta packages
do controle do código-fonte. Para obter mais informações, consulte o tópico Pacotes e controle do código-fonte.
Embora todos os usuários sejam implicitamente aceitos no consentimento de Restauração Automática de Pacotes, é possível facilmente optar por não participar por meio das configurações do Gerenciador de Pacotes no Visual Studio.
O NuGet 2.7 apresenta um novo recurso para o nuget.exe: nuget.exe restore
Esse novo comando Restore permite que você restaure facilmente todos os pacotes de uma solução com um único comando, aceitando um arquivo ou pasta de solução como argumento. Além disso, esse argumento está implícito quando há somente uma única solução na pasta atual. Isso significa que todos os seguintes funcionam a partir de uma pasta que contém um único arquivo de solução (MySolution.sln):
- nuget.exe restore MySolution.sln
- nuget.exe restore .
- nuget.exe restore
O comando Restaurar abrirá o arquivo de solução e localizará todos os projetos dentro da solução. A partir daí, ele encontrará os arquivos packages.config
para cada um dos projetos e restaurará todos os pacotes encontrados. Ele também restaura pacotes de nível de solução encontrados no arquivo .nuget\packages.config
. Mais informações sobre o novo comando Restore podem ser encontradas na Referência de linha de comando.
Estamos entusiasmados com essas alterações na Restauração de Pacotes, pois ela introduz um novo fluxo de trabalho. Se você quiser omitir seus pacotes do controle do código-fonte, você simplesmente não confirma a pasta packages
. Os usuários do Visual Studio que abrirem e compilarem a solução verão os pacotes restaurados automaticamente. Para compilações de linha de comando, basta invocar nuget.exe restore
antes de invocar msbuild
. Você não precisa mais se lembrar de usar o gesto "Ativar Restauração de Pacotes NuGet" em sua solução, e não precisaremos mais modificar seus projetos para alterar a compilação. E isso também gera uma experiência muito melhor para pacotes que incluem importações do MSBuild, especialmente para importações adicionadas por meio do recurso recente do NuGet para importar automaticamente arquivos de propriedades/destinos da pasta \build.
Além do trabalho que nós mesmos fizemos, também estamos trabalhando com alguns parceiros importantes para completar essa nova abordagem. Ainda não temos cronogramas concretos para nenhum deles, mas cada parceiro está tão animado quanto nós com a nova abordagem.
- Team Foundation Service - Eles estão trabalhando para integrar a chamada para
nuget.exe restore
nos cenários de compilação padrão. - Sites do Windows Azure - Eles estão trabalhando para permitir que você envie seu projeto para o Azure e chame
nuget.exe restore
antes que seu site seja criado. - TeamCity - Eles estão atualizando o plugin NuGet Installer para TeamCity 8.x
- AppHarbor - Eles estão trabalhando para permitir que você envie seu repositório para o AppHarbor e chamaram
nuget.exe restore
antes que sua solução fosse compilada.
Com cada um dos parceiros acima, eles usariam sua própria cópia do nuget.exe e você não precisaria carregar nuget.exe em sua solução.
Havia dois problemas conhecidos com a restauração .exe nuget com a versão 2.7 inicial, mas eles foram corrigidos em 6/9/2013 com uma atualização para o pacote NuGet.CommandLine. Esta atualização também está disponível no [NuGet 2.7 download page](https://nuget.codeplex.com/releases/view/107605)
do CodePlex. A execução nuget.exe update -self
será atualizada para a versão mais recente.
As correções foram:
[New package restore doesn't work on Mono when using SLN file](https://nuget.codeplex.com/workitem/3596)
[New package restore doesn't work with Wix projects](https://nuget.codeplex.com/workitem/3598)
Há também um problema conhecido com o novo fluxo de trabalho de restauração de pacote em que [Automatic Package Restore does not work for projects under a solution folder](https://nuget.codeplex.com/workitem/3625)
. Esse problema foi corrigido no NuGet 2.7.1.
Muitas vezes, depois de redirecionar ou atualizar seu projeto, você descobre que alguns pacotes NuGet não estão funcionando corretamente. Infelizmente, não há indicação disso e, em seguida, não há orientação sobre como lidar com isso. Com o NuGet 2.7, agora usamos alguns eventos do Visual Studio para reconhecer quando você redirecionou ou atualizou seu projeto de uma maneira que afeta seus pacotes NuGet instalados.
Se detectarmos que algum dos seus pacotes foi afetado pelo redirecionamento ou atualização, produziremos erros de compilação imediatos para informá-lo. Além do erro de compilação imediato, também persistimos um sinalizador requireReinstallation="true"
no arquivo packages.config
para todos os pacotes que foram afetados pelo redirecionamento, e cada compilação subsequente no Visual Studio gerará avisos de compilação para esses pacotes.
Embora o NuGet não possa executar uma ação automática para reinstalar pacotes afetados, esperamos que essa indicação e aviso ajudem você a descobrir quando você precisa reinstalar pacotes. Também estamos trabalhando na documentação de orientação de reinstalação de pacotes para a qual essas mensagens de erro direcionam você.
Muitas empresas estão usando o NuGet internamente, mas têm tido dificuldade em orientar seus desenvolvedores a usar fontes de pacotes internos em vez de nuget.org. O NuGet 2.7 introduz um recurso Padrões de Configuração que permite que os padrões em todo o computador sejam especificados para:
- Fontes de pacote habilitadas
- Fontes de pacotes registradas, mas desabilitadas
- A origem padrão do nuget.exe push
Cada um deles agora pode ser configurado dentro de um arquivo localizado em %ProgramData%\NuGet\NuGetDefaults.Config
. Se esse arquivo de configuração especificar fontes de pacote, o código-fonte de pacote nuget.org padrão não será registrado automaticamente, e os NuGetDefaults.Config
de origem serão registrados.
Embora não seja necessário usar esse recurso, esperamos que as empresas implantem arquivos NuGetDefaults.Config
usando a Política de Grupo.
Observe que esse recurso nunca fará com que uma fonte de pacote seja removida das configurações do NuGet de um desenvolvedor. Isso significa que, se o desenvolvedor já tiver usado o NuGet e, portanto, a origem do pacote no nuget.org está registrada, ele não será removido após a criação de um arquivo NuGetDefaults.Config
.
Consulte Padrões de configuração do NuGet para obter mais informações sobre esse recurso.
O NuGet sempre registrou uma fonte de pacote padrão chamada "fonte oficial do pacote NuGet" que aponta para nuget.org. Esse nome era detalhado e também não especificava para onde estava realmente apontando. Para resolver esses dois problemas, renomeamos essa fonte de pacote para simplesmente "nuget.org" na interface do usuário. A URL do código-fonte do pacote também foi alterada para incluir o prefixo "www.". Depois de usar o NuGet 2.7, sua "fonte oficial do pacote NuGet" existente será atualizada automaticamente para "nuget.org" como nome e "https://www.nuget.org/api/v2/" como URL.
Fizemos algumas melhorias de desempenho na versão 2.7, o que produzirá menor volume de memória, menos uso de disco e instalação mais rápida de pacotes. Também fizemos consultas mais inteligentes a feeds baseados em OData, o que reduzirá a carga útil geral.
Adicionamos algumas novas APIs aos nossos serviços de extensibilidade para preencher a lacuna de recursos ausentes em versões anteriores.
// Checks if a NuGet package with the specified Id and version is installed in the specified project.
bool IsPackageInstalledEx(Project project, string id, string versionString);
// Get the list of NuGet packages installed in the specified project.
IEnumerable<IVsPackageMetadata> GetInstalledPackages(Project project);
// Installs one or more packages that exist on disk in a folder defined in the registry.
void InstallPackagesFromRegistryRepository(string keyName, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);
// Installs one or more packages that are embedded in a Visual Studio Extension Package.
void InstallPackagesFromVSExtensionRepository(string extensionId, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);
Esse recurso foi contribuído por Adam Ralph e permite que os autores de pacotes declarem dependências que foram usadas somente no momento do desenvolvimento e não exigem dependências de pacote. Ao adicionar um atributo developmentDependency="true"
a um pacote no packages.config
, o nuget.exe pack
não incluirá mais esse pacote como uma dependência.
O novo modelo de restauração de pacotes na versão 2.7 é implementado por um novo VSPackage que é diferente do NuGet VSPackage principal. Devido a um problema técnico, esse novo VSPackage não funciona corretamente no SKU do Visual Studio 2010 Express para telefone Windows, pois compartilhamos a mesma base de código com outros SKUs do Visual Studio com suporte. Portanto, a partir do NuGet 2.7, estamos descartando o suporte para o Visual Studio 2010 Express para telefone Windows da extensão publicada. O suporte para o Visual Studio 2010 Express para Web ainda está incluído na extensão primária publicada na Galeria de Extensões do Visual Studio.
Como não temos certeza de quantos desenvolvedores ainda estão usando o NuGet nessa versão/edição do Visual Studio, estamos publicando uma extensão separada do Visual Studio especificamente para esses usuários e publicando-a no CodePlex (em vez da Galeria de Extensões do Visual Studio). Não planejamos continuar a manter essa extensão, mas se isso afetar você, avise-nos registrando um problema no CodePlex.
Para baixar o Gerenciador de Pacotes NuGet (para Visual Studio 2010 Express para telefone Windows), visite a [NuGet 2.7 Downloads](https://nuget.codeplex.com/releases/view/107605)
página.
Além desses recursos, essa versão do NuGet também inclui muitas outras correções de bugs. Foram 97 problemas totais resolvidos na versão. Para obter uma lista completa dos itens de trabalho corrigidos no NuGet 2.7, consulte o [NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.7&status=all)
.