Partilhar 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

O NuGet 2.5 foi lançado em 25 de abril de 2013. Este lançamento foi tão grande que nos sentimos obrigados 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 [160 work items](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.5&status=all) no lançamento.

Agradecimentos

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) - Correção ortográfica de NuGet.targets para um sistema operativo sensível a maiúsculas e minúsculas
  3. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
    • Faça com que a solução se baseie no Mono.
  4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
    • Corrigir testes de unidade que estão a falhar no Mono.
  5. [Olivier Dagenais](https://www.codeplex.com/site/users/view/OliIsCool) (@OliIsCool)
    • [#2920](https://nuget.codeplex.com/workitem/2920) - o comando pack do nuget.exe não propaga as 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)
    • 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)
    • Corrija os testes de unidade ao executar no Visual Studio 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) - 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 Clear Text Password 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 de ajuda do Get-Package

Também agradecemos às seguintes pessoas por encontrarem bugs com o NuGet 2.5 Beta/RC que foram aprovados e corrigidos antes do lançamento final:

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

Características notáveis no lançamento

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.

Sobrescrever ficheiros 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 um arquivo de um pacote já existir no projeto de destino. Defina como 'Substituir' para sempre substituir ficheiros. Defina como 'Ignorar' para ignorar ficheiros. Se não for especificado, ele solicitará cada arquivo conflitante.

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

Uma nova pasta convencional foi criada no nível superior do pacote NuGet. Como par de \lib, \content, e \tools, agora pode incluir uma pasta \build no seu pacote. Nesta 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 nestas.

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

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

Antes da versão 2.5, no .nuspec arquivo, o usuário só pode especificar os arquivos de referência, a serem adicionados para toda a estrutura. Agora, com este novo recurso na versão 2.5, o usuário pode criar o <reference/> elemento 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 baseado no arquivo .nuspec:

  1. Localize a lib pasta apropriada para a estrutura de destino e obtenha a lista de assemblies dessa pasta
  2. Separadamente, identifique o grupo de referências apropriado para o framework de destino e obtenha a lista de assemblies desse grupo. O grupo de referência sem estrutura de destino especificada é o grupo de fallback.
  3. Encontre a interseção das duas listas e use-a como as 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 plataformas, quando, de outra forma, precisariam incluir assemblies duplicados em várias pastas lib.

Nota: atualmente deve utilizar nuget.exe pack para utilizar esta funcionalidade; O Gerenciador de Pacotes NuGet 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 sabem sobre o cmdlet PowerShell "Update-Package" para atualizar todos os seus pacotes; agora há uma maneira fácil de fazer isso através da interface do usuário também.

Para experimentar esta funcionalidade:

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

Botão Atualizar tudo na caixa de diálogo

Suporte de referência de projeto melhorado para o nuget.exe Pack

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

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

Isso permite que um projeto referenciado seja tratado como uma dependência se houver um .nuspec arquivo, caso contrário, ele se torna 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 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 o 2.6, indicações visuais serão dadas ao usuário indicando que o pacote não será instalável. O usuário será então 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.

Durante a instalação de pacotes, as dependências já não são atualizadas desnecessariamente.

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 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á tem 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 existente 1.0.0 já satisfaça a restrição de versão de dependência, que é >= 1.0.0.

No NuGet 2.5 e versões mais recentes:

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

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

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

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

Saída HTTP do nuget.exe

nuget.exe push agora suporta UNC e origens de pasta

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 recentemente adicionado, tornou-se comum que o nuget.exe precisasse apontar para uma fonte UNC/pasta ou uma Galeria NuGet baseada em HTTP.

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

O seguinte comando agora funcionará:

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

nuget.exe suporta arquivos de configuração especificados explicitamente

nuget.exe comandos que acessam a configuração (todos, exceto 'spec' e 'pack') agora suportam 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 do framework de destino "nativo" é introduzido para pacotes que incluem arquivos em \build, \content e \tools quando o pacote é instalado num projeto nativo. A pasta 'lib' não é usada para projetos nativos.