Administrar dependencias de ensamblado .NET mediante referencia dll en lugar de referencia de proyecto en VS

Question

Tenemos un proyecto .NET que consta de varios subproyectos (alrededor de 20). Hay varias soluciones, cada una conteniendo solo aquellos subproyectos que son relevantes para la solución particular.

Para permitir soluciones arbitrarias, nuestros subproyectos nunca se referencian entre sí mediante referencias de proyecto, sino más bien mediante referencias dll directas. Hay pocos ajustes en el archivo csproj, para que HintPath incluya $ (Configuración), por lo que Debug construye referencias de Debll dlls y Release builds reference Release dlls.

Todo funciona muy bien, pero hay dos problemas importantes - uno es molesto y otro es muy aguda:

1. VS no reconoce las referencias dll con el propósito de calcular la dependencia. Tenemos que especificar manualmente las dependencias usando el diálogo "Dependencias del proyecto" cada vez que se agrega un nuevo proyecto o referencia. Esto es molesto
2. No usamos ni Resharper ni Visual Assist (grandes herramientas, pero no las usamos, es un hecho). Nos gusta utilizar el comando estándar "Navegar a la definición" (disponible desde el menú contextual en el código fuente, por ejemplo). El problema principal es que solo funciona en el proyecto cruzado si un proyecto hace referencia al otro utilizando la referencia del proyecto y no funciona cuando la referencia es la referencia directa del dll, , incluso si el proyecto al que se hace referencia está incluido en la solución. Eso es un verdadero fastidio, porque en lugar de navegar hacia la fuente, navega hacia los metadatos.

Estoy buscando un consejo de aquellos que usan referencias de dll como nosotros y de alguna manera han superado estos dos problemas. Gracias.

EDIT:

Tenga en cuenta, que además del tema "Navegar a Definición", que tiene referencias de DLL en lugar de las referencias del proyecto incurre en un único coste de tiempo en el director del proyecto - que es para actualizar las dependencias del proyecto de cada solución afectada cuando se agrega un nuevo proyecto o se debe introducir una nueva dependencia. Estas dependencias de proyecto se conservan en el archivo .sln y no requieren mantenimiento hasta que llega un nuevo proyecto o se crea una nueva dependencia, lo que ocurre con demasiada frecuencia.

Estamos utilizando msbuild para construir nuestros proyectos en el servidor de CI, que utiliza los mismos archivos .sln que VS. Hay un archivo .sln principal, que incluye todos los subproyectos.

Deseo enfatizar el problema más agudo - la incapacidad de navegar a una definición en otro proyecto, aunque ambos proyectos están en la misma solución solo porque las referencias son referencias dll. Esto es molesto y es una molestia, no hay ninguna razón por la que VS insista en las referencias del proyecto para habilitar la función. Otras herramientas, como Resharper o Visual Assist no tienen esta limitación. Por desgracia, no tenemos estas herramientas y es poco probable que las tengamos en el futuro observable.

Answer 1

¿Hay alguna razón por la que desee permitir soluciones arbitrarias? Parece que sería más fácil crear una solución única y poner todos los proyectos en esa solución. Intento evitar múltiples soluciones siempre que sea posible.

Answer 2

Me parece que los problemas que encuentra son el resultado directo del uso incorrecto de su conjunto de herramientas. Visual Studio no tiene otra forma de calcular automáticamente las dependencias de proyecto cuando no permite que lo administre.

Parece que tiene dos opciones.

1. Uso de Visual Studio para gestionar las dependencias del proyecto
2. utilizar otro sistema de construcción (como de NAnt)

Suena como usted ha descartado la opción # 1, por lo que no se ocupará de eso nunca más . Entonces eso solo deja la opción # 2.

Puede usar NAnt para construir sus proyectos de CSproj individuales y usar su script de construcción NAnt para definir las dependencias entre proyectos. Hay dos desventajas en esto.

1. usted tiene que manejar todo compre mano (que suena como si estuviera preparado para hacerlo)
2. Visual Studio sería igualmente como roto con usted lo que es ahora.

En el inconveniente # 2, Visual Studio no podría compilar la solución como un todo porque esa lógica se habría desplazado de VS a un script de compilación externo. Esto podría generar confusión entre los desarrolladores y dificultaría el proceso de depuración. No digo que esas cosas no se superen, que sean capaces ... solo digo que sería una configuración extra involucrada en esos pasos del proceso de desarrollo.

Answer 3

El problema con la configuración de su compilación es el siguiente: supongamos que tiene 3 proyectos y 2 soluciones.

Solution1 
- Project1 
- Project2 
Solution2 
- Project1 
- Project3 

De repente, la construcción de Solución 2 se basa parte del código para la Solución 1, dejándolo en un estado no válido (los últimos binarios son incompatibles o no necesitan ser construidas).

Cada proyecto debe incluirse en una única solución. Pueden confiar en otras soluciones, pero no deben cambiar activamente el código de esos proyectos. De esta forma, pueden hacer referencia a una DLL integrada porque no hay motivo para reconstruir las dependencias externas.

En resumen, usted debe tomar algún tiempo y reestructurar sus soluciones para satisfacer las siguientes condiciones:

• Cada proyecto está incluido en exactamente una solución.
• Si un proyecto depende de otro proyecto dentro de la misma solución, conviértalo en una referencia de proyecto.
• Si un proyecto depende de otro proyecto en una solución diferente , conviértalo en una referencia de DLL.

Además de lo anterior, recomiendo crear un directorio "Externo" para colocar construcciones cuando se hace referencia a otras soluciones. Digamos que reestructurar a lo siguiente:

Solution1 
- Project1 
- Project2 -> reference project Project1 
Solution2 
- Project3 -> reference Project1.dll 

En este caso, tendría que incluir copias de Project1.dll y Project1.pdb en Externals\Project1\Debug y Externals\Project1\Release y la referencia External\Project1\$(Configuration)\Project1.dll en proyecto3. Solo actualice las compilaciones en el directorio Externals cuando esté listo para enviar la compilación a todas sus otras soluciones.