Trabajar con bibliotecas comunes/de utilidad

Question

En la empresa para la que trabajo tenemos un proyecto de "Utilidad" al que hacen referencia casi todas las aplicaciones que creamos.Tiene muchas cosas como NullHelpers, ConfigSettingHelpers, Common ExtensionMethods, etc.

La forma en que trabajamos es que cuando queremos crear un nuevo proyecto, obtenemos la última versión del proyecto desde el control de fuente, la agregamos a la solución y luego hacemos referencia al proyecto desde cualquier proyecto nuevo que se agregue a la solución.

Esto ha funcionado bien, sin embargo, ha habido un par de casos en los que las personas han realizado "cambios importantes" en el proyecto común, que funciona para ellos, pero no para otros.

He estado pensando que en lugar de agregar la biblioteca común como referencia del proyecto, tal vez deberíamos comenzar a desarrollar la biblioteca común como una DLL independiente y publicar diferentes versiones y apuntar a una versión particular para un proyecto en particular para que se puedan realizar cambios sin ningún riesgo. a otros proyectos que utilizan la biblioteca común.

Habiendo dicho todo esto, me interesa ver cómo otros hacen referencia o usan sus bibliotecas comunes.

Answer 1

Eso es exactamente lo que estamos haciendo.Tenemos un proyecto de utilidad que tiene algunas funciones útiles no específicas del proyecto.Aumentamos la versión manualmente (menor), creamos el proyecto en la versión de lanzamiento, lo firmamos y lo colocamos en una ubicación compartida.

Luego la gente usa la versión específica del biblioteca.

Si se implementan algunos métodos útiles en algunos proyectos específicos que podrían llegar al proyecto de utilidad principal, los colocamos en una clase auxiliar especial en el proyecto y los marcamos como un posible candidato de utilidad (simple //TODO).Al final del proyecto, revisamos los candidatos y si se quedan, los trasladamos a la página principal. biblioteca.

Los cambios importantes están prohibidos y marcamos métodos y clases como [Obsoletos] si es necesario.

Pero realmente no importa porque aumentamos la versión en cada publicación.

Espero que esto ayude.

Answer 2

Usamos ramificaciones en el control de fuente;todos usan la rama principal hasta que hacen un lanzamiento.Cuando ramifiquen la versión, también ramificarán el proyecto de utilidades comunes.

Además, nuestro proyecto de servicios públicos tiene sus propias pruebas unitarias.De esa manera, otros equipos pueden saber si romperían la construcción para otros equipos.

Por supuesto, todavía tenemos problemas como los que usted menciona de vez en cuando.Pero cuando un equipo registra un cambio que rompe la construcción de otro equipo, generalmente significa que el contrato para ese método/objeto se ha roto en alguna parte.Vemos esto como oportunidades para mejorar el diseño del proyecto de servicios públicos comunes...o al menos escribir más pruebas unitarias :/

Answer 3

he tenido el EXACTO ¡mismo problema!

Solía ​​​​usar referencias de proyectos, pero todo parece ir mal cuando, como dices, tienes muchos proyectos que hacen referencia a ellos.

Ahora compilo en una DLL y configuro la propiedad CopyLocal para la referencia de la DLL en falso después de la primera compilación (de lo contrario, encuentro que puede anular los subproyectos y convertirse en un desastre).

Supongo que, en teoría, probablemente debería tener GAC, pero si es un problema que está cambiando mucho (como el mío), esto puede volverse problemático.