Múltiples aplicaciones en una sola solución de Visual Studio [cerrado]

Estoy trabajando para una empresa que quiere reunir todas sus aplicaciones .Net (aplicaciones web, aplicaciones de Windows y aplicaciones de consola) en una sola solución de Visual Studio.

Estoy buscando experiencia de desarrolladores que estructuran sus propias aplicaciones de esta manera o que trabajan en una empresa que hace esto. ¿Es esta una buena idea?

• ¿Cuáles son las ventajas y desventajas de poner todas sus aplicaciones en una única solución en lugar de tener soluciones separadas para cada aplicación?

• ¿Qué tan rápido es Visual Studio con una solución de más de 20 proyectos?

• ¿Y qué tan estable es el archivo de solución con desarrollo concurrente controlado por fuente?

Recientemente, migramos casi todo el código fuente de mi empresa a una única solución.

¿Por qué?

Originalmente, teníamos docenas de soluciones. Algunos proyectos de una solución reutilizaron proyectos de otra, y a nadie le importó usar un administrador de paquetes. El día que cambie sustancialmente un proyecto que se usa en casi todas partes, espere horas y horas de trabajo perdido para toda la empresa durante los próximos días o semanas. La peor parte es que ni siquiera puedes saber qué se vería afectado exactamente por el cambio.

Fusionar todo el código en una solución era una alternativa. Funciona bien por el momento, y las dependencias ahora son fáciles de seguir. ¿Desea modificar un método pero también realizar un seguimiento de las repercusiones que este cambio puede tener en cualquier parte de la base del código? Visual Studio puede hacer eso con facilidad. Para mí es un éxito.

La integración continua ahora también es más fácil. Una solución para compilar e implementar. Casi nada que configurar.

¿Es escalable?

En cuanto al rendimiento, Visual Studio me sorprendió mucho . Pensé que comenzaría a llorar con una solución con, digamos, 50 proyectos. Hoy, hay más de 200 proyectos; Visual Studio parecía ser lo suficientemente escalable como para administrarlos como si solo hubiera 20 de ellos. Sí, hay cosas que llevan tiempo. Si vuelve a compilar cada proyecto, con contratos de código, análisis de código habilitado de forma predeterminada, etc., espere que tarde un tiempo. Pero nadie esperaría compilar 200 proyectos tan rápido como 10, y por cierto, no debería: esta es la función del servidor de integración continua. El tiempo de inicio (arranque en frío, luego cargar la solución) es impresionantemente rápido ; tal vez no sea tan rápido como con 10 proyectos, pero sigue siendo muy aceptable (menos de 20 segundos en una máquina comprada hace más de cinco años).

Para ir aún más lejos, descargar proyectos sistemáticamente es una buena idea (y realmente fácil cuando los proyectos se organizan en directorios dentro de la solución). Si alguien trabaja en algo que requiere la carga de solo tres proyectos, no es necesario cargar los 200 proyectos (a menos, por supuesto, que las dependencias puedan verse afectadas).

El control de versiones también funciona como se esperaba (estoy usando un servidor SVN, si es importante). No he trabajado en un entorno real concurrente, con, digamos, docenas de desarrolladores que frecuentemente cometen código, pero me imagino que esto no tendría demasiados problemas. Solo tenga cuidado con los casos en que muchos desarrolladores agregan nuevos proyectos al mismo tiempo: fusionar el archivo .sln no es lo más fácil de hacer.

Conclusión

Si tuviera que elegir la decisión nuevamente:

1. Todavía migraría todo a una única solución. Esto reduce enormemente el dolor de las dependencias rotas, y este beneficio solo vale totalmente la pena. Tener un lugar centralizado para todo el código también es una buena idea; Esto hace posible, por ejemplo, buscar algo dentro de Visual Studio. También puedo trabajar en dos proyectos débilmente relacionados, y todavía tengo una sola ventana de Visual Studio abierta.

2. También estudiaría un poco más NuGet y la capacidad de alojar un servidor NuGet privado. Administrar las dependencias a través de NuGet puede resolver algunos de los problemas cuando no desea fusionar algunos proyectos en la solución común. Personalmente, no tenía tales casos, pero imagino que otras compañías podrían tenerlos.

3. Finalmente, invertir en un SSD para cada desarrollador puede hacer una gran diferencia. Pero no es necesario, y en mi caso, la base del código todavía está almacenada en un disco duro normal.

Este es el uso previsto.

¿Cuáles son las ventajas y desventajas de poner todas sus aplicaciones en una única solución en lugar de tener soluciones separadas para cada aplicación?

• pros:
  • referencias más fáciles entre proyectos
  • depuración / paso más fácil
  • más fácil de adjuntar a los procesos (es decir, está pasando por un servicio de Windows, cuando salta al código de la biblioteca compartida, y simplemente funciona porque todos los símbolos ya están cargados y contabilizados)
  • la búsqueda de código dentro del ide funciona mejor (no necesariamente tiene que saber en qué proyecto reside el código que está buscando)
  • las listas de cambios entre proyectos son más fáciles de administrar (es decir, cambió el código de la biblioteca, por lo que debe actualizar el código del cliente al mismo tiempo, con 1 registro)
• contras:
  • velocidad de construcción: si tiene la costumbre de "reconstruir todo", las construcciones tardan más. Mucho más, y las construcciones incrementales a veces tienen un comportamiento funky.
  • velocidad ide: ver siguiente

¿Qué tan rápido es Visual Studio con una solución de más de 20 proyectos?

Con más de 20 proyectos ... podría no ser tan malo. He visto más sin que VS tenga problemas. Es bastante estable / rápido. SIN EMBARGO ... si es un problema, puede mitigarse: abra el .csproj en VS y trabaje desde allí. No obtienes los beneficios de tener todo en una solución, pero siempre puedes volver a abrir el sln cuando lo necesites y trabajar solo en el .csproj cuando lo necesites (como lo haces ahora).

¿Y qué tan estable es el archivo de solución con desarrollo concurrente controlado por fuente?

El archivo de solución solo cambia cuando agrega / elimina proyectos u objetos de nivel de solución, por lo que rara vez cambia. Es xml, para que pueda ver lo que contiene. Cambian raramente.