Tenemos un problema similar ya que tenemos 109 proyectos diferentes para tratar. Para responder a las preguntas originales, basadas en nuestras experiencias:
1. ¿Cómo hacer que las mejores referencias de la manija entre los proyectos
Usamos la opción del menú contextual 'añadir referencia'. Si se selecciona 'proyecto', entonces la dependencia se agrega a nuestro único archivo de solución global de manera predeterminada.
2. ¿Se debe activar o desactivar "copiar local"?
Apagado en nuestra experiencia. La copia adicional solo aumenta los tiempos de compilación.
3. En caso de que todos los proyectos de construcción a su propia carpeta, o en caso de que toda la construcción en la misma carpeta de salida (todos ellos son parte de la misma aplicación)
Toda nuestra salida se colocan en una sola carpeta llamada 'bin'. La idea es que esta carpeta sea la misma que cuando se implementa el software. Esto ayuda a prevenir problemas que ocurren cuando la configuración del desarrollador es diferente de la configuración de implementación.
4. ¿Las carpetas de soluciones son una buena forma de organizar cosas?
No en nuestra experiencia. La estructura de carpetas de una persona es la pesadilla de otra persona. Las carpetas profundamente anidadas solo aumentan el tiempo que lleva encontrar algo. Tenemos una estructura completamente plana, pero el nombre de nuestros archivos de proyectos, ensambles y espacios de nombres es el mismo.
Nuestra manera de estructurar proyectos se basa en un único archivo de solución. Construir esto lleva mucho tiempo, incluso si los proyectos en sí mismos no han cambiado. Para ayudar con esto, normalmente creamos otro archivo de solución de "conjunto de trabajo actual". Cualquier proyecto en el que estamos trabajando se agrega a esto. Los tiempos de compilación han mejorado mucho, aunque un problema que hemos visto es que Intellisense falla para tipos definidos en proyectos que no están en el conjunto actual.
un ejemplo parcial de nuestra solución de diseño:
\bin
OurStuff.SLN
OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]
¿Puedo preguntar por qué una sola solución necesita más de 100 proyectos? ¿Están creando cada uno su propia asamblea? –
Sí, lo son, y cada uno de ellos representa una funcionalidad lógicamente separada. – Eyvind
Tenemos algo similar aquí en Java ...un marco, alrededor de 200 complementos por ahora. Pone a Eclipse a prueba cuando los tengo cargados y apuesto a que no es tan raro (aunque esto es académico, probablemente diferente de The Real World ™). – Joey