visual studio solución solucion restaurar referencia que proyecto por paquetes ningun los hace guardó guarde faltan este error equipo encuentra elemento declarado antes admitido administrar nuget nuget-package solution

studio - Configuración de una carpeta común de nuget packages para todas las soluciones cuando algunos proyectos están incluidos en múltiples soluciones



restaurar paquetes nuget visual studio 2017 (12)

He estado usando NuGet para recuperar paquetes de fuentes de paquetes externos e internos, lo cual es muy conveniente. Pero me he dado cuenta de que los paquetes están almacenados de manera predeterminada por solución, lo cual es muy frustrante cuando algunos proyectos con referencias NuGet se incluyen en varias soluciones. A continuación, las referencias se cambian a otra carpeta de paquete de soluciones que puede no estar disponible para otro desarrollador o máquina de creació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, consulte las notas de la versión . Estoy usando NuGet v2.7

Pero intenté 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 para NuGet 2.1 (ver enlace arriba) 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. ¿Puede el archivo nuget.config colocarse 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 orden determinado, 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 puedan encontrar sus paquetes nuget requeridos.

Actualizando mi experiencia con nuget 2.8.3. Fue relativamente simple. All did fue habilitada la restauración del paquete desde la opción de clic derecho. Editó NuGet.Config y agregó estas líneas:

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

Luego reconstruí 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 común de paquetes 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/

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

Crea 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 tu.

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

Si tiene varios repositorios en el mismo nivel y qué compartir con ellos en la misma carpeta de paquetes, intente usar la forma de subir una carpeta.

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

Pero de esta manera usted hace que los paquetes nuget hagan referencia a que csproj está apuntando una carpeta fuera de la ruta de los repositorios.

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 habrá pocos paquetes, por lo que puede cambiarlo fácilmente.

Creo que es una mejor solución, cuando el código de bifurcación, al establecer repos común, debe cambiar la ruta relativa, en esta solución no es necesario hacer esto.

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 soluciones para compartir proyectos.

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

He creado un paquete NuGet que convierte de forma transparente todas las referencias de NuGet en un proyecto en un formato relativo a $ (SolutionDir). Lo hace usando la transformación XSLT en tiempo de compilación, por lo que no necesita hackear el archivo del 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 sus paquetes al formulario project.json como se describe aquí: https://oren.codes/2016/02/08/project-json-all-the-things

Mi experiencia al probar 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
  • Repase todos los archivos csproj y cambie HintPaths para que apunte a la nueva ubicación
  • Lucro

En mi caso, quería poner todos los paquetes en .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 restaurará cuando sea necesario.
  • Si intenta agregar el paquete desde la opción de clic derecho en 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''. Normalmente instalo desde el clic derecho en el proyecto, por lo que esto no me molesta en absoluto.

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

Para cualquier solución significativa, las respuestas anteriores serán insuficientes. Simplemente, una estructura de espacio de trabajo TFS compleja con diferentes rutas relativas, ramificación, 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, HintPath se sobrescribe con una nueva ruta relativa). Qué sucede si tiene que ejecutar Update-Package -Reinstall.

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

Solo hardlink / packages a la ubicación compartida deseada. Entonces su proyecto no se romperá para otros usuarios, que no tienen una ubicación especial para paquetes.

Abra un símbolo del sistema como administrador y use

mklink /prefix link_path Target_file/folder_path

Tengo la versión 2.8.50926 de NuGet con VS 2013. No necesita usar múltiples archivos nuget.config, o usar estructuras complejas de directorios. Simplemente modifica el archivo predeterminado que se encuentra 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: / Projects / nugetpackages", sin importar dónde esté la solución.

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

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

  • Base de código
    • 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 Actualización 3

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

  • Todo lo que se debe comprometer con el control del código fuente es visible y se rastrea en la solución
  • La instalación de paquetes nuevos o la actualización de paquetes utilizando Package Manager en Visual Studio utilizará la ruta de depósito correcta
  • Después de la configuración inicial, no hackeo de archivos .csproj
  • Sin modificaciones de la estación de trabajo del desarrollador (Code is build ready al momento de la salida)

Hay algunas desventajas potenciales a tener en cuenta (aún no las he experimentado, YMMV). Vea Benol''s respuesta y los comentarios de Benol''s 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 sea un archivo codificado en UTF-8 que cree; si no está seguro de cómo hacerlo, use el archivo Archivo-> Nuevo-> Archivo de Visual Studio y luego elija la plantilla Archivo XML. Agregar 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 (recomendada) utilizando $ token. El $ token se basa en dónde se encuentra NuGet.Config (El $ token es en realidad relativo a un nivel debajo de la ubicación de NuGet.Config). Entonces, si tengo / Solutions / NuGet.Config y quiero / Solutions / Packages necesitaría especificar $ / .. / Packages como el valor.

A continuación, querrá agregar una solución de carpeta 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 los archivos desde cualquier lugar). Haga clic con el botón derecho en su carpeta de solución "NuGet" y luego agregue-> Artículo existente y seleccione / Soluciones / NuGet.Config.

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

Al colocar el archivo NuGet.Config en / Soluciones / sobre cualquier archivo .sln, estamos aprovechando el hecho de que NuGet navegará recursivamente la estructura de la carpeta 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.

Cambiando su carpeta de paquetes

Primero, le recomiendo que revise cada una de las carpetas de soluciones y elimine las carpetas / Packages / que existen (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 se asegura de que los enlaces a la carpeta / Packages / incorrecta fallarán y luego se podrán reparar.

Abra su solución en Visual Studio y inicie Rebuild All. Ignore todos los errores de compilación que recibirá, esto se espera en este momento. Sin embargo, esto debería iniciar la característica de restauración del paquete NuGet al inicio del proceso de compilación. Verifique que su carpeta / Solutions / Packages / se haya creado en el lugar que desea. 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 su-xxx.csproj
  3. Busque referencias a / packages / y actualícelas en la nueva ubicación.
    • La mayoría de estas serán referencias de <HintPath>, pero no todas. Por ejemplo, WebGrease y Microsoft.Bcl.Build tendrán una configuración de ruta separada que deberá actualizarse.
  4. Guarde el archivo .csproj y luego haga clic con el botón derecho en el proyecto y seleccione Recargar proyecto

Una vez que todos sus archivos .csproj se hayan actualizado, inicie nuevamente Rebuild All y no debería tener más errores de compilación sobre referencias faltantes. En este momento ya ha terminado y ahora tiene configurado NuGet para usar una carpeta compartida de Paquetes.

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 rutas en el sistema nuget package. Esto fue particularmente confuso de resolver. Específicamente, el problema es que msbuild y Visual Studio (llamando a msbuild) no usan la ruta en nuget.config, sino que la anulan en el archivo nuget.targets.

Preparación del ambiente

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 estén visiblemente instalados en la carpeta correcta y que ayuden a descubrir cualquier referencia de ruta incorrecta a lo largo de sus soluciones. A continuación, me aseguraré de que tenga instalada la última versión de Nuget Visual Studio. También me aseguraría de tener 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 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, si está utilizando una ruta relativa con $ que es relativa a un nivel debajo de la ubicación de NuGet.Config (creo que esto es un error).

Establecer 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>

Actualizar PackagesDir 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 en sus carpetas de soluciones. Si no, entonces verifica tus rutas.

Reparando referencias de proyectos

Abra cada archivo .csproj en un editor de texto y busque referencias a / packages y actualícelos en la ruta correcta. La mayoría de estas serán referencias de <HintPath>, pero no todas. Por ejemplo, WebGrease y Microsoft.Bcl.Build tendrán una configuración de ruta separada que deberá 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 el paquete falta 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 esto es el resultado de actualizar su código desde el control del código fuente, entonces puede intentar sacar una copia limpia y luego compilarla. 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 utilizando la línea de comando en la carpeta .nuget de la solución en cuestión:

nuget restore ../YourSolution.sln

Un breve resumen para aquellos profesionales de VS 2013 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 ese: C: / Projects / 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 entren en vigencia.