manejar dependencies a una DLL que cambia frecuentemente

tenemos una cantidad de proyectos de c # que dependen de una DLL común (también c #). este file DLL cambia un poco la frecuencia, ya que estamos en un entorno en el que tenemos que ser capaces de crear e implementar código actualizado con frecuencia. El problema con esto es que si una de estas actualizaciones requiere un cambio en la DLL común, terminamos con varias aplicaciones cliente que tienen versiones ligeramente diferentes de la DLL.

estamos intentando descubrir cómo mejorar esta configuration, por lo que podemos garantizar que cualquiera pueda consultar un proyecto (utilizamos SVN) y poder buildlo sin problemas. parece que labelr cada cambio de DLL a una nueva versión es excesivo, pero no estoy seguro de cuál es la solución "correcta" (o al less algo elegante).

sería ideal si cualquier solución permitiera a un desarrollador ingresar al código DLL desde Visual Studio, lo que solo parece posible si tiene el proyecto en su máquina (podría estar mal allí).

Francamente, creo que versionar tu DLL en control de fuente es la solución CORRECTA.

Es muy posible que un DLL de núcleo que cambia rápidamente pueda causar compatibilidad binaria y de origen en un proyecto de cliente. Al crear versiones, puede evitar que cada proyecto use la nueva DLL hasta que esté listo para migrar.

Esto proporciona un nivel de security: usted sabe que no romperá el proyecto de un cliente porque alguien más cambió algo debajo de usted, pero es muy fácil actualizarlo en cualquier momento a la nueva versión.

El control de versiones en SVN es trivial, así que no dejaría que esto sea un problema. También es más seguro desde una perspectiva empresarial, ya que tiene un "seguimiento en papel" muy claro de la versión que se utilizó con un entregable determinado de un proyecto de cliente, que tiene muchos beneficios en términos de facturación, seguimiento, capacidad de testing, etc.

No hay una solución fácil, y las dos respuestas anteriores son posiblemente el método más aceptado para lograr lo que desea. Si tuviera un entorno de CI y pudiera desplegar todas sus aplicaciones a pedido desde una tienda que se creó a través de CI, entonces podría evitar este problema. Eso puede ser una gran ambición, sin embargo, si hay aplicaciones antiguas allí no se rigen por las testings, etc.

Si su aplicación es .Net 3.5 (incluso podría necesitar el SP1), ¿sabía que los ensamblados que se cargan desde la networking ya no tienen restricciones de confianza? Esto significa que puede configurar una ruta de ensamblaje en las máquinas en cuestión para apuntar a una location de networking compartida, de alta disponibilidad, y hacer que todas sus aplicaciones localicen el ensamblaje desde allí.

Una alternativa a esto, pero que lograría el mismo objective, sería build un componente que se enganche en el evento AppDomain.CurrentDomain.AssemblyResolve, que se activa siempre que el time de ejecución no pueda descubrir automáticamente un ensamblado, y hacer una búsqueda manual en esa location de networking para el dll en cuestión (si tomara la parte AssemblyName del nombre completo, anexe .dll, entonces estaría reproduciendo la misma búsqueda que la carpeta .Net Fusion realiza de todos modos).

Solo un pensamiento 😉

Creo que podría beneficiarse al configurar un server de continuous integration con objectives para cada uno de los proyectos del cliente y el proyecto DLL común.

De esta forma, sabrá de inmediato cuándo los cambios en el DLL común rompen cualquiera de los proyectos del cliente. Podría networkingucir el problema de actualizar proyectos de cliente cuando cambia la interfaz DLL común. Esta solución puede ser inadecuada si su equipo de desarrollo está distribuido y es muy grande.

Sin embargo, no diría que hay una solución CORRECTA. Hay muchas forms de gestionar los problemas de dependencia.

También puedes echarle un vistazo a Maven. Le ayudará a configurar dependencies de proyectos. Sin embargo, no estoy seguro de cómo puede integrar Maven en Visual Studio. Maven le permitirá especificar en qué versión de un proyecto (en SVN) desea confiar. Los desarrolladores podrán luego verificar la versión correcta del proyecto y build sus proyectos. Maven comprobará la versión correcta de los proyectos dependientes de SVN para ellos. No he trabajado con él, pero lo usan muchos proyectos de código abierto en la comunidad de Java.