Cantidad recomendada de proyectos en Visual Studio Solution

Question

Estamos comenzando a desarrollar una nueva aplicación que incluirá algo así como 30-50 proyectos desarrollados por una docena de desarrolladores con C# en MS Visual Studio.

Estoy trabajando en componentes de los módulos de la aplicación para soportar la arquitectura y permitir el trabajo en paralelo.

Hemos argumentado: ¿Cuántas soluciones deberíamos tener?

Algunos afirman que deberíamos tener una solución de 1-2 con 15-30 proyectos cada uno. Algunos afirman que necesitamos una solución por componente que signifique entre 10 y 12 soluciones con aproximadamente 3-6 proyectos cada una.

estaría feliz de escuchar ventajas/desventajas y experiencia con cada dirección (u otra dirección del mismo)

Gracias

Answer 1

No creo que el número real de asuntos soluciones. Mucho más importante es que rompa la cosa a lo largo de líneas funcionales. Como un ejemplo tonto y artificial si tiene un grupo de bibliotecas que maneja la interoperabilidad con servicios web extranjeros, esa sería una solución; un EXE con las DLL que necesita para trabajar sería otro.

Answer 2

Creo que no debería exagerar la cantidad de proyectos/soluciones. Componentize lo que puede
y será reutilizado, de lo contrario no componentes! Solo hará que las cosas sean menos transparentes y aumentará los tiempos de construcción. El particionamiento también se puede hacer dentro de un proyecto usando una carpeta o usando una estructura de clase lógica.

Answer 3

Desea mantener las referencias del proyecto. Si puede dividir su solución de manera segura con dos o más conjuntos de proyectos discretos que dependen uno del otro, hágalo. Si no puedes, entonces todos deben estar juntos.

Answer 4

Las soluciones están realmente ahí para la gestión de la dependencia, por lo que puede tener proyectos en más de una solución, si más de una cosa depende de ello. La cantidad de soluciones realmente debería depender de su gráfico de dependencia.

Editar: Esto significa que no debe pegar proyectos que no dependen el uno del otro en la misma solución, ya que crea la ilusión de dependencia, lo que significa que alguien podría crear una dependencia real cuando dos proyectos realmente deberían ser independientes.

Answer 5

Lo único que tiene que ver con tantos proyectos en una sola solución es que las referencias y el orden de construcción comienzan a ser confusos.

Como regla general, me gustaría reducir el número de proyectos (hacer el proyecto un poco más genérico) y hacer que los desarrolladores compartan el control de fuente en esos proyectos, pero separar la funcionalidad dentro de esos proyectos por espacios de nombres.

Answer 6

He trabajado en una solución con cerca de 200 proyectos. No es gran cosa si tienes suficiente RAM :).

Una cosa importante para recordar es que los proyectos dependen uno del otro (ya sea con Dependencias o Referencias), probablemente deberían estar en la misma solución. De lo contrario, obtienes un comportamiento extraño cuando diferentes proyectos tienen dependencias diferentes en diferentes soluciones.

Answer 7

Debe tener tantas como necesite. No hay límite ni buenas prácticas. Practica y lee sobre los proyectos y las soluciones y luego toma las decisiones de ingeniería adecuadas sobre lo que necesitas a partir de ahí.

Answer 8

Tenemos una solución que tiene aproximadamente 130 proyectos. Hace unos 3 años, cuando utilizamos vs.net 2003, fue un problema terrible. A veces, la solución y el VSS se bloqueaban.

Pero ahora con VS.NET 2005 está bien. Solo cargarlo lleva mucho tiempo. Algunos de mis compañeros de trabajo descargan proyectos que no usan. Es otra opción para acelerar.

Cambiar el tipo de compilación a versión es otro problema. Pero ahora tenemos scripts de MSBuild. Ya no usamos la versión de VS.NET de relese.

Answer 9

Se ha dicho en otras respuestas; sin embargo, probablemente valga la pena repetirlo.

Las dependencias de proyectos son buenas ya que pueden reconstruir proyectos dependientes si la dependencia tiene un cambio.

Si realiza una dependencia de archivos de ensamblado, no hay manera de que VS o MSBuild sepan que se debe crear una cadena de proyectos. Lo que sucederá es que en la primera construcción se reconstruirá el proyecto que ha cambiado. Si ha puesto la dependencia en la salida de compilación, al menos en la segunda compilación dependerá el proyecto que se compilará. Pero luego tienes un número desconocido de compilaciones necesarias para llegar al final de la cadena.

Con dependencias de proyecto, lo resolverá por usted.

Así que la respuesta que dice tiene tantos (o pocos) como sea necesario para garantizar que se utilicen las dependencias del proyecto.

Si su equipo se divide en áreas funcionales que tienen un mecanismo de liberación más formal en lugar de verificar el código fuente, dividirlo sería el camino a seguir, de lo contrario, el mapa de dependencia es su amigo.

Answer 10

He trabajado en productos en ambos extremos: uno con ~ 100 proyectos en una sola solución, y uno con> 20 soluciones, de 4-5 proyectos cada una (Prueba, Business Layer, API, etc.).

Cada enfoque tiene sus ventajas y desventajas.

Una sola solución es muy útil cuando se realizan cambios: es más fácil trabajar con dependencias y permite que las herramientas de refactorización funcionen bien. Sin embargo, da como resultado tiempos de carga más largos y tiempos de construcción más largos.

Las soluciones múltiples pueden ayudar a forzar la separación de las preocupaciones y mantener bajos los tiempos de construcción/carga, y pueden ser adecuadas para tener múltiples equipos con un enfoque más estrecho y límites de servicio bien definidos. Sin embargo, tienen un gran inconveniente cuando se trata de refactorización, ya que muchas referencias son archivos, no referencias de proyectos.

Tal vez haya espacio para un enfoque híbrido, use soluciones más pequeñas en su mayor parte, pero cree una sola que incluya todos los proyectos para los momentos en que se requieren cambios a mayor escala. Por supuesto, debe mantener dos soluciones separadas ...

Finalmente, la estructura de sus proyectos y dependencias influirá en la organización de sus soluciones.

Y tenga en cuenta que, a la larga, la RAM es más barata que el tiempo del programador ...

Answer 11

Al decidir qué número de proyectos de soluciones vs qué necesita, es necesario concider algunas preguntas:

• capas lógicas de su aplicación;
• dependencia entre proyectos;
• cómo se crean los proyectos;
• que trabaja con qué proyectos;

Actualmente tenemos 1 solución con 70 proyectos. Para nuestra integración continua, creamos 5 proyectos msbuild, por lo que CI no desarrolla nuestra solución de desarrollo.

Anteriormente, teníamos una solución separada para la capa de presentación (web y proyectos relacionados) en un repositorio de git separado. Esta solución fue utilizada por desarrolladores web externos y externos.