Configurar una carpeta de paquetes nuget común para todas las soluciones cuando algunos proyectos se incluyen en varias soluciones

He estado usando NuGet para recuperar paquetes de fuentes de paquetes externas e internas, lo cual es muy conveniente. Pero me di cuenta de que los paquetes se almacenan por solución por defecto, lo cual es muy frustrante cuando algunos proyectos con referencias NuGet se incluyen en varias soluciones. Luego, las referencias se cambian a otra carpeta del paquete de soluciones que en realidad no está disponible para otro desarrollador o máquina de compilación.

He visto que hay formas de señalar una ubicación de paquete común (quizás en el nivel raíz del proyecto, estamos usando el control de fuente TFS) con la versión 2.1 de NuGet, vea las notas de la versión . Estoy usando NuGet v2.7

Pero he intentado agregar archivos nuget.config sin ver ningún efecto de esto. Los paquetes todavía se almacenan en la carpeta de la solución. ¿Hay algo que me haya perdido? Parece que hay diferentes estructuras del nodo xml para agregar al archivo nuget.config, dependiendo de quién responda esa pregunta: Schwarzie sugiere en otro hilo de Stackoverflow :

<settings>
  <repositoryPath>..\..\[relative or absolute path]</repositoryPath>
</settings>

Las notas de la versión de NuGet 2.1 (ver enlace anterior) sugieren este formato:

<configuration>
  <config>
    <add key="repositoryPath" value="..\..\[relative or absolute path]" />
  </config>
</configuration>

No sé cuál de estos, o ninguno, o ambos funcionarán al final. He intentado ambos a nivel de solución. ¿Se puede colocar el archivo nuget.config en el nivel raíz del proyecto TFS, o debe estar en el directorio de la solución? Parece que NuGet lee y aplica la configuración de estos archivos en un cierto orden, por lo que tendría sentido agregarlos en varios niveles, donde un archivo nuget.config en el nivel de solución anularía uno en el nivel raíz del proyecto TFS. ¿Se puede aclarar esto?

¿Debo eliminar todos los paquetes instalados antes de que esas referencias funcionen? Me encantaría que alguien pudiera proporcionar una instrucción paso a paso para pasar del uso de nuget específico de la solución a una carpeta de paquete común donde los proyectos que pertenecen a varias soluciones pueden encontrar sus paquetes nuget necesarios.

Tengo una situación similar con las fuentes de paquetes externos e internos con proyectos referenciados en más de una solución. Acabo de hacer que esto funcione con una de nuestras bases de código hoy y parece estar funcionando con las estaciones de trabajo del desarrollador y nuestro servidor de compilación. El siguiente proceso tiene este escenario en mente (aunque no debería ser difícil adaptarse para tener la carpeta de paquetes comunes en otro lugar).

• Codebase
  • Proyecto a
  • Proyecto B
  • Proyecto c
  • Soluciones
    • Solución 1
    • Solución 2
    • Solución 3
    • Paquetes (este es el común compartido por todas las soluciones)

Respuesta actualizada a partir de NuGet 3.5.0.1484 con Visual Studio 2015 Update 3

Este proceso es un poco más fácil ahora que cuando lo aborde originalmente y pensé que era hora de actualizarlo. En general, el proceso es el mismo con menos pasos. El resultado es un proceso que resuelve o proporciona lo siguiente:

• Todo lo que necesita ser comprometido con el control del código fuente es visible y rastreado en la solución
• Instalar nuevos paquetes o actualizar paquetes usando el Administrador de paquetes en Visual Studio usará la ruta correcta del repositorio
• Después de la configuración inicial, no hackear archivos .csproj
• Sin modificaciones de la estación de trabajo del desarrollador (el código está listo para construir al finalizar la compra)

Hay algunos inconvenientes potenciales a tener en cuenta (aún no los he experimentado, YMMV). Vea la respuesta y los comentarios de Benol a continuación.

Añadir NuGet.Config

Deberá crear un archivo NuGet.Config en la raíz de la carpeta \ Solutions \. Asegúrese de que este es un archivo codificado UTF-8 que cree, si no está seguro de cómo hacerlo, use el menú Archivo-> Nuevo-> Archivo de Visual Studio y luego elija la plantilla de Archivo XML. Agregue a NuGet.Config lo siguiente:

<?xml version="1.0" encoding="utf-8"?>
<configuration>  
  <config>
    <add key="repositoryPath" value="$\..\Packages" />
  </config>
</configuration>

Para la configuración repositoryPath, puede especificar una ruta absoluta o una ruta relativa (recomendado) utilizando el token $. El token $ se basa en la ubicación del NuGet.Config (el token $ en realidad es relativo a un nivel por debajo de la ubicación del NuGet.Config). Entonces, si tengo \ Solutions \ NuGet.Config y quiero \ Solutions \ Packages, necesitaría especificar $ \ .. \ Packages como el valor.

A continuación, tendrá que agregar una carpeta de soluciones a su solución llamada algo así como "NuGet" (haga clic con el botón derecho en su solución, Agregar-> Nueva carpeta de soluciones). Las carpetas de soluciones son carpetas virtuales que solo existen en la solución de Visual Studio y no crearán una carpeta real en la unidad (y puede hacer referencia a archivos desde cualquier lugar). Haga clic con el botón derecho en la carpeta de la solución "NuGet" y luego en Agregar-> Elemento existente y seleccione \ Solutions \ NuGet.Config.

La razón por la que estamos haciendo esto es para que sea visible en la solución y debería ayudar a garantizar que esté correctamente comprometida con el control de su código fuente. Es posible que desee realizar este paso para cada solución en su base de código que participa con sus proyectos compartidos.

Al colocar el archivo NuGet.Config en \ Solutions \ sobre cualquier archivo .sln, estamos aprovechando el hecho de que NuGet navegará recursivamente la estructura de carpetas hacia arriba desde el "directorio de trabajo actual" en busca de un archivo NuGet.Config para usar. El "directorio de trabajo actual" significa un par de cosas diferentes aquí, una es la ruta de ejecución de NuGet.exe y la otra es la ubicación del archivo .sln.

Cambiar su carpeta de paquetes

Primero, le recomiendo que revise cada una de las carpetas de su solución y elimine cualquier carpeta \ Paquetes \ que exista (primero deberá cerrar Visual Studio). Esto hace que sea más fácil ver dónde NuGet está colocando su carpeta \ Packages \ recién configurada y garantiza que cualquier enlace a la carpeta \ Packages \ errónea fallará y luego podrá repararse.

Abra su solución en Visual Studio y comience un Reconstruir todo. Ignore todos los errores de compilación que recibirá, esto se espera en este momento. Sin embargo, esto debería iniciar la función de restauración del paquete NuGet al comienzo del proceso de compilación. Verifique que su carpeta \ Solutions \ Packages \ se haya creado en el lugar que desee. Si no es así, revise su configuración.

Ahora, para cada proyecto en su solución, querrá:

1. Haga clic derecho en el proyecto y seleccione Descargar proyecto
2. Haga clic derecho en el proyecto y seleccione Editar your-xxx.csproj
3. Encuentre referencias a \ paquetes \ y actualícelas a la nueva ubicación.
   • La mayoría de estos serán referencias <HintPath>, pero no todas. Por ejemplo, WebGrease y Microsoft.Bcl.Build tendrán configuraciones de ruta separadas que deberán actualizarse.
4. Guarde el archivo .csproj y luego haga clic derecho en el proyecto y seleccione Actualizar proyecto

Una vez que se hayan actualizado todos sus archivos .csproj, inicie otro Reconstruir todo y no debería tener más errores de compilación sobre referencias faltantes. En este punto ya ha terminado, y ahora tiene NuGet configurado para usar una carpeta de paquetes compartidos.

A partir de NuGet 2.7.1 (2.7.40906.75) con VStudio 2012

Lo primero a tener en cuenta es que nuget.config no controla todas las configuraciones de ruta en el sistema de paquetes nuget. Esto fue particularmente confuso de entender. Específicamente, el problema es que msbuild y Visual Studio (que llaman a msbuild) no usan la ruta en nuget.config sino que la anulan en el archivo nuget.targets.

Preparación ambiental

Primero, revisaría la carpeta de su solución y eliminaría todos los \ paquetes \ carpetas que existen. Esto ayudará a garantizar que todos los paquetes se instalen visiblemente en la carpeta correcta y ayudará a descubrir cualquier referencia de ruta incorrecta en todas sus soluciones. A continuación, me aseguraría de que tenga instalada la última extensión nuget de Visual Studio. También me aseguraría de que tenga instalado el último nuget.exe en cada solución. Abra un símbolo del sistema y vaya a cada carpeta $ (SolutionDir) \ .nuget \ y ejecute el siguiente comando:

nuget update -self

Establecer una ruta de carpeta de paquete común para NuGet

Abra cada $ (SolutionDir) \ .nuget \ NuGet.Config y agregue lo siguiente dentro de la sección <configuration>:

<config>
    <add key="repositorypath" value="$\..\..\..\Packages" />
</config>

Nota: Puede usar una ruta absoluta o una ruta relativa. Tenga en cuenta que si está utilizando una ruta relativa con $ que es relativa a un nivel por debajo de la ubicación de NuGet.Config (crea que esto es un error).

Establecer una ruta de carpeta de paquete común para MSBuild y Visual Studio

Abra cada $ (SolutionDir) \ .nuget \ NuGet.targets y modifique la siguiente sección (tenga en cuenta que para los que no son Windows hay otra sección debajo):

<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
    <!-- Windows specific commands -->
    <NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
    <PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
    <PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>

Paquetes de actualizaciónDir to be

<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>

Nota: GetFullPath resolverá nuestra ruta relativa en una ruta absoluta.

Restaurar todos los paquetes nuget en una carpeta común

Abra un símbolo del sistema y vaya a cada $ (SolutionDir) \ .nuget y ejecute el siguiente comando:

nuget restore ..\YourSolution.sln

En este punto, debe tener una sola carpeta \ packages \ en su ubicación común y ninguna dentro de ninguna de las carpetas de su solución. Si no, verifique sus caminos.

Arreglando referencias de proyectos

Abra todos los archivos .csproj en un editor de texto y encuentre referencias a \ packages y actualícelos a la ruta correcta. La mayoría de estos serán referencias <HintPath>, pero no todas. Por ejemplo, WebGrease y Microsoft.Bcl.Build tendrán configuraciones de ruta separadas que deberán actualizarse.

Construye tu solución

Abra su solución en Visual Studio y comience una compilación. Si se queja de paquetes faltantes que necesitan ser restaurados, no asuma que falta el paquete y necesita ser restaurado (el error puede ser engañoso). Podría ser una mala ruta en uno de sus archivos .csproj. Verifique eso primero antes de restaurar el paquete.

¿Tiene un error de compilación sobre paquetes faltantes?

Si ya ha verificado que las rutas en sus archivos .csproj son correctas, entonces tiene dos opciones para probar. Si este es el resultado de actualizar su código desde el control del código fuente, entonces puede intentar verificar una copia limpia y luego construirla. Esto funcionó para uno de nuestros desarrolladores y creo que había un artefacto en el archivo .suo o algo similar. La otra opción es forzar manualmente la restauración de un paquete usando la línea de comando en la carpeta .nuget de la solución en cuestión:

nuget restore ..\YourSolution.sln

En lugar de establecer una ubicación de paquete común para todos los proyectos, también es posible cambiar HintPath en el proyecto de la siguiente manera:

<HintPath>$(SolutionDir)\packages\EntityFramework.6.1.0\lib\net40\EntityFramework.dll</HintPath>

En la mayoría de los casos, en el proyecto compartido solo habrá unos pocos paquetes, por lo que puede cambiarlo fácilmente.

Creo que es una mejor solución, cuando ramifica código, cuando establece un repositorio común, debe cambiar la ruta relativa, en esta solución no necesita hacer esto.

Mi experiencia probando esto con la última versión de NuGet (2.7) y VS2012:

• Elimine la carpeta .nuget (en el disco y en la solución)
• Coloque un archivo NuGet.Config en una carpeta principal común de todas las soluciones
• Eliminar cualquier carpeta de paquetes existente
• Revise todos los archivos csproj y cambie HintPaths para apuntar a la nueva ubicación
• Lucro

En mi caso, quería poner todos los paquetes .packages, por lo que mi NuGet.Config se veía a continuación.

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <config>
     <add key="repositorypath" value=".packages" />
   </config>
 </configuration>

Tenga en cuenta que hay algunas cosas 'extrañas' que pueden suceder, pero creo que son soportables:

• Si 'Actualiza' un paquete de una solución, eliminará rápidamente la versión anterior de su carpeta de paquetes (no puede saber si tiene otra solución que esté apuntando allí). Esto no me molesta mucho, ya que la otra solución simplemente se restaurará cuando sea necesario.
• Si intenta agregar el paquete con el botón derecho del mouse sobre la solución, si el paquete ya está presente en otra solución, verá que está allí y le mostrará la 'marca verde' en lugar del botón 'instalar'. Por lo general, instalo con el botón derecho del mouse sobre el proyecto, por lo que esto no me molesta en absoluto.

Descargo de responsabilidad : acabo de probar esto hoy, ¡no tengo ninguna experiencia a largo plazo para respaldarlo!

Tengo NuGet versión 2.8.50926 con VS 2013. No es necesario usar múltiples archivos nuget.config o estructuras de directorios complejas. Simplemente modifique el archivo predeterminado ubicado aquí:

%APPDATA%\Roaming\NuGet\NuGet.Config

Aquí está el contenido de mi archivo:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\Projects\nugetpackages" />
  </config>
  <activePackageSource>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </activePackageSource>
</configuration>

Por lo tanto, todos los paquetes van a la carpeta "C: \ Proyectos \ nugetpackages", sin importar dónde esté la solución.

En todas sus soluciones, simplemente elimine las carpetas existentes de "paquetes". Luego, cree su solución y NuGet restaurará automáticamente los paquetes faltantes en el nuevo directorio centralizado que especificó.

Ya no hay necesidad de modificar nuget.targets. Se ha corregido en nuget 2.8 ( http://nuget.codeplex.com/workitem/2921 ). Solo necesita establecer la ruta del repositorio.

Desde Visual Studio 2013 Update 4 y Nugget Package Manager versión> 2.8.5 ...

Cree el archivo nuget.config en la raíz del repositorio.

contenido del archivo:

<configuration>
  <config>
    <add key="repositoryPath" value="packages" />
  </config>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

Esto hará que todos los paquetes irán a la carpeta de paquetes en el nivel del archivo nuget.config de su.

Ahora puede ir a cada consola .sln nuget con el comando 'update-package -reinstall'

Si tiene múltiples repositorios en el mismo nivel y qué compartir la misma carpeta de paquetes entre ellos, intente usar una carpeta para subir.

 <add key="repositoryPath" value="..\packages" />

Pero de esta manera, hace que la referencia de paquetes nuget csproj apunte una carpeta hacia arriba fuera de la ruta de sus repositorios.

He inventado un paquete NuGet que convierte de forma transparente todas las referencias de NuGet en un proyecto a un formato relativo a $ (SolutionDir). Lo hace utilizando la transformación XSLT en tiempo de construcción, por lo que no necesita hackear su archivo de proyecto a mano. Puede actualizar sus paquetes libremente, no romperá nada.

https://www.nuget.org/packages/NugetRelativeRefs

O bien, si usa Visual Studio 2015 Update 3, puede migrar las referencias de su paquete al project.jsonformulario como se describe aquí: https://oren.codes/2016/02/08/project-json-all-the-things

Actualizando mi experiencia con nuget 2.8.3. Fue relativamente simple. Todo lo que hizo fue habilitar la restauración del paquete desde la solución de clic derecho. Editó NuGet.Config y agregó estas líneas:

  <config>
    <add key="repositorypath" value="..\Core\Packages" />
  </config>

Luego reconstruyó la solución, descargó todos los paquetes a mi carpeta deseada y actualizó las referencias automáticamente. Hice lo mismo para todos mis otros proyectos, donde solo se descargaron paquetes incrementales y se hizo referencia a los paquetes existentes. Por lo tanto, se ha establecido un repositorio de paquetes común para todos los proyectos.

Aquí hay un procedimiento paso a paso para habilitar la restauración del paquete.

http://blogs.4ward.it/enable-nuget-package-restore-in-visual-studio-and-tfs-2012-rc-to-building-windows-8-metro-apps/

Simplemente enlace / paquetes a la ubicación compartida deseada. Entonces su proyecto no se romperá para otros usuarios, que no tienen una ubicación de paquetes especiales.

Abra un símbolo del sistema como administrador y use

mklink /prefix link_path Target_file/folder_path

Para cualquier solución significativa, las respuestas anteriores se quedarán cortas. En pocas palabras, una compleja estructura de espacio de trabajo TFS con diferentes rutas relativas, ramificaciones, proyectos compartidos, etc. hacen imposible un único repositorio central.

Usar ($ SolutionDir) es un paso en la dirección correcta, pero codificar manualmente el archivo csproj con ($ SolutionDir) sería bastante tedioso en una base de código con cientos de paquetes que se actualizan regularmente (cada vez que ocurre una actualización, el HintPath se sobrescribe con Un nuevo camino relativo). ¿Qué sucede si tiene que ejecutar Update-Package -Reinstall?

Hay una gran solución llamada NugetReferenceHintPathRewrite . Automatiza la inyección de ($ SolutionDir) en los HintPaths justo antes de la compilación (sin cambiar realmente el archivo csproj). Me imagino que podría incorporarse fácilmente en sistemas de construcción automatizados

Un breve resumen para aquellos en VS 2013 profesional con NuGet Version: 2.8.60318.667

Así es como dirigiría los paquetes a una ruta relativa a la carpeta .nuget:

<configuration>
  <config>
    <add key="repositoryPath" value="../Dependencies" />
  </config>
</configuration>

Por ejemplo, si su solución (archivo .sln) reside en C: \ Projects \ MySolution, cuando habilita la restauración del paquete NuGet, la carpeta .nuget se crea así: C: \ Projects \ MySolution.nuget y los paquetes se descargarán a un directorio como este: C: \ Proyectos \ MySolution \ Dependencies

NOTA: Por alguna razón (desconocida), cada vez que actualizo el "repositoryPath", tengo que cerrar y volver a abrir la solución para que los cambios surtan efecto

para aquellos que usan paket como su administrador de paquetes, hay una opción de enlace automático para su archivo de dependencias:

storage: symlink

por cierto: paket aprovecha nuget

referencia: https://fsprojects.github.io/Paket/dependencies-file.html

Si desea modificar lo menos posible, puede limpiar los subdirectorios periódicamente con un script. es decir. El comportamiento predeterminado de Nuget es copiar archivos de una ubicación global a una carpeta de paquetes locales, de modo que elimine estos archivos después.

Solo uso las uniones NTFS para hacer que todas las carpetas de los paquetes se dirijan a una sola carpeta sobre las raíces del repositorio. Funciona genial. No hay problemas con la restauración de paquetes paralelos en múltiples soluciones. Una ventaja de esto es que no tiene que volver a configurar nada en su código fuente, como los cientos de rutas de pistas relativas en sus archivos .csproj. Simplemente funciona al permitir que el sistema de archivos maneje la redirección y la simulación de una sola carpeta de paquetes.

Solo ten cuidado con los problemas de 'git'. Aunque el 'estado de git' a través de la línea de comando no muestra cambios sin clasificar, noté que GitKraken ve la unión del 'paquete' como un archivo sin clasificar . Incluso muestra errores como 'el archivo es un directorio' cuando hace clic en él. GitKraken también intentará esconder este 'archivo' si vuelve a crear una base, destruye la unión y la restaura como un archivo real que contiene texto con la ruta del archivo original. Comportamiento muy extraño. Tal vez pueda evitarlo asegurándose de que el archivo de paquetes se agregue a su .gitignore.

Estas son las instrucciones de NuGet 2.1: http://docs.nuget.org/docs/release-notes/nuget-2.1

No es necesario editar archivos de nivel de solución.

Funciona con Visual Studio 2013 y tres proyectos de soluciones compartidas.

No olvide actualizar el nivel de solución NuGet (cada nuget.exe en las carpetas .nuget).