Partilhar via

Notas sobre a versão do NuGet 2.5

  • Artigo

Notas sobre a versão do NuGet 2.2.1 | Notas sobre a versão do Nuget 2.6

O NuGet 2.5 foi lançado em 25 de abril de 2013. Esse lançamento foi tão grande que nos sentimos motivados a pular as versões 2.3 e 2.4. Até o momento, este é o maior lançamento que tivemos para o NuGet, com mais de [160 work items](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.5&status=all) no lançamento.

Confirmações

Gostaríamos de agradecer aos seguintes colaboradores externos por suas contribuições significativas para o NuGet 2.5:

  1. [Daniel Plaisted](https://www.codeplex.com/site/users/view/dsplaisted) (@dsplaisted)
    • [#2847](https://nuget.codeplex.com/workitem/2847) - adição de MonoAndroid, MonoTouch e MonoMac à lista de identificadores de estrutura de destino conhecidos.
  2. [Andres G. Aragoneses](https://www.codeplex.com/site/users/view/knocte) (@knocte)
    • [#2865](https://nuget.codeplex.com/workitem/2865) - correção da ortografia de NuGet.targets para um sistema operacional que diferencia a maiúsculas e minúsculas
  3. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
    • Fazer com que a solução seja compilada no Mono.
  4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
    • Correção de falha nos testes de unidade no Mono.
  5. [Olivier Dagenais](https://www.codeplex.com/site/users/view/OliIsCool) (@OliIsCool)
    • [#2920](https://nuget.codeplex.com/workitem/2920) - o comando nuget.exe pack não propaga propriedades para o MSBuild
  6. [Miroslav Bajtos](https://www.codeplex.com/site/users/view/MiroslavBajtos) (@bajtos)
    • [#1511](https://nuget.codeplex.com/workitem/1511) - código de manipulação XML modificado para preservar a formatação.
  7. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • Adição de palavras reconhecidas ao dicionário personalizado para permitir que build.cmd tenha êxito.
  8. [Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
    • Correção de testes de unidade ao executar no VS.
  9. [Gareth Evans](https://www.codeplex.com/site/users/view/garethevans)
    • Interface extraída do PackageService
  10. [Maxime Brugidou](https://www.codeplex.com/site/users/view/brugidou) (@brugidou)
    • [#936](https://nuget.codeplex.com/workitem/936) - lidar com dependências do projeto ao empacotar
  11. [Xavier Decoster](https://www.codeplex.com/site/users/view/XavierDecoster) (@XavierDecoster)
    • [#2991](https://nuget.codeplex.com/workitem/2991), [#3164](https://nuget.codeplex.com/workitem/3164) - suporte a senha de texto não criptografado ao armazenar credenciais de origem do pacote em arquivos nuget.cofig
  12. [James Manning](http://www.codeplex.com/site/users/view/jmanning) (@manningj)
    • [#3190](http://nuget.codeplex.com/workitem/3190), [#3191](https://nuget.codeplex.com/workitem/3191) - correção de descrição da ajuda Get-Package

Também agradecemos aos seguintes indivíduos por encontrarem bugs no NuGet 2.5 Beta/RC que foram aprovados e corrigidos antes da versão final:

  1. [Tony Wall](https://www.codeplex.com/site/users/view/CodeChief) (@CodeChief)
    • [#3200](https://nuget.codeplex.com/workitem/3200) - MSTest danificado com as últimas compilações NuGet 2.4 e 2.5

Características em destaque na versão

Permitir que os usuários substituam arquivos de conteúdo que já existem

Um dos recursos mais solicitados de todos os tempos foi a capacidade de substituir arquivos de conteúdo que já existem no disco quando incluídos em um pacote NuGet. A partir do NuGet 2.5, esses conflitos são identificados e você é solicitado a substituir os arquivos, enquanto anteriormente esses arquivos eram sempre ignorados.

Overwrite content files

'nuget.exe update' e 'Install-Package' agora têm uma nova opção '-FileConflictAction' para definir um padrão para cenários de linha de comando.

Definir uma ação padrão quando um arquivo de um pacote já existir no projeto de destino. Definir como 'Substituir' para sempre substituir arquivos. Definir como 'Ignorar' para ignorar arquivos. Se não for especificado, ele solicitará cada arquivo conflitante.

Importação automática de destinos e arquivos props do MSBuild

Uma nova pasta convencional foi criada no nível superior do pacote NuGet. Como um par para \lib, \content e \tools, agora você pode incluir uma pasta \build em seu pacote. Nessa pasta, você pode colocar dois arquivos com nomes fixos {packageid}.targets ou {packageid}.props. Esses dois arquivos podem estar diretamente sob build ou sob pastas específicas da estrutura, assim como as outras pastas. A regra para escolher a pasta de estrutura mais adequada é exatamente a mesma que nessas pastas.

Quando o NuGet instala um pacote com arquivos \build, ele adiciona um elemento <Import> MSBuild no arquivo do projeto apontando para os arquivos .targets e .props. O arquivo .props é adicionado na parte superior, enquanto o arquivo .targets é adicionado à parte inferior.

Especificar referências diferentes por plataforma usando o elemento <References/>

Antes de 2.5, no arquivo .nuspec, o usuário só pode especificar os arquivos de referência, a serem adicionados para toda a estrutura. Agora com esse novo recurso na versão 2.5, o usuário pode criar o elemento <reference/> para cada uma das plataformas suportadas, por exemplo:

<references>
    <group targetFramework="net45">
        <reference file="a.dll" />
    </group>
    <group targetFramework="netcore45">
        <reference file="b.dll" />
    </group>
    <group>
        <reference file="c.dll" />
    </group>
</references>

Aqui está o fluxo de como o NuGet adiciona referências a projetos com base no arquivo .nuspec:

  1. Localize a pasta lib apropriada para a estrutura de destino e obtenha a lista de assemblies dessa pasta
  2. Localizar separadamente o grupo de referências apropriado para a estrutura de destino e obter a lista de assemblies desse grupo. O grupo de referência sem estrutura de destino especificada é o grupo de fallback.
  3. Encontrar a interseção das duas listas e usá-las como referências para adicionar

Esse novo recurso permitirá que os autores de pacotes usem o recurso Referências para aplicar subconjuntos de assemblies a diferentes estruturas quando, de outra forma, precisariam carregar assemblies duplicados em várias pastas lib.

Observação: atualmente você deve usar o pacote nuget.exe para usar esse recurso; O NuGet Package Explorer ainda não oferece suporte a ele.

Botão Atualizar tudo para permitir a atualização de todos os pacotes de uma só vez

Muitos de vocês conhecem o cmdlet do PowerShell "Update-Package" para atualizar todos os seus pacotes; agora há uma maneira fácil de fazer isso por meio da interface do usuário também.

Para experimentar esse recurso:

  1. Criar um novo aplicativo ASP.NET MVC
  2. Inicie a caixa de diálogo 'Gerenciar pacotes NuGet'
  3. Selecione 'Atualizações'
  4. Clique no botão 'Atualizar tudo'

Update All button in the dialog

Suporte aprimorado de referência de projeto para nuget.exe Pack

Agora, o comando nuget.exe pack processa projetos referenciados com as seguintes regras:

  1. Se o projeto referenciado tiver um arquivo .nuspec correspondente, por exemplo, houver um arquivo chamado proj1.nuspec na mesma pasta que proj1.csproj, então esse projeto será adicionado como uma dependência ao pacote, usando o id e a versão lidos do arquivo .nuspec.
  2. Caso contrário, os arquivos do projeto referenciado serão empacotados no pacote. Em seguida, os projetos referenciados por este projeto serão processados usando as mesmas regras recursivamente.
  3. Todas as DLLs, .pdb e arquivos .exe são adicionados.
  4. Todos os outros arquivos de conteúdo são adicionados.
  5. Todas as dependências são mescladas.

Isso permite que um projeto referenciado seja tratado como uma dependência se houver um arquivo .nuspec, caso contrário, ele se tornará parte do pacote.

Mais detalhes aqui: [http://nuget.codeplex.com/workitem/936](http://nuget.codeplex.com/workitem/936)

Adicionar uma propriedade 'Versão mínima do NuGet' aos pacotes

Um novo atributo de metadados chamado 'minClientVersion' agora pode indicar a versão mínima do cliente NuGet necessária para consumir um pacote.

Esse recurso ajuda o autor do pacote a especificar que um pacote funcionará somente após uma versão específica do NuGet. À medida que novos recursos .nuspec são adicionados após o NuGet 2.5, os pacotes poderão reivindicar uma versão mínima do NuGet.

<metadata minClientVersion="2.6">

Se o usuário tiver o NuGet 2.5 instalado e um pacote for identificado como exigindo 2.6, dicas visuais serão dadas ao usuário indicando que o pacote não será instalável. O usuário será orientado a atualizar sua versão do NuGet.

Isso melhorará a experiência existente em que os pacotes começam a ser instalados, mas depois falham, indicando que uma versão de esquema não reconhecida foi identificada.

As dependências não são mais atualizadas desnecessariamente durante a instalação do pacote

Antes do NuGet 2.5, quando era instalado um pacote que dependia de um pacote já instalado no projeto, a dependência era atualizada como parte da nova instalação, mesmo que a versão existente satisfizesse a dependência.

A partir do NuGet 2.5, se uma versão de dependência já estiver satisfeita, a dependência não será atualizada durante outras instalações de pacote.

O cenário:

  1. O repositório de código fonte contém o pacote B com as versões 1.0.0 e 1.0.2. Ele também contém o pacote A que tem uma dependência de B (>= 1.0.0).
  2. Suponha que o projeto atual já tenha o pacote B versão 1.0.0 instalado. Agora você deseja instalar o pacote A

No NuGet 2.2 e versões anteriores:

  • Ao instalar o pacote A, o NuGet atualizará automaticamente B para 1.0.2, mesmo que a versão 1.0.0 existente já satisfaça a restrição de versão de dependência, que é > = 1.0.0.

No NuGet 2.5 e mais recente:

  • O NuGet não atualizará mais B, porque detecta que a versão 1.0.0 existente satisfaz a restrição de versão de dependência.

Para obter mais informações sobre essa mudança, leia o [work item](https://nuget.codeplex.com/workitem/1681) detalhado, bem como o [discussion thread](https://nuget.codeplex.com/discussions/436712) relacionado.

NuGet.exe gera solicitações HTTP com detalhamento detalhado

Se você estiver solucionando problemas do nuget.exe ou apenas estiver curioso sobre quais solicitações HTTP são feitas durante as operações, a opção '-verbosity detailed' agora produzirá todas as solicitações HTTP feitas.

HTTP output from nuget.exe

O push .exe nuget agora oferece suporte a UNC e fontes de pasta

Antes do NuGet 2.5, se você tentasse executar o 'nuget.exe push' para uma origem de pacote com base em um caminho UNC ou pasta local, o push falharia. Com o recurso de configuração hierárquica adicionado recentemente, tornou-se comum que o nuget.exe precise direcionar uma fonte UNC/pasta ou uma Galeria NuGet baseada em HTTP.

A partir do NuGet 2.5, se o nuget.exe identificar uma origem UNC/pasta, ele executará a cópia do arquivo para a origem.

O seguinte comando funcionará agora:

nuget push -source \\mycompany\repo\ mypackage.1.0.0.nupkg

nuget.exe dá suporte a arquivos de configuração explicitamente especificados

Os comandos nuget.exe que acessam a configuração (todos, exceto 'spec' e 'pack') agora oferecem suporte a uma nova opção '-ConfigFile', que força um arquivo de configuração específico a ser usado no lugar do arquivo de configuração padrão em %AppData%\nuget\Nuget.Config.

Exemplo:

nuget sources add -name test -source http://test -ConfigFile C:\test\.nuget\Nuget.Config

Suporte para projetos nativos

Com o NuGet 2.5, as ferramentas do NuGet agora estão disponíveis para projetos nativos no Visual Studio. Esperamos que a maioria dos pacotes nativos utilize o recurso de importações do MSBuild acima, usando uma ferramenta criada pelo projeto CoApp. Para obter mais informações, leia os detalhes sobre a ferramenta no site da coapp.org.

O nome da estrutura de destino "native" é introduzido para pacotes para incluir arquivos em \build, \content e \tools quando o pacote é instalado em um projeto nativo. A pasta 'lib' não é usada para projetos nativos.