Compartilhar via


Notas de versão do NuGet 2.5

Notas de versão do NuGet 2.2.1 | Notas de versão do NuGet 2.6

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

Reconhecimento

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) - Adicione 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) - Corrigir a ortografia de NuGet.targets em um sistema operacional sensível a maiúsculas e minúsculas
  3. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
    • Crie a solução com base no Mono.
  4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
    • Corrigir falhas 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) - comando pack do nuget.exe 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 tratamento XML modificado para preservar a formatação.
  7. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • Foram adicionadas palavras reconhecidas ao dicionário personalizado para permitir que build.cmd tenham êxito.
  8. [Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
    • Corrigir testes de unidade ao executar em um VS localizado.
  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) – Gerenciar dependências de projeto ao criar pacotes
  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 Claro 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) - Corrigir a descrição da ajuda do Get-Package

Também apreciamos os seguintes indivíduos por encontrarem bugs com o 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 quebrado com as compilações mais recentes do NuGet 2.4 e 2.5

Recursos notáveis 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 em 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 sempre eram ignorados.

Substituir arquivos de conteúdo

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

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

Importação automática de arquivos de props e alvos 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 em build ou em pastas específicas da estrutura, assim como as outras pastas. A regra para escolher a pasta de estrutura que melhor corresponda é exatamente a mesma que nas outras.

Quando o NuGet instala um pacote com \arquivos de build, adicionará um elemento MSBuild <Import> no arquivo de projeto que aponta para os arquivos .targets e .props. O .props arquivo é adicionado na parte superior, enquanto o .targets arquivo é adicionado à parte inferior.

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

Antes da 2.5, no .nuspec arquivo, o usuário só pode especificar os arquivos de referência a serem adicionados para todas as estruturas. Agora, com esse novo recurso na versão 2.5, o usuário pode criar o <reference/> elemento para cada uma das plataformas com suporte, 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 .nuspec arquivo:

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

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

Observação: atualmente você deve usar nuget.exe pacote para usar esse recurso; O Gerenciador de Pacotes NuGet ainda não dá suporte a ele.

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

Muitos de vocês sabem sobre o cmdlet "Update-Package" do PowerShell 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 este recurso:

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

Botão Atualizar Tudo na caixa de diálogo

Suporte de referência de projeto aprimorado 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 correspondente .nuspec, por exemplo, há um arquivo chamado proj1.nuspec na mesma pasta que proj1.csproj, então esse projeto é adicionado como uma dependência ao pacote, usando a identificação e a versão lidas do arquivo .nuspec.
  2. Caso contrário, os arquivos do projeto referenciado serão agrupados no pacote. Em seguida, os projetos referenciados por esse projeto serão processados usando as mesmas regras recursivamente.
  3. Todos os arquivos DLL, .pdb e .exe são adicionados.
  4. Todos os outros arquivos de conteúdo são adicionados.
  5. Todas as dependências são integradas.

Isso permite que um projeto referenciado seja tratado como uma dependência se houver um .nuspec arquivo, 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 .nuspec recursos forem 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, as indicações visuais serão fornecidas ao usuário indicando que o pacote não será instalável. Em seguida, o usuário será orientado a atualizar sua versão do NuGet.

Isso melhorará a experiência atual 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 de pacotes

Antes do NuGet 2.5, quando um pacote era instalado que dependia de um pacote já instalado no projeto, a dependência seria atualizada como parte da nova instalação, mesmo que a versão existente atendesse à 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 origem 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 anteriores:

  • Ao instalar o pacote A, o NuGet atualizará automaticamente b para 1.0.2, embora a versão existente 1.0.0 já atenda à 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, pois detecta que a versão 1.0.0 existente atende à restrição de versão de dependência.

Para obter mais informações sobre essa alteração, leia os detalhes [work item](https://nuget.codeplex.com/workitem/1681) , bem como os relacionados [discussion thread](https://nuget.codeplex.com/discussions/436712).

nuget.exe gera solicitações http com verbosidade detalhada

Se você estiver resolvendo problemas com o nuget.exe ou apenas curioso para saber quais solicitações HTTP são feitas durante as operações, o parâmetro '-verbosity detailed' agora exibirá um detalhamento de todas as solicitações HTTP feitas.

Saída HTTP de nuget.exe

nuget.exe push agora oferece suporte a fontes UNC e pastas

Antes do NuGet 2.5, se você tentasse executar 'nuget.exe push' para uma fonte 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 nuget.exe precisasse direcionar uma origem UNC/pasta ou Galeria NuGet baseada em HTTP.

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

O comando a seguir agora funcionará:

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

nuget.exe dá suporte a arquivos Config especificados explicitamente

nuget.exe comandos que acessam a configuração (todos, exceto 'spec' e 'pack') agora dão 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 do coapp.org.

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