Estaba buscando algunas respuestas en SO o aquí, pero sin ningún resultado, es por eso que le preguntaría.
Supongamos que tengo dos proyectos diferentes, por ejemplo, parte del servidor y parte del cliente de una aplicación. Estoy desarrollando mi propia parte, mientras mi amigo está haciendo la segunda. Pero ambos deberíamos usar algunas interfaces comunes como Usero AccountInfoo ChangableAccount... lo que sea para garantizar una compatibilidad. Por ejemplo, si un cliente envía un dato de Usuario al servidor, entonces el servidor debe operar en la misma clase. Lo mismo con las interfaces, etc. Además, si hay algún cambio en una interfaz común, ambos proyectos deben ajustar su código a la nueva situación.
La única solución que puedo ver ahora es crear un proyecto adicional en el que se definan todas las cosas comunes. Nosotros, mi amigo y yo, deberíamos agregar este proyecto como una dependencia a un proyecto principal (cliente o servidor). El proyecto compartido puede ser administrado por algún sistema de control de versiones, por lo que siempre tenemos el estado más actualizado.
¿Qué otra solución sugerirías? ¿Cómo se resuelven estos problemas en las aplicaciones profesionales?
fuente
Respuestas:
Este es exactamente el primer paso para compartir piezas reutilizables, y es la parte fácil. La parte más difícil es decidir si los dos proyectos que usan la biblioteca compartida tendrán ciclos de lanzamiento independientes (o no), y si debería ser posible que el "proyecto A" use la versión 1.0 de su lib compartida, mientras que el proyecto B usa versión 2.0 al mismo tiempo .
Si desea que esto último sea posible, debe tener un estricto esquema de versiones y administración de versiones para su biblioteca (y números de versión como parte del nombre del archivo de la biblioteca, como lo sugiere @RoryHunter). También debe tener cuidado con la compatibilidad con versiones anteriores en su lib en esta situación. Su biblioteca debe administrarse como un producto separado, agregando pruebas unitarias para asegurarse de que las diferentes versiones en producción serán una buena idea, y una herramienta como Maven también puede tener sentido.
Sin embargo, si desea evitar esa situación, debe administrar el "proyecto A", el "proyecto B" y su lib como un proyecto común, con un proceso combinado de desarrollo, compilación y lanzamiento. Esto permitirá cambiar la interfaz común de la biblioteca compartida mucho más y con frecuencia que en el primer escenario. Y no necesitará algo como Maven o números de versión en el nombre del archivo de la biblioteca. Pero la compensación es que A y B ya no pueden desarrollarse independientemente.
fuente
Tu solución es la correcta. Coloque el código compartido en otro proyecto que construya su propio archivo JAR y úselo en ambos proyectos. Al construir el archivo JAR, es posible que desee incluir la versión en el nombre, por ejemplo, en estilo Debian;
No evita problemas de versiones, pero debería ayudar. Nunca he usado Maven, pero entiendo que puede ayudar en esta situación.
fuente
Esa es exactamente la forma en que .Net espera que lo haga.
Resuma estos objetos en una tercera Asamblea, y haga referencia a esto desde ambos proyectos. Sugeriría hacerlo como Interfaces, que es más limpio, pero ...
Cuidado con la serialización:
fuente
Como otros han sugerido, su proceso de pensamiento es preciso. Profesionalmente, la mayoría usaría algo como Maven o Gradle para administrar estas dependencias de manera eficiente.
fuente