Compartir clases o interfaces entre diferentes proyectos.

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?

crear un proyecto adicional en el que se definan todas las cosas comunes

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.

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;

libmyproject-shared-1.0.jar

No evita problemas de versiones, pero debería ayudar. Nunca he usado Maven, pero entiendo que puede ayudar en esta situación.

crear un proyecto adicional en el que se definan todas las cosas comunes

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:

• La única forma en que podía serializar / deserializar objetos directamente entre los dos programas (es cierto que esto fue hace un tiempo usando Framework 2.0) era instalar el ensamblado "compartido" en la Caché de ensamblados global en las máquinas cliente y servidor. Si el ensamblaje era "local" para cada proyecto, entonces el Marco los veía como Tipos discretos y se negaba a [des] serializar el uno en el otro.
• Y [des] serializar objetos Escritos como Interfaces es un poco un "desafío". El tipo original que no era de interfaz no parecía "pasar" a través de la "tubería" de serialización, por lo que el receptor no sabía qué tipo concreto "construir" a partir de la transmisión entrante.

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.