projects and solutions - visual - NuGet y múltiples soluciones
nuget package manager visual studio mac (4)
Tenemos dos soluciones: foo.sln y bar.sln
Tengo una biblioteca común que es utilizada tanto por foo como por barra. Common.csproj es utilizado por ambos.
Si abro foo y actualizo nuget references, todas las referencias en Common.csproj apuntan a foo / packages /. Si más tarde abro la barra y actualizo las referencias nuget, todas las referencias se configuran a aquellas en bar / packages /. Naturalmente, esto molesta al equipo foo ya que puede causar incompatibilidades entre Common.csproj y cosas específicas de Foo como Foo.Data.csproj, que aún apunta a foo / packages.
Debe haber alguna solución obvia que no sea: "cree una gran solución que contenga todos sus proyectos, y si necesita tocar nuget, solo hágalo desde esa solución".
Parece que hay un problema en codeplex , (el tema más votado, por cierto), pero evidentemente soy demasiado grueso para entender cómo se resuelve este problema. ¿Alguien puede explicar cómo arreglar esto?
¿Por qué no tener common.csproj como un ensamblado separado al que hace referencia y tiene sus propias dependencias en lugar de las de la solución?
Al hacer esto, protege los valores comunes de cualquier foo o barra actualizando el paquete al que se hace referencia y rompiéndolo.
Arreglo el problema cambiando la ruta de sugerencia en el proyecto fil para que contenga la variable $ (SolutionDir):
Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<HintPath>$(SolutionDir)packages/EntityFramework.6.1.3/lib/net40/EntityFramework.dll</HintPath>
En nuestro caso, muchos desarrolladores y soluciones con tfs, y sus múltiples versiones en diferentes ramas ... y cada desarrollador entiende dónde debe estar la fuente.
La ruta relativa en este caso no funciona, las rutas absolutas en caso de disco de coincidencia se reemplazan por relativa y tampoco funcionó.
Nuestra solución consiste en deshacernos de la ruta relativa. Puede hacerlo si coloca NuGetPackages en un disco aparte . al igual que:
net use /persistent:yes p: //localhost/C$/NuGetPackagesDiskFolder
Cualquier nombre de carpeta que no quieras
Después de eso, puede especificar una ruta realmente absoluta en NuGet.Config
<config>
<add key="repositorypath" value="p:/NuGetPackages" />
</config>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>
Después de todo eliminar los archivos suo
pd: un pequeño problema con la alteración de las soluciones existentes, si viven en control de fuente de la manera más fácil es corregir la ruta a p: / NuGetPackages en cada .csproj. De lo contrario, es necesario reinstalar todos los refs y deshacer manualmente todos los packages.config marcado como eliminado en el control de fuente
Este problema precede NuGet. Si tiene un proyecto al que se hace referencia en dos soluciones y cambia las referencias de ensamblaje en el proyecto cuando está abierto en una solución, por supuesto cambiará la ruta de referencia para ese proyecto cuando esté abierto en la otra solución. Este siempre ha sido el caso, independientemente de cómo se haya cambiado la referencia (con NuGet o de otro modo).
Pero el verdadero problema es que cuando haces una actualización, los paquetes actualizados no aparecen en el directorio foo / packages ¿verdad?
La solución simple es mover Common.csproj a una solución propia, con sus propias referencias, carpeta de paquetes, proceso de compilación y lanzamiento. A continuación, cree un paquete NuGet propio con las dependencias pertinentes integradas en él. Luego puede instalar su paquete Común en Foo y Bar y luego el equipo de Foo puede actualizar libremente a la última versión de Common cuando estén listos.
El argumento principal que he escuchado en contra de esto es que es posible que desee pasar por el código común durante la depuración, pero esto ya no es un problema con Visual Studio 2010.
La pregunta fundamental que debe hacerse es ¿a quién pertenece Common.csproj? ¿Es el equipo Foo o el equipo Bar?