Compartir contratos de WCF para el cliente y el server

Hay 2 equipos trabajando en un producto. Un equipo está trabajando en una lógica del lado del server, expuesto como un service WCF, el otro equipo está trabajando en la implementación de una interfaz (ASP.NET MVC website). ¿Cuál es la solución adecuada para compartir API de service entre esos 2 equipos? Por API quiero decir una interfaz de service web + un grupo de classs de DTO. Estamos usando git y TeamCity para una continuous integration. El service y el front-end se desarrollan y despliegan de forma independiente.

En base a esto, las opciones que veo son:

  1. Ponga todo el material de "interfaz" en un proyecto separado y compártelo a través de los modules de git. Tanto el cliente como el server compartirán el código.
  2. Ponga todo el material de "interfaz" en un proyecto separado y publíquelo en el repository NuGet privado. Tanto el cliente como el server harán reference al único ensamblaje común.
  3. Coloque tanto el cliente como el server en la única solución VS y literalmente comparta el ensamblaje.

La opción 3 parece ser el enfoque más trivial, fácil de implementar y comprender, pero no estoy muy entusiasmado con la idea de get una solución más grande. Las opciones 1 y 2 son muy parecidas, aunque me gusta más la opción 2.

¿Cuál crees que es un mejor enfoque aquí? ¿Alguna otra solución?

Usamos la opción 4: el cliente y el server están en soluciones separadas, pero ambas soluciones contienen el mismo proyecto de contrato de WCF (que contiene solo definiciones de [DataContract] y [ServiceContract] ) y lo referencen con una reference de proyecto en lugar de una reference de ensamblado. Puede sonar gracioso pero funciona bien.

Ambas soluciones se pueden build por separado y ambas obtienen la misma DLL, ya sea en el order en que estén integradas, la segunda compilation no volverá a comstackr la DLL porque ya está actualizada.

La principal ventaja de esto, como yo lo veo, es que cuando alguien hace que un código fuente cambie al proyecto del contrato, el cambio está disponible instantáneamente para el código del cliente y del server sin tener que "actualizar" nada. Esto corta arguments como "Sí, hice ese cambio", "no, no lo hiciste", "sí, lo hice", "bueno, no puedo verlo", etc.

Almacenamos nuestro código común en una solución separada. Produce .dll's que se agregan como un set simple de references a otros proyectos múltiples que dependen de ellos.

Todas las construcciones están definidas en files nant, y tenemos algunos files .bat que ejecutan las comstackciones en el order apropiado.

Cuando solo quiere build el proyecto desde VS, el .dll dependiente probablemente ya esté construido. Si quieres ser 100% Tienes todo construido con los últimos cambios, ejecutas esos scripts bat que activarán nant comstackciones y rebuildán todo.

En mi proyecto utilizamos la forma similar a la descrita en la opción 1 compartiendo códigos