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.

Configuración Nuget jerárquica

NuGet 2.1 le ofrece una mayor flexibilidad para controlar la configuración de NuGet recorriendo recursivamente la estructura de carpetas buscando archivos de NuGet.Config y luego construir la configuración a partir 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 de un proyecto individual podría ser similar a la siguiente:

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

Para que el repositorio de paquetes interno del equipo esté disponible para todos los proyectos en los que trabaja el equipo, aunque no lo haga disponible para cada proyecto de la máquina, podemos crear un nuevo archivo Nuget.Config y colocarlo en la carpeta c:\myteam. No hay ninguna manera de especificar una carpeta de paquetes por 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 podemos ver que el origen se agregó ejecutando el comando "nuget.exe sources" desde cualquier carpeta debajo de c:\myteam, como se muestra a continuación:

NuGet.Config Los archivos se buscan en el orden siguiente:

1. .nuget\Nuget.Config
2. Paseo recursivo de la carpeta del proyecto a la raíz
3. Global Nuget.Config (%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 el Nuget.Config global, seguido de los archivos Nuget.Config detectados desde la carpeta raíz hasta la del proyecto, seguido de .nuget\Nuget.Config. Esto es especialmente importante si usa el <clear/> elemento para quitar un conjunto de elementos de la configuración.

Especificar 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 que tienen instalados paquetes NuGet, esto puede dar lugar a que el mismo paquete se instale en muchos lugares diferentes en el sistema de archivos.

NuGet 2.1 proporciona un control más granular sobre la ubicación de la carpeta packages a través del repositoryPath elemento del NuGet.Config archivo. Basándose en el ejemplo anterior de compatibilidad jerárquica con Nuget.Config, supongamos que deseamos tener todos los proyectos en C:\myteam\ compartir 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 compartido Nuget.Config 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 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 the.NET Framework a Silverlight a 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 paquete para las versiones y perfiles del marco, NuGet 2.1 ahora admite bibliotecas portátiles al permitirle crear paquetes que tengan carpetas de destino de perfil lib y marco compuestas.

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

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

Como puede ver, la convención de nombre de carpeta de biblioteca portátil sigue el patrón 'portable-{framework 1}+{framework n}' donde los identificadores del marco siguen las convenciones de nombre de marco y versión existentes. Se encuentra 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). El uso de "silverlight-wp7", por ejemplo, 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, tal como se especifica en el nombre de la carpeta. El principio detrás de las reglas de coincidencia de NuGet es 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 en el que el conjunto de plataformas admitido sea el que esté "más cercano" al proyecto que hace referencia al paquete.

Enfoque en proyectos de Windows 8 y Windows Phone 8

Además de agregar compatibilidad para proyectos de bibliotecas portátiles como objetivo, NuGet 2.1 proporciona nuevos identificadores de marco para proyectos de la Tienda de Windows 8 y Windows Phone 8, así como algunos nuevos identificadores generales para proyectos de la Tienda de Windows y Windows Phone que serán más fáciles de administrar en futuras versiones de las respectivas plataformas.

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

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

A lo largo de las últimas iteraciones, se han introducido cambios en la galería de NuGet que han mejorado considerablemente la velocidad y relevancia de las búsquedas de paquetes. Sin embargo, estas mejoras se limitaron al sitio web de nuget.org. NuGet 2.1 hace que la experiencia de búsqueda mejorada esté disponible a través del cuadro de diálogo administrador de paquetes NuGet. Por ejemplo, imagine que quería encontrar el paquete de versión preliminar de almacenamiento en caché de Windows Azure. Una consulta de búsqueda razonable para este paquete puede ser "Azure Cache". En versiones anteriores del cuadro de diálogo del administrador de paquetes, el paquete deseado ni siquiera aparecería en la primera página de resultados. Sin embargo, en NuGet 2.1, el paquete deseado aparece ahora en la parte superior de los resultados de la búsqueda.

Forzar actualización de paquete de software

Antes de NuGet 2.1, NuGet omitiría la actualización de un paquete cuando no había un número de versión alto. Esto introdujo fricción para determinados escenarios, especialmente en el caso de escenarios 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 independientemente. NuGet 2.1 aborda esto con el indicador "reinstalar". Por ejemplo, las versiones anteriores de NuGet darían lugar a 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 de reinstalación, 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 el indicador de reinstalación resulta beneficioso es el de la reorientación del marco de trabajo. 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. NuGet 2.1 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

NuGet 2.1 incluye muchas correcciones de errores. Para obtener una lista completa de los elementos de trabajo fijos 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)