Compartir a través de

Notas de la versión de NuGet 2.7

Notas de la versión de NuGet 2.6.1 para WebMatrix | Notas de la versión de NuGet 2.7.1

NuGet 2.7 se publicó el 22 de agosto de 2013.

Reconocimientos

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

  1. [Mike Roth](http://www.codeplex.com/site/users/view/mxrss) (@mxrss)
    • Mostrar la URL de la licencia al enumerar paquetes cuando la verbosidad es detallada.
  2. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • [#1956](http://nuget.codeplex.com/workitem/1956) - Agregue el atributo developmentDependency a packages.config y úselo en el comando pack para incluir solo paquetes en tiempo de ejecución.
  3. [Rafael Nicoletti](http://www.codeplex.com/site/users/view/tkrafael) (@tkrafael)
    • Evite la clave de Properties duplicada en el comando pack de nuget.exe.
  4. [Ben Phegan](http://www.codeplex.com/site/users/view/benphegan) (@BenPhegan)
    • [#2610](http://nuget.codeplex.com/workitem/2610) - Aumente el tamaño de caché de la máquina a 200.
  5. [Slava Trenogin](http://www.codeplex.com/site/users/view/derigel) (@derigel)
    • [#3217](http://nuget.codeplex.com/workitem/3217) - Se ha corregido el cuadro de diálogo de NuGet que muestra las actualizaciones en la pestaña incorrecta.
    • Corregir que Project.TargetFramework puede ser nulo en ProjectManager
    • [#3248](http://nuget.codeplex.com/workitem/3248) - sharedPackageRepository FindPackage/FindPackagesById fallará si el packageId no existe.
  6. [Kevin Boyle](http://www.codeplex.com/site/users/view/KevinBoyleRG) (@kevfromireland)
    • [#3234](http://nuget.codeplex.com/workitem/3234) - Habilitar la compatibilidad con el proyecto Nomad
  7. [Corin Blaikie](http://www.codeplex.com/site/users/view/corinblaikie) (@corinblaikie)
    • [#3252](http://nuget.codeplex.com/workitem/3252) - Se ha corregido un error en el comando push con el código de salida 0 cuando el archivo no existe.
  8. [Martin Veselý](http://www.codeplex.com/site/users/view/veselkamartin)
    • [#3226](http://nuget.codeplex.com/workitem/3226) - Se ha corregido un error con Add-BindingRedirect comando cuando un proyecto hace referencia a un proyecto de base de datos.
  9. [Miroslav Bajtos](http://www.codeplex.com/site/users/view/miroslavbajtos) (@bajtos)
    • [#2891](http://nuget.codeplex.com/workitem/2891) - Se ha corregido un error de nuget.pack que analizaba comodín en el atributo "exclude" incorrectamente.
  10. [Justin Dearing](http://www.codeplex.com/site/users/view/zippy1981) (@zippy1981)
    • [#3307](http://nuget.codeplex.com/workitem/3307) - Corregir el error NuGet.targets para que pase $(Platform) a nuget.exe al restaurar paquetes.
  11. [Brian Federici](http://www.codeplex.com/site/users/view/benerdin)
    • [#3294](http://nuget.codeplex.com/workitem/3294) - Se ha corregido el error en el comando de paquete de nuget.exe que permitía agregar archivos con el mismo nombre pero diferente uso de mayúsculas y minúsculas, provocando finalmente la excepción "Item already exists".
  12. [Daniel Cazzulino](http://www.codeplex.com/site/users/view/dcazzulino) (@kzu)
    • [#2990](http://nuget.codeplex.com/workitem/2990) - Agregue la propiedad Version a la clase NetPortableProfile.
  13. [David Simner](https://www.codeplex.com/site/users/view/DavidSimner)
    • [#3460](https://nuget.codeplex.com/workitem/3460) - Se ha corregido el error NullReferenceException si requireApiKey = true, pero el encabezado X-NUGET-APIKEY no está presente.
  14. [Michael Friis](https://www.codeplex.com/site/users/view/friism) (@friism)
    • [#3278](https://nuget.codeplex.com/workitem/3278) - Corrige el archivo de destinos NuGet.Build para que funcione correctamente en MonoDevelop
  15. [Pranav Krishnamoorthy](https://www.codeplex.com/site/users/view/pranavkm) (@pranav_km)
    • Mejora del rendimiento de los comandos de restauración aumentando la paralelización

Características importantes de la versión

NuGet 2.7 presenta un nuevo enfoque para la restauración de paquetes y también supera un obstáculo importante: el consentimiento de la restauración del paquete ahora está activado de forma predeterminada. La combinación del nuevo enfoque y el consentimiento implícito simplificarán drásticamente los escenarios de restauración de paquetes.

Con las versiones 2.0, 2.1, 2.2, 2.5 y 2.6 de NuGet, los usuarios necesitaban permitir explícitamente que NuGet descargue paquetes que faltan durante la compilación. Si no se hubiera dado explícitamente este consentimiento, las soluciones que tenían habilitada la restauración de paquetes no podrían construirse hasta que el usuario hubiera concedido el consentimiento.

A partir de NuGet 2.7, el consentimiento de la restauración de paquetes está activado de forma predeterminada, al tiempo que permite a los usuarios rechazar explícitamente la restauración de paquetes si lo desea, mediante la casilla en la configuración de NuGet en Visual Studio. Este cambio de consentimiento implícito afecta a NuGet en los siguientes entornos:

  • Visual Studio 2013 Preview
  • Visual Studio 2012
  • Visual Studio 2010
  • utilidad de línea de comandos de nuget.exe

Restauración automática de paquetes en Visual Studio

A partir de NuGet 2.7, NuGet descargará automáticamente los paquetes que faltan durante la compilación en Visual Studio, incluso si la restauración de paquetes no se ha habilitado explícitamente para la solución. Esta restauración automática de paquetes se produce en Visual Studio al compilar un proyecto o la solución, pero antes de invocar MSBuild. Esto produce algunas ventajas significativas:

  1. No es necesario usar el gesto "Habilitar restauración de paquetes NuGet" en la solución
  2. No es necesario modificar los proyectos y NuGet no realizará cambios en el proyecto para asegurarse de que la restauración de paquetes está habilitada.
  3. Todos los paquetes NuGet, incluidos los que incluyeron importaciones de MSBuild para archivos props/targets, se restaurarán antes de invocar MSBuild, lo que garantiza que esas propiedades o destinos se reconozcan correctamente durante la compilación.

Para usar la restauración automática de paquetes en Visual Studio, solo debe realizar una (en)acción:

  1. No registrar la carpeta packages

Hay varias maneras de omitir la packages carpeta del control de código fuente. Para obtener más información, vea el tema Paquetes y control de código fuente .

Aunque todos los usuarios participan implícitamente en el consentimiento para la restauración automática de paquetes, puede optar por no participar fácilmente a través de los ajustes del Administrador de paquetes en Visual Studio.

Configuración del Administrador de paquetes

Restauración simplificada de paquetes desde el Command-Line

NuGet 2.7 presenta una nueva característica para nuget.exe: nuget.exe restore

Este nuevo comando Restore permite restaurar fácilmente todos los paquetes de una solución con un solo comando, aceptando un archivo de solución o carpeta como argumento. Además, ese argumento está implícito cuando solo hay una única solución en la carpeta actual. Esto significa que todo funciona desde una carpeta que contiene un único archivo de solución (MySolution.sln):

  1. nuget.exe restaurar MySolution.sln
  2. nuget.exe restaurar .
  3. restauración de nuget.exe

El comando Restaurar abrirá el archivo de solución y buscará todos los proyectos dentro de la solución. Desde allí, encontrará los packages.config archivos de cada uno de los proyectos y restaurará todos los paquetes encontrados. También restaura los paquetes de nivel de solución que se encuentran en el .nuget\packages.config archivo. Puede encontrar más información sobre el nuevo comando Restaurar en la referencia de línea de comandos.

Flujo de trabajo de restauración de paquetes nuevo

Nos complacen estos cambios en la restauración de paquetes, ya que presenta un nuevo flujo de trabajo. Si desea omitir los paquetes del control de código fuente, simplemente no confirma la packages carpeta. Los usuarios de Visual Studio que abren y compilan la solución verán los paquetes restaurados automáticamente. En el caso de las compilaciones de línea de comandos, simplemente invoque nuget.exe restore antes de invocar msbuild. Ya no es necesario recordar usar la acción "Habilitar la restauración de paquetes NuGet" en tu solución, y ya no necesitaremos ajustar tus proyectos para alterar la compilación. Y esto también produce una experiencia mucho mejorada para los paquetes que incluyen importaciones de MSBuild, especialmente para las importaciones agregadas a través de la característica reciente de NuGet para importar automáticamente archivos props/targets desde la carpeta \build.

Además del trabajo que hemos hecho nosotros mismos, también estamos trabajando con algunos asociados importantes para redondear este nuevo enfoque. Aún no tenemos escalas de tiempo concretas para ninguno de estos, pero cada socio está tan emocionado como estamos acerca del nuevo enfoque.

  • Team Foundation Service: están trabajando para integrar la llamada a nuget.exe restore en los escenarios de compilación predeterminados.
  • Sitios web de Windows Azure: están trabajando para permitirle enviar su proyecto a Azure y ejecutar nuget.exe restore antes de construir su sitio web.
  • TeamCity: actualizan su complemento del instalador de NuGet para TeamCity 8.x
  • AppHarbor - Están trabajando para permitirle hacer push a su repositorio en AppHarbor y que nuget.exe restore se llame antes de compilar su solución.

Con cada uno de los colaboradores mencionados anteriormente, usarían su propia copia de nuget.exe y no necesitaría incluir nuget.exe en su solución.

Problemas conocidos

Hubo dos problemas conocidos con nuget.exe restauración con la versión 2.7 inicial, pero se corrigieron el 6/9/2013 con una actualización al paquete NuGet.CommandLine. Esta actualización también está disponible en [NuGet 2.7 download page](https://nuget.codeplex.com/releases/view/107605) en CodePlex. Al ejecutar nuget.exe update -self, se actualizará a la versión más reciente.

Los fijos eran:

  1. [New package restore doesn't work on Mono when using SLN file](https://nuget.codeplex.com/workitem/3596)
  2. [New package restore doesn't work with Wix projects](https://nuget.codeplex.com/workitem/3598)

También hay un problema conocido con el nuevo flujo de trabajo de restauración de paquetes por el que [Automatic Package Restore does not work for projects under a solution folder](https://nuget.codeplex.com/workitem/3625). Este problema se corrigió en NuGet 2.7.1.

Redireccionamiento de Proyecto y Errores/Avisos de Construcción de Actualización

Muchas veces, después de cambiar el objetivo o actualizar su proyecto, puede encontrar que algunos paquetes NuGet no funcionan correctamente. Desafortunadamente, no hay ninguna indicación de esto y, a continuación, no hay ninguna guía sobre cómo abordarlo. Con NuGet 2.7, ahora usamos algunos eventos de Visual Studio para reconocer cuándo ha redirigido o actualizado su proyecto de manera que afecte a los paquetes NuGet instalados.

Si detectamos que alguno de sus paquetes se vieron afectados por el redireccionamiento o la actualización, generaremos errores de compilación inmediatos para informarle. Además del error de compilación inmediato, también se conserva un requireReinstallation="true" indicador en el archivo packages.config para todos los paquetes afectados por la reorientación, y cada compilación posterior en Visual Studio mostrará advertencias de compilación para esos paquetes.

Aunque NuGet no puede realizar acciones automáticas para reinstalar los paquetes afectados, esperamos que esta indicación y advertencia le ayudarán a detectar cuándo necesita reinstalar paquetes. También estamos trabajando en la documentación de instrucciones de reinstalación de paquetes a la que estos mensajes de error le dirigen.

Valores predeterminados de configuración de NuGet

Muchas empresas usan NuGet internamente, pero han tenido dificultades para guiar a sus desarrolladores a usar orígenes de paquetes internos en lugar de nuget.org. NuGet 2.7 presenta una característica de valores predeterminados de configuración que permite especificar los valores predeterminados de toda la máquina para:

  1. Orígenes de paquetes habilitados
  2. Orígenes de paquetes registrados, pero deshabilitados
  3. Origen de envío de nuget.exe predeterminado

Cada uno de estos ahora se puede configurar dentro de un archivo ubicado en %ProgramData%\NuGet\NuGetDefaults.Config. Si este archivo de configuración especifica orígenes de paquete, el origen predeterminado del paquete nuget.org no se registrará automáticamente y los orígenes de paquete dentro de NuGetDefaults.Config se registrarán en su lugar.

Aunque no es necesario usar esta característica, esperamos que las empresas implementen NuGetDefaults.Config archivos mediante la directiva de grupo.

Tenga en cuenta que esta característica nunca hará que una fuente de paquetes se quite de la configuración de NuGet de un desarrollador. Esto significa que si el desarrollador ya ha usado NuGet y, por lo tanto, tiene registrado el origen del paquete nuget.org, no se quitará después de la creación de un NuGetDefaults.Config archivo.

Consulte Valores predeterminados de configuración de NuGet para obtener más información sobre esta característica.

Cambiar el nombre del origen del paquete predeterminado

NuGet siempre ha registrado un origen de paquete predeterminado denominado "origen de paquete oficial de NuGet" que apunta a nuget.org. Ese nombre era detallado y tampoco especificó dónde apuntaba realmente. Para solucionar estos dos problemas, hemos cambiado el nombre de este origen de paquete a simplemente "nuget.org" en la interfaz de usuario. La dirección URL del origen del paquete también se cambió para incluir el prefijo "www". Después de usar NuGet 2.7, el origen del paquete oficial de NuGet existente se actualizará automáticamente a "nuget.org" como su nombre y "https://www.nuget.org/api/v2/" como dirección URL.

Mejoras de rendimiento

Hemos realizado una mejora del rendimiento en la versión 2.7, lo que producirá una superficie de memoria más pequeña, menos uso de disco y una instalación de paquetes más rápida. También hemos realizado consultas más inteligentes en fuentes basadas en OData, lo que reducirá la carga general.

Nuevas API de extensibilidad

Hemos agregado algunas API nuevas a nuestros servicios de extensibilidad para llenar la brecha de funcionalidades que faltan en las versiones anteriores.

IVsPackageInstallerServices

// Checks if a NuGet package with the specified Id and version is installed in the specified project.
bool IsPackageInstalledEx(Project project, string id, string versionString);

// Get the list of NuGet packages installed in the specified project.
IEnumerable<IVsPackageMetadata> GetInstalledPackages(Project project);

IVsPackageInstaller

// Installs one or more packages that exist on disk in a folder defined in the registry.
void InstallPackagesFromRegistryRepository(string keyName, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);

// Installs one or more packages that are embedded in a Visual Studio Extension Package.
void InstallPackagesFromVSExtensionRepository(string extensionId, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);

Dependencias Solo para Desarrollo

Esta característica fue aportada por Adam Ralph y permite a los autores de paquetes declarar dependencias que solo se usaron en tiempo de desarrollo y no requieren dependencias de paquete. Al agregar un developmentDependency="true" atributo a un paquete en packages.config, nuget.exe pack ya no incluirá ese paquete como dependencia.

Se ha quitado la compatibilidad con Visual Studio 2010 Express para Windows Phone

El nuevo modelo de restauración de paquetes en 2.7 se implementa mediante un nuevo VSPackage que es diferente del VSPackage principal de NuGet. Debido a un problema técnico, este nuevo VSPackage no funciona correctamente en la SKU de Visual Studio 2010 Express para Windows Phone , ya que compartimos la misma base de código con otras SKU de Visual Studio compatibles. Por lo tanto, a partir de NuGet 2.7, vamos a quitar la compatibilidad con Visual Studio 2010 Express para Windows Phone desde la extensión publicada. La compatibilidad con Visual Studio 2010 Express para Web todavía se incluye en la extensión principal publicada en la Galería de extensiones de Visual Studio.

Puesto que no estamos seguros de cuántos desarrolladores siguen usando NuGet en esa versión o edición de Visual Studio, estamos publicando una extensión de Visual Studio independiente específicamente para esos usuarios y publicarla en CodePlex (en lugar de en la Galería de extensiones de Visual Studio). No tenemos previsto seguir manteniendo esa extensión, pero si esto le afecta, háganoslo saber mediante la presentación de un problema en CodePlex.

Para descargar el Administrador de paquetes NuGet (para Visual Studio 2010 Express para Windows Phone), visite la [NuGet 2.7 Downloads](https://nuget.codeplex.com/releases/view/107605) página.

Correcciones de errores

Además de estas características, esta versión de NuGet también incluye muchas otras correcciones de errores. En la versión se han solucionado 97 problemas totales. Para obtener una lista completa de los elementos de trabajo fijos en NuGet 2.7, vea .[NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.7&status=all)

  • Last updated on