¿Cuál es la mejor manera de tratar con dlls compartidos en C#?

Question

En mi equipo tenemos cientos de dlls compartidos, que muchos también hacen referencia a otros dlls que se refieren a otros dlls, y así sucesivamente. Hemos comenzado a utilizar un directorio "Compartido" para todos los dlls que creemos que son lo suficientemente genéricos como para usarlos en otros proyectos, como una base de datos comm dll.

El problema es que si se cambia uno de los dlls a lo largo del árbol, entonces todo lo que lo haga debe ser recompilado para evitar problemas de versiones (que ocurren en tiempo de ejecución).

Para evitar esto, ahora se habla de agregar todos nuestros dlls "compartidos" en un gran ensamblado, y cualquiera que cree nuevas aplicaciones simplemente hace referencia a eso, y solo a eso.

Esto, obviamente, se hará cada vez más grande y no estoy seguro si esta es la mejor manera o no. ¿Alguna idea, por favor?

Answer 1

Definitivamente no es la mejor manera de hacerlo. Tengo algunos archivos DLL "compartidos" en mi trabajo que son algo así. Se vuelven complicados y difíciles (léase: imposible) para realizar cambios significativos porque es muy difícil garantizar que los cambios no rompan las aplicaciones en sentido descendente, lo que parece ser exactamente lo contrario de lo que estás tratando de hacer.

Parece que lo que realmente necesita hacer es separar sus preocupaciones un poco mejor. Si todos estos archivos DLL se están haciendo referencia entre sí, probablemente estén demasiado unidos. Una verdadera DLL "compartida" debería ser capaz de sostenerse por sí misma, o como parte de un paquete de tres o cuatro que viajan en grupo. Si sus dependencias realmente le impiden realizar cambios, entonces su estrategia de acoplamiento ha sido terriblemente incorrecta.

Poner todo en una gran DLL ciertamente no va a hacer nada mejor. De hecho, probablemente todo lo contrario. Una vez que tenga todo en una DLL, la tentación estará allí para unir todo dentro de ella aún más estrechamente, lo que hará que sea imposible separar las cosas más tarde.

Answer 2

Lo que hacemos es tratar el mantenimiento de las DLL compartidas como un proyecto en sí mismo, con su propio control de fuente y todo. Luego, aproximadamente dos veces al año, hacemos una 'versión' de los archivos DLL compartidos al público, con su propio número de versión y todo. Siempre y cuando siempre use los archivos DLL como un 'conjunto' (lo que significa que todos los que hace referencia son de la misma versión), se garantiza que no tendrá ningún problema de dependencia.

Answer 3

puede hacer una solución que incluya todos los proyectos conectados.
y cuando se necesita soltar, simplemente construir esta solución

---

actualización.
Como dices, la solución no puede contener tanto dlls.
En otro lado se puede hacer una externa MSBuild guión o usando CruiseControl.NET que tienen posibilidades de hacer este tipo de tareas complicadas.

Answer 4

Para citar del libro de GoF, "Programa en una interfaz, no en una implementación". Esto podría aplicarse aquí a algunas de sus bibliotecas. Ya conoces cuán frágil se vuelve tu desarrollo cuando tienes un acoplamiento fuerte. Ahora lo que debe abordarse es cómo darle espacio para respirar.

• Puede crear una interfaz. Esto proporcionará un contrato que cualquier aplicación puede usar para especificar que un conjunto mínimo de funcionalidades esté disponible.

• Puede crear un servicio que implemente una interfaz. Esto le permitirá proporcionar lo que se consideraría un complemento o un complemento. Esto le permite diseñar una versión de contrato con expectativas de que sus herramientas se ajusten.

• Puede crear un servicio que solo utilice una interfaz. Esto permitirá que su aplicación envíe una implementación concreta que cumpla con un contrato de diseño.

Productos como los editores de desarrollo y los navegadores web utilizan este enfoque para hacer posible un poco de reutilización de código. Gracias. Buen día.

Design Principles from Design Patterns

Plugin