2011-09-15 22 views
38

Tenemos dos soluciones: foo.sln y bar.slnNuGet y múltiples soluciones

que tienen una biblioteca común que se utiliza por tanto foo y bar. 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: "crea una gran solución que contenga todos tus proyectos, y si necesitas tocar nuget, solo hazlo desde esa solución".

Parece haber un issue on codeplex, (el tema más votado, por cierto), pero evidentemente soy demasiado grueso para comprender cómo se resuelve este problema. ¿Alguien puede explicar cómo arreglar esto?

+0

Me pregunto si esto se ha convertido repentinamente en un problema, ya que lo he estado haciendo durante meses sin tener problemas, hubo una actualización ayer y de repente ambos nos topamos con ella en 24 horas. O tal vez es una coincidencia. – GraemeF

+5

También vea http://stackoverflow.com/questions/6277925/nu-get-issue-with-project-level-dependences-for-projects-referenced-by-multipl/7908976#7908976. Describe cómo cambiar la configuración para especificar dónde la solución almacenará sus archivos. Si señala todas las soluciones en el mismo directorio, la ruta de acceso debe ser correcta independientemente de la solución que utilice. –

+1

@ReedRector, debe poner el enlace como una respuesta, no solo como comentario. –

Respuesta

1

¿Por qué no han common.csproj como un conjunto separado que se hace referencia y tiene sus propias dependencias en lugar de los de la solución en su.

Haciendo que proteja común de cualquiera de foo bar o actualizar el paquete que se hace referencia y rompiéndolo

32

Este problema es anterior a 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 problema real es que cuando haces una actualización, los paquetes actualizados no aparecen en el directorio foo/packages ¿no?

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 principal argumento que he escuchado en contra de esto es que es posible que desee recorrer el código común durante la depuración, pero esto ya no es un problema con Visual Studio 2010.

La cuestión fundamental que hay que preguntarse ¿A quién pertenece Common.csproj? ¿Es el equipo Foo o el equipo Bar?

+1

Esta es la mejor respuesta que he visto para explicar esto. Si pudiera votar esto diez veces, lo haría – ferventcoder

+0

+1 Simplemente me encontré con esta situación exacta y es probable que pase a esta solución (postergando un tiempo). – Sumo

+8

También descubrí que NuGet 2.1 puede resolver este problema. http://docs.nuget.org/docs/release-notes/nuget-2.1#Specify_%e2%80%98packages%e2%80%99_Folder_Location – Sumo

1

En nuestro caso, muchos desarrolladores y soluciones con tfs, y sus versiones múltiples en diferentes ramas ... y cada desarrollador desarrollan su comprensión de dónde debe estar la fuente.

La ruta relativa en este caso no funciona, las rutas absolutas en caso de coincidencia del disco se reemplazan por relativa y tampoco funcionó.

Nuestra solución consiste en deshacernos de la ruta relativa. Puede hacerlo si pone NuGetPackages en un disco diferente. así:

net use /persistent:yes p: \\localhost\C$\NuGetPackagesDiskFolder 

Cualquier nombre de la carpeta te planteo
Después de eso, se puede especificar la ruta realmente absoluta en el NuGet.Config

<config> 
<add key="repositorypath" value="p:\NuGetPackages" /> 
</config> 
<packageRestore> 
<add key="enabled" value="True" /> 
</packageRestore> 

Después de todo eliminar archivos suo

ps: Será un pequeño problema con la alteración de las soluciones existentes, si viven en sourcecontrol la forma más fácil es corregir la ruta a p: \ NuGetPackages en cada .csproj De lo contrario, es necesario volver a instalar todos los refs y deshacer manualmente todos los paquetes. Configuró marcado como eliminado en el control de origen

3

Resuelvo el problema cambiando la ruta de sugerencia en el archivo fil para contener 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> 
Cuestiones relacionadas