tricks - ¿Cómo compartes las dependencias externas entre las soluciones de Visual Studio?

visual studio code highlight closing tag

Question

Tengo experiencia en Java, así que 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 aún no he encontrado una buena forma de administrar todas estas dependencias externas.

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

Me di cuenta de que una solución podría ser incluir las bibliotecas externas en un "proyecto de biblioteca" que se incluye en todas las soluciones y dejar que los otros proyectos las hagan referencia a través de ellas. (O simplemente asegúrese de hacer referencia a los dll externos desde el mismo lugar para todos los proyectos).

¿Pero hay alguna forma mejor de hacer esto? (Preferiblemente utilizando algún tipo de complemento para Visual Studio).

Miré el Visual Studio Dependency Manager y parece una combinación perfecta, pero ¿alguien lo ha probado de verdad? También he visto los puertos .NET de Maven, pero desafortunadamente no estaba muy impresionado por el estado de esos. (Pero, por favor, acércate y recomiéndalos a cualquiera si crees que debería volver a intentarlo).

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

Actualizar:

Me di cuenta de que necesitaba explicar lo que quería decir con el enlace al mismo conjunto de dll .

Una de las cosas que trato 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 siguiente 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 antes de que existieran herramientas como NuGet o OpenWrap . Si alguien está dispuesto a proporcionar una información más actualizada, siga adelante y cambiaré la respuesta aceptada.

Answer 1

1. Encuentra un lugar para almacenar los ensamblajes. Por ejemplo, almaceno los ensamblajes de núcleo .Net de esta manera:

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

2. Use la propiedad ReferencePath en MSBuild (o AdditionalReferencePath en Team Build) para apuntar sus proyectos a las rutas apropiadas. Para simplificar y facilitar el mantenimiento, tengo el archivo 1 * .targets que conoce todos los directorios; todos mis proyectos Importar ese archivo.

3. Asegúrese de que su estrategia de control de versiones (bifurcaciones, fusiones, asignaciones de servidores <-> locales) mantenga constantes las rutas relativas entre sus proyectos y sus rutas de referencia.

EDITAR

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

4) Asegúrese de que cada referencia de ensamblado en cada archivo de proyecto use el nombre 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>

Bueno:

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

Ventajas del último formato:

• El uso de HintPath en un entorno de desarrollo colaborativo conducirá inevitablemente a situaciones en las que "funciona para mí", pero no a otras. Especialmente su servidor de compilación. Omitirlo obliga a que sus rutas de referencia sean correctas o no se compilará.
• Usar un nombre débil invita a la posibilidad de "DLL hell." Una vez que usa nombres fuertes, es seguro tener múltiples versiones del mismo ensamblado en sus rutas de referencia porque el enlazador solo cargará las que coincidan con cada criterio. Además, si decide actualizar algunos ensambles (en lugar de agregar copias), se le notificará cualquier cambio de rotura en el momento de la compilación en lugar de cada vez que los errores comienzan a aparecer .

Answer 2

Agregando a lo que todos los demás dicen, básicamente se reduce a dos cosas:

1. Asegurándose de que todos los desarrolladores tengan las mismas versiones de bibliotecas externas
2. Asegurándose 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 # 2. Si está utilizando msbuild en su proceso de compilación (en nuestro caso, estamos usando CruiseControl en lugar de MS Team Build), también puede pasarle 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 demasiado exagerada para la mayoría de los propósitos.

Answer 3

Normalmente tengo una estructura de carpetas separada en el control de origen para extrenal o dependencias internas, y estos filtros tienen los ensamblados según el número de compilación o versión, por ejemplo

public / External / libraries / Nunit / 2.6 /

o

Public / Internal / libraries / Logger / 5.4.312 /

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