¿Cómo comparte dependencias externas entre las soluciones de Visual Studio?

Question

Tengo un fondo de Java, así que & # 8217; estoy acostumbrado a que Maven maneje todos los problemas relacionados con la descarga y el mantenimiento de las dependencias actualizadas. Pero en el entorno .NET todavía no he encontrado una buena manera de administrar todas estas dependencias externas.

El principal problema aquí es que produzco soluciones en masa y todas ellas tienden a depender del mismo dll de terceros & # 8217; s. Pero no quiero & # 8217; no quiero mantener copias separadas de cada componente debajo de cada solución. Entonces, necesito una forma de vincular todas las diferentes soluciones al mismo conjunto de dll & # 8217; s.

Me di cuenta de que una solución podría ser incluir las bibliotecas externas en un & # 8221; proyecto de biblioteca & # 8221; eso está incluido en todas las soluciones y deja que los otros proyectos los hagan referencia a través de él. (O simplemente asegúrese de hacer referencia a los dll externos & # 8217; s desde el mismo lugar para todos los proyectos).

¿Pero hay mejores formas de hacer esto? (Preferiblemente usando algún tipo de complemento para Visual Studio).

I & # 8217; he visto el Visual Studio Dependency Manager y parece un perfecto partido, pero ¿alguien lo ha probado de verdad? & # 8217; también he visto los puertos .NET de Maven, pero desafortunadamente no me impresionó demasiado el estado de esos. (Pero continúe y recomiéndelos a todos si cree que debería intentarlos nuevamente).

Entonces, ¿cuál sería la forma más inteligente de abordar este problema?

Actualización:

Me di cuenta de que necesitaba explicar lo que quise decir con vinculación al mismo conjunto de dll & # 8217; s .

Una de las cosas que estoy tratando de lograr aquí es evitar que las diferentes soluciones hagan referencia a diferentes versiones de cada componente. Si actualizo un componente a una nueva versión, debería actualizarse para todas las soluciones en la próxima compilación. Esto me obligaría a asegurarme de que todas las soluciones estén actualizadas con los últimos componentes.

Actualización 2: Tenga en cuenta que esta es una vieja pregunta que se hizo antes de herramientas como NuGet o OpenWrap existía. Si alguien está dispuesto a proporcionar una información más actualizada, continúe y cambiaré la respuesta aceptada.

Answer 1

1. Encuentre un lugar para almacenar los ensamblajes. Por ejemplo, almaceno los ensamblados de núcleo .Net así:

   • <branch > \ NetFX \ 2.0527 \ *
   • <=> > \ NetFX \ 3.0 <=> *
   • <=> > \ NetFX \ 3.5 <=> *
   • <=> > \ NetFX \ Silverlight 2 <=> *
   • <=> > \ NetFX \ Silverlight 3 <=> *

2. Use la propiedad ReferencePath en MSBuild (o AdditionalReferencePath en Team Build) para apuntar sus proyectos a las rutas apropiadas. Por simplicidad y fácil mantenimiento, tengo un archivo 1 * .targets que conoce cada directorio; todos mis proyectos Importar ese archivo.

3. Asegúrese de que su estrategia de control de versiones (bifurcación, fusión, local < - > asignaciones de servidor) mantenga las rutas relativas entre sus proyectos & amp; sus rutas de referencia constantes.

EDITAR

En respuesta a la actualización en la pregunta, permítame agregar un paso más:

4) Asegúrese de que cada referencia de ensamblaje en cada archivo de proyecto utilice el nombre seguro completo de .Net y nada más .

Malo:

<Reference Include="Microsoft.SqlServer.Smo">
  <SpecificVersion`>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath>
</Reference>

Bien:

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />

Ventajas del último formato:

• El uso de un HintPath en un entorno de desarrollo colaborativo inevitablemente conducirá a situaciones en las que " funciona para mí " Pero no otros. Especialmente su servidor de compilación. Omitirlo te obliga a obtener tus rutas de referencia correctas o no se compilará.
• El uso de un nombre débil invita a la posibilidad de " DLL hell. " Una vez que use nombres seguros, es seguro tener múltiples versiones del mismo ensamblaje en sus rutas de referencia porque el enlazador solo cargará las que coincidan con cada criterio. Además, si decide actualizar algunos ensamblajes en su lugar (en lugar de agregar copias), se le notificará de cualquier cambio importante en el momento de la compilación en lugar de cada vez que comiencen los errores.

Answer 2

Además de lo que todos dicen, básicamente se reduce a dos cosas:

1. Asegurarse de que todos los desarrolladores tengan las mismas versiones de bibliotecas externas
2. Asegurarse de que todos los desarrolladores tengan las bibliotecas externas ubicadas en el mismo lugar (al menos, en relación con el código fuente)

Como señala Richard Berg, puede usar ReferencePath y / o AdditionalReferencePath para ayudar a resolver el n. ° 2. Si está utilizando msbuild en su proceso de compilación (en nuestro caso, estamos utilizando CruiseControl en lugar de MS Team Build), también puede pasar ReferencePath en la línea de comando. Para resolver el n. ° 1, he encontrado que svn: externals es útil (si está utilizando SVN).

Mi experiencia con Maven es que es excesivo para la mayoría de los propósitos.

Answer 3

Por lo general, tengo una estructura de carpetas separada en el control de origen para dependencias externas o internas, y estos rellenos tienen los ensamblados de acuerdo con el número de versión o de compilación, por ejemplo

public \ External \ bibliotecas \ Nunit \ 2.6 \

o

Público \ Interno \ bibliotecas \ Logger \ 5.4.312 \

y dentro de las soluciones, todos los proyectos que necesitan usar cualquiera de las dependencias solo agregan una referencia a los ensamblados en las carpetas públicas internas o externas.