Compartir a través de

Notas de la versión de NuGet 2.5

  • Artículo

Notas de la versión de NuGet 2.2.1 | Notas de la versión de NuGet 2.6

NuGet 2.5 se publicó el 25 de abril de 2013. Esta versión era tan grande que se tuvieron que omitir las versiones 2.3 y 2.4. Hasta la fecha, es la versión más grande de NuGet, con más de [160 work items](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.5&status=all) en la versión.

Agradecimientos

Nos gustaría agradecer a los siguientes colaboradores externos sus contribuciones significativas a NuGet 2.5:

  1. [Daniel Plaisted](https://www.codeplex.com/site/users/view/dsplaisted) (@dsplaisted)
    • [#2847](https://nuget.codeplex.com/workitem/2847): se han agregado MonoAndroid, MonoTouch y MonoMac a la lista de identificadores de marco de destino conocidos.
  2. [Andres G. Aragoneses](https://www.codeplex.com/site/users/view/knocte) (@knocte)
    • [#2865](https://nuget.codeplex.com/workitem/2865): se ha corregido la ortografía de NuGet.targets para un sistema operativo que distingue mayúsculas y minúsculas
  3. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
    • Creación de la compilación de la solución en Mono.
  4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
    • Corrección de errores en las pruebas unitarias en Mono.
  5. [Olivier Dagenais](https://www.codeplex.com/site/users/view/OliIsCool) (@OliIsCool)
    • [#2920](https://nuget.codeplex.com/workitem/2920): el comando nuget.exe pack no propaga propiedades a MSBuild
  6. [Miroslav Bajtos](https://www.codeplex.com/site/users/view/MiroslavBajtos) (@bajtos)
    • [#1511](https://nuget.codeplex.com/workitem/1511): código de control XML modificado para conservar el formato.
  7. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • Se han agregado palabras reconocidas al diccionario personalizado para permitir que build.cmd se ejecute correctamente.
  8. [Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
    • Corrección de pruebas unitarias al ejecutarse en VS localizado.
  9. [Gareth Evans](https://www.codeplex.com/site/users/view/garethevans)
    • Interfaz extraída de PackageService
  10. [Maxime Brugidou](https://www.codeplex.com/site/users/view/brugidou) (@brugidou)
    • [#936](https://nuget.codeplex.com/workitem/936): control de las dependencias del proyecto al empaquetar
  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): compatibilidad con contraseñas de texto no cifrado al almacenar credenciales de origen del paquete en archivos de 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): se ha corregido la descripción de la ayuda Get-Package

También agradecemos a los siguientes usuarios la búsqueda de errores con NuGet 2.5 Beta/RC aprobados y corregidos antes de la versión final:

  1. [Tony Wall](https://www.codeplex.com/site/users/view/CodeChief) (@CodeChief)
    • [#3200](https://nuget.codeplex.com/workitem/3200): interrupción de MSTest con las compilaciones de NuGet 2.4 y 2.5

Características importantes de la versión

Permiso para que los usuarios sobrescriban archivos de contenido que ya existen

Una de las características más solicitadas ha sido la capacidad de sobrescribir archivos de contenido que ya existen en el disco cuando se incluyen en un paquete NuGet. A partir de NuGet 2.5, estos conflictos se identifican y se le pedirá que sobrescriba los archivos, mientras que antes siempre se omitían.

Overwrite content files

"nuget.exe update" e "Install-Package" ahora tienen una nueva opción "-FileConflictAction" a fin de establecer algunos valores predeterminados para escenarios de línea de comandos.

Establezca una acción predeterminada cuando ya exista un archivo de un paquete en el proyecto de destino. Establézcalo en "Overwrite" para sobrescribir siempre los archivos. Establézcalo en "Ignore" para omitir los archivos. Si no se especifica, se solicitará para cada archivo en conflicto.

Importación automática de destinos y archivos de propiedades de MSBuild

Se ha creado una carpeta convencional en el nivel superior del paquete NuGet. Como elemento del mismo nivel que \lib, \contenty \tools, ahora puede incluir una carpeta \build en el paquete. En esta carpeta, puede colocar dos archivos con nombres fijos, {packageid}.targets o {packageid}.props. Estos dos archivos pueden estar directamente bajo build o en carpetas específicas del marco, como las otras carpetas. La regla para elegir la carpeta de marco con la mejor coincidencia es exactamente la misma que en esas.

Cuando NuGet instala un paquete con archivos \build, agrega un elemento <Import> de MSBuild en el archivo del proyecto que apunta a los archivos .targets y .props. El archivo .props se agrega en la parte superior, mientras que el archivo .targets se agrega en la parte inferior.

Especificación de diferentes referencias por plataforma mediante el elemento <References/>

Antes de la versión 2.5, en el archivo .nuspec, el usuario solo podía especificar los archivos de referencia que se van a agregar para todo el marco. Ahora con esta nueva característica de la versión 2.5, el usuario puede crear el elemento <reference/> para cada una de las plataformas admitidas, por ejemplo:

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

Este es el flujo de cómo NuGet agrega referencias a proyectos en función del archivo .nuspec:

  1. Busque la carpeta lib adecuada para el marco de destino y obtenga la lista de ensamblados de esa carpeta
  2. Busque por separado el grupo de referencias adecuado para el marco de destino y obtenga la lista de ensamblados de ese grupo. El grupo de referencia sin el marco de destino especificado es el grupo de reserva.
  3. Busque la intersección de las dos listas y úsela como las referencias que se van a agregar

Esta nueva característica permitirá a los creadores de paquetes usar la característica Referencias para aplicar subconjuntos de ensamblados a marcos diferentes cuando, de lo contrario, necesitarían llevar ensamblados duplicados en varias carpetas lib.

Nota: Actualmente debe usar nuget.exe pack para utilizar esta característica; en el Explorador de paquetes NuGet aún no se admite.

Botón Actualizar todo para permitir la actualización de todos los paquetes a la vez

Muchos usuarios conocen el cmdlet "Update-Package" de PowerShell para actualizar todos los paquetes; ahora también hay una manera fácil de hacerlo desde la interfaz de usuario.

Para probar esta característica:

  1. Cree una aplicación ASP.NET MVC
  2. Abra el cuadro de diálogo "Administrar paquetes NuGet"
  3. Seleccione "Actualizaciones"
  4. Haga clic en el botón "Actualizar todo"

Update All button in the dialog

Compatibilidad mejorada de la referencia de proyectos para Pack de nuget.exe

Ahora, el comando Pack de nuget.exe procesa con las reglas siguientes los proyectos a los que se hace referencia:

  1. Si el proyecto al que se hace referencia tiene el archivo .nuspec correspondiente, por ejemplo, hay un archivo llamado proj1.nuspec en la misma carpeta que proj1.csproj, este proyecto se agrega como una dependencia al paquete, con el identificador y la versión leídos del archivo .nuspec.
  2. De lo contrario, los archivos del proyecto al que se hace referencia se agrupan en el paquete. Después, los proyectos a los que hace referencia este proyecto se procesarán mediante las mismas reglas de forma recursiva.
  3. Se agregan todos los archivos DLL, .pdb y .exe.
  4. Se agregan todos los demás archivos de contenido.
  5. Se combinan todas las dependencias.

Esto permite que un proyecto al que se hace referencia se trate como una dependencia si hay un archivo .nuspec; de lo contrario, se convierte en parte del paquete.

Más detalles aquí: [http://nuget.codeplex.com/workitem/936](http://nuget.codeplex.com/workitem/936)

Adición de una propiedad "Versión mínima de NuGet" a los paquetes

Ahora, un nuevo atributo de metadatos denominado "minClientVersion" puede indicar la versión mínima del cliente NuGet necesaria para consumir un paquete.

Esta característica ayuda al creador del paquete a especificar que un paquete funcionará solo después de una versión determinada de NuGet. A medida que se agregan nuevas características de .nuspec después de NuGet 2.5, los paquetes podrán reclamar una versión mínima de NuGet.

<metadata minClientVersion="2.6">

Si el usuario ha instalado NuGet 2.5 y un paquete se identifica como que necesita la versión 2.6, se proporcionarán indicaciones visuales al usuario para indicar que el paquete no se puede instalar. Después, se guiará al usuario para que actualice la versión de NuGet.

Esto mejorará la experiencia existente en la que los paquetes comienzan a instalarse, pero se producirá un error que indica que se ha identificado una versión del esquema no reconocida.

Las dependencias ya no se actualizan innecesariamente durante la instalación del paquete

Antes de NuGet 2.5, cuando se instalaba un paquete que dependía de otro ya instalado en el proyecto, la dependencia se actualizaba como parte de la nueva instalación, incluso si la versión existente cumplía la dependencia.

A partir de NuGet 2.5, si ya se cumple una versión de dependencia, la dependencia no se actualizará durante las instalaciones de otros paquetes.

Escenario:

  1. El repositorio de origen contiene el paquete B con la versión 1.0.0 y 1.0.2. También contiene el paquete A que tiene una dependencia de B (>= 1.0.0).
  2. Imagine que el proyecto actual ya tiene instalado el paquete B versión 1.0.0. Ahora quiere instalar el paquete A.

En NuGet 2.2 y versiones anteriores:

  • Al instalar el paquete A, NuGet actualizará automáticamente B a 1.0.2, aunque la versión 1.0.0 existente ya cumpla la restricción de versión de dependencia, que es >= 1.0.0.

En NuGet 2.5 y versiones posteriores:

  • NuGet ya no actualizará B, porque detecta que la versión 1.0.0 existente satisface la restricción de versión de dependencia.

Para más información sobre este cambio, lea los detalles de [work item](https://nuget.codeplex.com/workitem/1681), así como los relacionados de [discussion thread](https://nuget.codeplex.com/discussions/436712).

nuget.exe genera solicitudes HTTP detalladas

Si va a solucionar problemas de nuget.exe o simplemente tiene curiosidad por las solicitudes HTTP que se realizan durante las operaciones, el modificador "-verbosity detailed" ahora mostrará todas las solicitudes HTTP realizadas.

HTTP output from nuget.exe

Ahora push de nuget.exe ahora admite orígenes UNC y de carpeta

Antes de NuGet 2.5, si se intentaba ejecutar "nuget.exe push" en un origen de paquete basado en una ruta de acceso UNC o una carpeta local, se producía un error en la inserción. Con la característica de configuración jerárquica agregada recientemente, era habitual que nuget.exe tuviera que seleccionar como destino un origen UNC o una carpeta, o bien una galería de NuGet basada en HTTP.

A partir de NuGet 2.5, si nuget.exe identifica un origen UNC o de carpeta, realizará la copia del archivo en el origen.

El siguiente comando no funcionará:

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

nuget.exe admite archivos Config especificados de forma explícita

Los comandos de nuget.exe que acceden a la configuración (todos excepto "spec" y "pack") ahora admiten una nueva opción "-ConfigFile", que obliga a usar un archivo de configuración específico en lugar del predeterminado en %AppData%\nuget\Nuget.Config.

Ejemplo:

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

Compatibilidad con proyectos nativos

Con NuGet 2.5, ahora las herramientas de NuGet están disponibles para proyectos nativos en Visual Studio. Esperamos que la mayoría de los paquetes nativos usen la característica de importaciones de MSBuild anterior, mediante una herramienta creada por el proyecto CoApp. Para más información, lea los detalles sobre la herramienta en el sitio web de coapp.org.

El nombre del marco de destino "native" se ha introducido para que los paquetes incluyan archivos en \build, \content y \tools cuando el paquete se instala en un proyecto nativo. La carpeta "lib" no se usa para proyectos nativos.