Versioning y estructura de la solución en Visual Studio

Tengo un sistema que tiene tres aplicaciones (una aplicación de Windows y dos aplicaciones web). Todas estas aplicaciones comparten dos sets en común. Por lo tanto, tengo 5 proyectos en total. En el pasado, tuve una solución separada para cada proyecto. Esto me permitió versionar cada ensamblaje individualmente en control de fuente. Sin embargo, esto tiene una sobrecarga significativa porque tengo que abrir cada solución por separado para ver si un cambio que realicé en uno de los ensamblajes comunes rompió cualquiera de las aplicaciones.

He pensado en pasar a una estructura en la que una solución contenga todos los proyectos. Esto me permite ver de inmediato el impacto de cualquier cambio que realice, pero conduce a problemas de versiones. Si solo cambio el ensamblaje común, o si solo cambio una de las aplicaciones, cada proyecto / ensamblaje pronto estará en un nivel de versión diferente. En el control de fuente, dado que toda la solución está unida, no tengo un número de versión único para usar en el repository de mi proyecto.

Cada discusión que he leído parece resolver un problema o el otro. O bien, múltiples soluciones para versiones más sencillas o una única solución para un control de dependencia más sencillo.

¿Qué sugerencias tienen las personas para estructurar soluciones / proyectos mientras se pueden versionar los ensamblajes de manera apropiada?

Me quedaría con múltiples soluciones. Su aplicación de Windows realmente no necesita (y no debería) saber qué está pasando en sus aplicaciones web.

Trabajo con una configuration similar donde tenemos múltiples aplicaciones web con sets comunes compartidos entre ellos. Tener una creación diaria (o continua si tus times de construcción son lo suficientemente rápidos) ayuda enormemente. Utilizamos NAnt y CruiseControl, pero las opciones disponibles son tan abundantes como las opiniones.

Si utiliza una configuration de compilation continua, puede hacer que las otras comstackciones de soluciones (aplicaciones web, etc.) se activen después de que las bibliotecas compartidas compilen y pasen sus testings unitarias. Todavía tendría que abrir la otra solución, pero el server de compilation puede decirle si es necesario.

Personalmente, me gusta la solución que favorece un control de dependencia más fácil. Estoy mucho más preocupado por romper los cambios que por tener elementos en la misma versión.

La única vez que (personalmente) me preocuparía la versión # es cuando tengo que solucionar problemas o corregir un error. Y si tengo que hacer una corrección de errores, finalmente voy a volver a comstackr el código y tendré la versión más reciente. Honestamente, si hay alguien corriendo código que usa una versión anterior de alguna biblioteca de classs compartida que he desarrollado, ¿y qué? Si funciona, ¿qué me importa si se trata de una versión anterior? Es probable que la única razón por la que hay una versión más nueva es que alguna otra aplicación escrita posteriormente requiera una funcionalidad adicional.

Esto, por supuesto, asume que estás siguiendo el mandamiento "no cambiarás las asambleas compartidas de tal manera que el cambio rompa el código existente". Agregar una nueva function está bien. La modificación de una function para que funcione de manera diferente internamente, pero devuelve el mismo resultado, está bien. Cambiar una function para que funcione para el nuevo software pero rompe el software existente NO ES ACEPTABLE. Luego, preocuparse por el control de versiones no es un problema.

Por supuesto, esto podría deberse a que nunca he trabajado en una tienda donde haya una razón para preocuparse por la versión, así que espero ser golpeado por esta respuesta, pero incluso si lo estoy, estoy seguro de que Aprenderé de los comentarios sobre por qué esta es una mala respuesta, y por eso me gusta este sitio de todos modos.