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.
Nos gustaría agradecer a los siguientes colaboradores externos sus contribuciones significativas a NuGet 2.7:
[Mike Roth](http://www.codeplex.com/site/users/view/mxrss)
(@mxrss)- Mostrar la dirección URL de licencia al enumerar paquetes e indicar nivel de detalle.
[Adam Ralph](http://www.codeplex.com/site/users/view/adamralph)
(@adamralph)[#1956](http://nuget.codeplex.com/workitem/1956)
: adición del atributo developmentDependency apackages.config
y uso en el comando pack para incluir solo paquetes en tiempo de ejecución
[Rafael Nicoletti](http://www.codeplex.com/site/users/view/tkrafael)
(@tkrafael)- Evitar la clave Properties duplicada en el comando pack de nuget.exe.
[Ben Phegan](http://www.codeplex.com/site/users/view/benphegan)
(@BenPhegan)[#2610](http://nuget.codeplex.com/workitem/2610)
: aumento del tamaño de caché de la máquina a 200.
[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 NuGet en el que se mostraban las actualizaciones en la pestaña incorrecta- La corrección Project.TargetFramework puede ser null en ProjectManager
[#3248](http://nuget.codeplex.com/workitem/3248)
: se ha corregido el error de SharedPackageRepository FindPackage/FindPackagesById en un valor packageId no existente
[Kevin Boyle](http://www.codeplex.com/site/users/view/KevinBoyleRG)
(@kevfromireland)[#3234](http://nuget.codeplex.com/workitem/3234)
: habilitación de la compatibilidad con el proyecto Nomad
[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.
[Martin Veselý](http://www.codeplex.com/site/users/view/veselkamartin)
[#3226](http://nuget.codeplex.com/workitem/3226)
: se ha corregido un error con el comando Add-BindingRedirect cuando un proyecto hace referencia a un proyecto de base de datos.
[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 incorrectamente los caracteres comodín en el atributo "exclude".
[Justin Dearing](http://www.codeplex.com/site/users/view/zippy1981)
(@zippy1981)[#3307](http://nuget.codeplex.com/workitem/3307)
: se ha corregido el error deNuGet.targets
de no pasar $(Platform) a nuget.exe al restaurar paquetes.
[Brian Federici](http://www.codeplex.com/site/users/view/benerdin)
[#3294](http://nuget.codeplex.com/workitem/3294)
: se ha corregido un error en el comando package de nuget.exe que permitía agregar archivos con el mismo nombre pero diferentes mayúsculas y minúsculas, lo que finalmente provocaba la excepción "Item already exists".
[Daniel Cazzulino](http://www.codeplex.com/site/users/view/dcazzulino)
(@kzu)[#2990](http://nuget.codeplex.com/workitem/2990)
: se ha agregado la propiedad Version a la clase NetPortableProfile.
[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
[Michael Friis](https://www.codeplex.com/site/users/view/friism)
(@friism)[#3278](https://nuget.codeplex.com/workitem/3278)
: se ha corregido el archivo de destinos NuGet.Build para que funcione correctamente en MonoDevelop
[Pranav Krishnamoorthy](https://www.codeplex.com/site/users/view/pranavkm)
(@pranav_km)- Mejora del rendimiento del comando Restore aumentando la paralelización
En NuGet 2.7 se presenta un nuevo enfoque para la restauración de paquetes y también se 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 descargara los paquetes que faltaban durante la compilación. Si no se hubiera concedido explícitamente este consentimiento, las soluciones que tenían habilitada la restauración de paquetes no se generarían 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 deseas, 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 nuget.exe
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 de forma explícita 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 ofrece algunas ventajas significativas:
- No es necesario usar el gesto "Habilitar restauración de paquetes NuGet" en la solución
- 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
- Todos los paquetes NuGet, incluidos los que incluyen importaciones de MSBuild para archivos de propiedades o destinos, 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 acción:
- Omisión de la carpeta
packages
Hay varias maneras de omitir la carpeta packages
del control de código fuente. Para más información, vea el tema Paquetes y control de código fuente.
Aunque todos los usuarios participan implícitamente en el consentimiento de restauración automática de paquetes, puede rechazarlo fácilmente en la configuración del Administrador de paquetes en Visual Studio.
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, y acepta 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):
- nuget.exe restore MySolution.sln
- nuget.exe restore .
- nuget.exe restore
El comando Restore abrirá el archivo de solución y buscará todos los proyectos dentro de la solución. Desde allí, encontrará los archivos packages.config
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 archivo .nuget\packages.config
. Puede encontrar más información sobre el nuevo comando Restore en la Referencia de la línea de comandos.
Estamos emocionados por estos cambios en la restauración de paquetes, ya que presenta un nuevo flujo de trabajo. Si quiere omitir los paquetes del control de código fuente, simplemente no inserte la carpeta packages
. Los usuarios de Visual Studio que abran y compilen 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 el gesto "Habilitar restauración de paquetes NuGet" en la solución, ni tampoco modificar los proyectos para cambiar la compilación. Y esto también ofrece una experiencia mejorada para los paquetes que incluyen importaciones de MSBuild, especialmente para las agregadas mediante la característica reciente de NuGet para importar automáticamente archivos de propiedades o destinos desde la carpeta \build.
Además de nuestro propio trabajo, también colaboramos con algunos asociados importantes para precisar este nuevo enfoque. Aún no tenemos escalas de tiempo concretas, pero cada asociado comparte nuestro mismo entusiasmo sobre el nuevo enfoque.
- Team Foundation Service: trabajan para integrar la llamada a
nuget.exe restore
en escenarios de compilación predeterminados. - Sitios web de Windows Azure: trabajan para permitirle insertar el proyecto en Azure y hacer que se llame a
nuget.exe restore
antes de crear el sitio web. - TeamCity: van a actualizar su complemento del instalador de NuGet para TeamCity 8.x
- AppHarbor: trabajan para permitirle insertar el repositorio en AppHarbor y hacer que se llame a
nuget.exe restore
antes de compilar la solución.
Cada uno de los asociados anteriores usará su propia copia de nuget.exe y no tendrá que incluirlo en la solución.
Hubo dos problemas conocidos con la restauración de nuget.exe en la versión 2.7 inicial, pero se corrigieron el 6/9/2013 con una actualización del 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. La ejecución de nuget.exe update -self
se actualizará a la versión más reciente.
Se ha corregido lo siguiente:
[New package restore doesn't work on Mono when using SLN file](https://nuget.codeplex.com/workitem/3596)
[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 ha corregido en NuGet 2.7.1.
Muchas veces después de cambiar el destino de un proyecto o actualizarlo, descubre que algunos paquetes NuGet no funcionan correctamente. Desafortunadamente, no hay ninguna indicación de esto ni instrucciones sobre cómo solucionarlo. Con NuGet 2.7, ahora se usan algunos eventos de Visual Studio para reconocer cuándo se ha cambiado el destino del proyecto o se ha actualizado de una forma que afecte a los paquetes NuGet instalados.
Si se detecta que cualquiera de los paquetes se ha visto afectado por el cambio de destino o la actualización, se generan errores de compilación inmediatos para notificárselo. Además del error de compilación inmediato, también se conserva una marca requireReinstallation="true"
en el archivo packages.config
para todos los paquetes afectados por el cambio de destino y en cada compilación posterior en Visual Studio se generarán 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 se trabaja en la documentación de instrucciones de reinstalación de paquetes a la que estos mensajes de error le dirigen.
Muchas empresas usan NuGet de forma interna, pero han tenido dificultades para guiar a sus desarrolladores a usar orígenes de paquetes internos en lugar de nuget.org. En NuGet 2.7 se presenta una característica de valores predeterminados de configuración que permite especificar valores predeterminados de toda la máquina para lo siguiente:
- Orígenes de paquetes habilitados
- Orígenes de paquetes registrados, pero deshabilitados
- Origen de inserción predeterminado de nuget.exe
Ahora todos se pueden 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, en su lugar, se registrarán los de NuGetDefaults.Config
.
Aunque no es necesario usar esta característica, esperamos que las empresas implementen archivos NuGetDefaults.Config
mediante la directiva de grupo.
Tenga en cuenta que esta característica nunca hará que un origen de paquete se quite de la configuración de NuGet de un desarrollador. Esto significa que si el desarrollador ya ha usado NuGet y, por tanto, tiene registrado el origen del paquete de nuget.org, no se eliminará después de la creación de un archivo NuGetDefaults.Config
.
Para más información sobre esta característica, vea Valores predeterminados de configuración de NuGet.
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 especificaba a dónde apuntaba realmente. Para solucionar estos dos problemas, se ha cambiado el nombre de este origen de paquete a simplemente "nuget.org" en la interfaz de usuario. La URL del origen del paquete también se ha cambiado 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 nombre y a "https://www.nuget.org/api/v2/" como URL.
Se ha realizado una mejora del rendimiento en la versión 2.7, lo que generará una superficie de memoria más pequeña, menos uso de disco y una instalación de paquetes más rápida. También se han realizado consultas más inteligentes en fuentes basadas en OData, lo que reducirá la carga general.
Se han agregado algunas API nuevas a los servicios de extensibilidad para solucionar la ausencia de funcionalidades que faltaban en las versiones anteriores.
// 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);
// 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);
Esta característica fue una aportación de Adam Ralph y permite a los creadores de paquetes declarar dependencias que solo se han usado en tiempo de desarrollo y no necesitan dependencias de paquete. Al agregar un atributo developmentDependency="true"
a un paquete en packages.config
, nuget.exe pack
ya no incluirá ese paquete como dependencia.
El nuevo modelo de restauración de paquetes de la versión 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 Visual Studio 2010 Express para Windows Phone, ya que se comparte la misma base de código con otras SKU de Visual Studio compatibles. Por tanto, a partir de NuGet 2.7, se quitará la compatibilidad con Visual Studio 2010 Express para Windows Phone de 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.
Como no estamos seguros de cuántos desarrolladores siguen usando NuGet en esa versión o edición de Visual Studio, se va a publicar una extensión de Visual Studio independiente específicamente para esos usuarios en CodePlex (en lugar de la Galería de extensiones de Visual Studio). No está previsto seguir manteniendo esa extensión, pero si esto le afecta, háganoslo saber mediante la presentación de un problema en CodePlex.
A fin de descargar el Administrador de paquetes NuGet (para Visual Studio 2010 Express para Windows Phone), visite la página [NuGet 2.7 Downloads](https://nuget.codeplex.com/releases/view/107605)
.
Además de estas características, en esta versión de NuGet también se incluyen muchas otras correcciones de errores. En la versión se han solucionado un total de 97 problemas. Para obtener una lista completa de los elementos de trabajo corregidos en NuGet 2.7, vea [NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.7&status=all)
.