c# - org - Trabajando con bibliotecas comunes/de utilidad
mapwindows 5 (3)
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 de forma manual (menor), compilamos el proyecto en Versión de lanzamiento, lo firmamos y lo colocamos en una ubicación compartida.
La gente luego usa la versión específica de la biblioteca .
Si se implementan algunos métodos útiles en algunos proyectos específicos que podrían encontrar su camino en el proyecto de la utilidad principal, colocamos la clase de ayuda 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 mantienen, los trasladamos a la biblioteca principal.
Los cambios de última hora son un no-no y marcamos los métodos y las clases como [Obsoleto] si es necesario.
Pero, realmente no importa porque aumentamos la versión en cada publicación.
Espero que esto ayude.
En la empresa para la que trabajo tenemos un proyecto de "Utilidad" al que se hace referencia en la mayoría de las aplicaciones que creamos. Tiene muchas cosas como NullHelpers, ConfigSettingHelpers, Common ExtensionMethods, etc.
La forma en que trabajamos es que cuando queremos hacer un nuevo proyecto, obtenemos la última versión del proyecto desde el control de fuente, lo 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 funciona para otros.
He estado pensando que, en lugar de agregar la biblioteca común como referencia de proyecto, quizás deberíamos comenzar a desarrollar la biblioteca común como dll independiente y publicar diferentes versiones y apuntar a una versión particular para un proyecto en particular, para que los cambios puedan hacerse sin ningún riesgo a otros proyectos que usan la biblioteca común.
Habiendo dicho todo lo que me interesa, veo cómo otros hacen referencia o usan sus bibliotecas comunes.
¡He tenido el mismo problema!
Solía usar referencias de proyectos, pero todo parece ir mal, cuando, como dices, tienes muchos proyectos que hacen referencia a él.
Ahora compilo a una DLL, y establezco la propiedad CopyLocal para la referencia DLL a falso después de la primera compilación (de lo contrario, creo que puede anular subproyectos y convertirse en un desastre).
Supongo que en teoría probablemente debería ser GAC, pero si es un problema que está cambiando mucho (como el mío), esto puede volverse problemático.
Usamos ramificación en control de fuente; todos usan la rama de la cabeza hasta que hacen una liberación. Cuando ellos ramifican el lanzamiento, también ramificarán el proyecto de utilidades comunes.
Además, nuestro proyecto de servicios públicos tiene sus propias pruebas unitarias. De esta manera, otros equipos pueden saber si romperían la construcción de otros equipos.
Por supuesto, todavía tenemos problemas como los que mencionas ocasionalmente. Pero cuando un equipo verifica 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. Consideramos que estas son oportunidades para mejorar el diseño del proyecto de utilidades comunes ... o al menos para escribir más pruebas unitarias: /