Notas de la versión de NuGet 2.1

Notas de la versión de NuGet 2.0 | Notas de la versión de NuGet 2.2

NuGet 2.1 se publicó el 4 de octubre de 2012.

Nuget.Config jerárquico

NuGet 2.1 le ofrece una mayor flexibilidad para controlar la configuración de NuGet mediante el recorrido recursivo de la estructura de carpetas en busca de archivos NuGet.Config y, después, compilar la configuración a partir del conjunto de todos los archivos encontrados. Por ejemplo, considere el escenario en el que un equipo tiene un repositorio de paquetes interno para las compilaciones de CI de otras dependencias internas. La estructura de carpetas para un proyecto individual podría tener este aspecto:

C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1

Además, si la restauración de paquetes está habilitada para la solución, también existirá la siguiente carpeta:

C:\myteam\solution1\.nuget

A fin de que el repositorio de paquetes interno del equipo esté disponible para todos los proyectos en los que trabaja el equipo, pero no para todos los proyectos de la máquina, se puede crear un archivo Nuget.Config y colocarlo en la carpeta c:\myteam. No hay ninguna manera de especificar una carpeta de paquetes para cada proyecto.

<configuration>
    <packageSources>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </activePackageSource>
</configuration>

Ahora puede ver que el código fuente se ha agregado al ejecutar el comando "nuget.exe sources" desde cualquier carpeta debajo de c:\myteam, como se muestra a continuación:

Se busca en los archivos NuGet.Config en el orden siguiente:

1. .nuget\Nuget.Config
2. Recorrido recursivo desde la carpeta del proyecto a la raíz
3. Nuget.Config global (%appdata%\NuGet\Nuget.Config)

Las configuraciones se aplican en el orden inverso, lo que significa que, en función de la ordenación anterior, se aplicaría primero Nuget.Config global, seguido de los archivos Nuget.Config detectados desde la raíz a la carpeta del proyecto, seguido de .nuget\Nuget.Config. Esto es especialmente importante si usa el elemento <clear/> para quitar un conjunto de elementos de la configuración.

Especificación de la ubicación de la carpeta "packages"

En el pasado, NuGet ha administrado los paquetes de una solución desde una carpeta "packages" conocida que se encuentra debajo de la carpeta raíz de la solución. En el caso de los equipos de desarrollo que tienen muchas soluciones diferentes con paquetes NuGet instalados, esto puede dar lugar a que el mismo paquete se instale en muchos lugares diferentes en el sistema de archivos.

En NuGet 2.1 se proporciona un control más granular sobre la ubicación de la carpeta packages por medio del elementorepositoryPath del archivo NuGet.Config. Siguiendo con el ejemplo anterior de compatibilidad jerárquica con Nuget.Config, imagine que quiere que todos los proyectos de C:\myteam\ compartan la misma carpeta de paquetes. Para ello, basta con agregar la siguiente entrada a c:\myteam\Nuget.Config.

<configuration>
    <config>
    <add key="repositoryPath" value="C:\myteam\teampackages" />
    </config>
    ...
</configuration>

En este ejemplo, el archivo Nuget.Config compartido especifica una carpeta de paquetes compartidos para cada proyecto que se crea debajo de C:\myteam, independientemente de la profundidad. Tenga en cuenta que si tiene una carpeta de paquetes existente debajo de la raíz de la solución, debe eliminarla antes de que NuGet coloque los paquetes en la nueva ubicación.

Compatibilidad con bibliotecas portátiles

Las bibliotecas portátiles son una característica introducida por primera vez con .NET 4 que permite compilar ensamblados que pueden funcionar sin modificaciones en distintas plataformas de Microsoft, desde versiones de .NET Framework a Silverlight, Windows Phone e incluso Xbox 360 (aunque en este momento, NuGet no admite el destino de la biblioteca portátil de Xbox). Al extender las convenciones de paquetes para versiones y perfiles de marco, en NuGet 2.1 ahora se admiten bibliotecas portátiles al permitirle crear paquetes que tengan carpetas lib de destino de perfil y marco compuestas.

Por ejemplo, considere las siguientes plataformas de destino disponibles de la biblioteca de clases portables.

Una vez que se compila la biblioteca y se ejecuta el comando nuget.exe pack MyPortableProject.csproj, se puede ver la nueva estructura de carpetas de paquete de biblioteca portátil si se examina el contenido del paquete NuGet generado.

Como puede ver, la convención de nombre de carpeta de biblioteca portátil sigue el patrón "portátil-{marco 1}+{marco n}" donde los identificadores del marco siguen lasconvenciones de nombre de marco y versión existentes. Hay una excepción a las convenciones de nombre y versión en el identificador de marco que se usa para Windows Phone. Este moniker debe usar el nombre de marco "wp" (wp7, wp71 o wp8). Por ejemplo, si se usa "silverlight-wp7", se producirá un error.

Al instalar el paquete que se crea a partir de esta estructura de carpetas, NuGet ahora puede aplicar sus reglas de marco y perfil a varios destinos, como se especifica en el nombre de la carpeta. A las reglas de coincidencia de NuGet subyace el principio de que los destinos "más específicos" tendrán prioridad sobre los "menos específicos". Esto significa que los monikers destinados a una plataforma específica siempre se prefieren sobre los portátiles si ambos son compatibles con un proyecto. Además, si varios destinos portátiles son compatibles con un proyecto, NuGet preferirá aquel cuyo conjunto de plataformas admitido sea "más cercano" al proyecto que hace referencia al paquete.

Proyectos de Windows 8 y Windows Phone 8 como destino

Además de agregar compatibilidad con proyectos de bibliotecas portátiles de destino, en NuGet 2.1 se proporcionan nuevos monikers de marco para proyectos de la Tienda de Windows 8 y Windows Phone 8, así como algunos nuevos monikers generales para proyectos de Microsoft Store y Windows Phone que serán más fáciles de administrar en versiones futuras de cada plataforma.

En el caso de las aplicaciones de la Tienda de Windows 8, los identificadores tienen el siguiente aspecto:

NuGet 2.0 y versiones anteriores	NuGet 2.1
winRT45, .NETCore45	Windows, Windows8, win, win8

En el caso de los proyectos de Windows Phone, los identificadores son los siguientes:

Sistema operativo Phone	NuGet 2.0 y versiones anteriores	NuGet 2.1
Windows Phone 7	silverlight3-wp	wp, wp7, WindowsPhone, WindowsPhone7
Windows Phone 7.5 (Mango)	silverlight4-wp71	wp71, WindowsPhone71
Windows Phone 8	(no se admite)	wp8, WindowsPhone8

En todos los cambios anteriores, los nombres de marco antiguos seguirán siendo totalmente compatibles con NuGet 2.1. Al avanzar, se deben usar los nuevos nombres, ya que serán más estables en futuras versiones de cada plataforma. Pero los nuevos nombres *no* se admitirán en las versiones de NuGet anteriores a la 2.1, por lo que debe planear en consecuencia cuándo realizar el cambio.

Búsqueda mejorada en el cuadro de diálogo Administrador de paquetes

En el pasado, se han introducido cambios en la galería de NuGet que han mejorado considerablemente la velocidad y relevancia de las búsquedas de paquetes. Pero estas mejoras se han limitado al sitio web de nuget.org. NuGet 2.1 hace que la experiencia de búsqueda mejorada esté disponible desde el cuadro de diálogo Administrador de paquetes NuGet. Por ejemplo, imagine que quiere encontrar el paquete de versión preliminar de almacenamiento en caché de Windows Azure. Una consulta de búsqueda razonable para este paquete podría ser "Caché de Azure". En versiones anteriores del cuadro de diálogo Administrador de paquetes, el paquete deseado ni siquiera aparecería en la primera página de resultados. Pero en NuGet 2.1, ahora el paquete deseado aparece en la parte superior de los resultados de la búsqueda.

Actualización de paquete forzada

Antes de NuGet 2.1, NuGet omitía la actualización de un paquete cuando no había un número de versión alto. Esto provocaba fricción en determinados escenarios, especialmente en los de compilación o CI, en los que el equipo no quería incrementar el número de versión del paquete con cada compilación. El comportamiento deseado era forzar una actualización. En NuGet 2.1, esto se soluciona con la marca "reinstall". Por ejemplo, en versiones anteriores de NuGet se generaba lo siguiente al intentar actualizar un paquete que no tenía una versión de paquete más reciente:

PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.

Con la marca reinstall, el paquete se actualizará independientemente de si hay una versión más reciente.

PM> Update-Package Moq -Reinstall
Successfully removed 'Moq 4.0.10827' from MySolution.MyConsole.
Successfully uninstalled 'Moq 4.0.10827'.
Successfully installed 'Moq 4.0.10827'.
Successfully added 'Moq 4.0.10827' to MySolution.MyConsole.

Otro escenario en el que la marca reinstall resulta beneficiosa es el de cambio de destino de un marco. Al cambiar la plataforma de destino de un proyecto (por ejemplo, de .NET 4 a .NET 4.5), Update-Package -Reinstall puede actualizar las referencias a los ensamblados correctos para todos los paquetes NuGet instalados en el proyecto.

Edición de orígenes de paquetes en Visual Studio

En versiones anteriores de NuGet, la actualización de un origen de paquete desde el cuadro de diálogo de opciones de Visual Studio requería eliminar y volver a agregar el origen del paquete. En NuGet 2.1 se mejora este flujo de trabajo al admitir la actualización como una función de primera clase de la interfaz de usuario de configuración.

Correcciones de errores

En NuGet 2.1 se incluyen muchas correcciones de errores. Para obtener una lista completa de los elementos de trabajo corregidos en NuGet 2.0, vea [NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Fixed&type=All&priority=All&release=NuGet%202.1&assignedTo=All&component=All&sortField=LastUpdatedDate&sortDirection=Descending&page=0).