2010-10-08 6 views
5

A menudo tenemos un conjunto de bibliotecas centrales comunes que, para algunos de nuestros desarrollos, queremos considerarlas como referencias dll y, por lo tanto, solo hacemos referencia a las DLL y no incluimos archivo de proyecto.¿Hay una manera simple de cambiar entre un proyecto y su dll?

Otras veces necesitamos todos los proyectos para una sesión de depuración íntima. No puedo simplemente tener Uber.sln y Core.sln ya que las referencias están en los archivos del proyecto. He tenido esta pregunta durante varios años en diferentes proyectos, pero no tengo otra solución que no sea tener un Uber.sln con los 50 proyectos.

Cualquier idea/pista/dirección bienvenida!

Respuesta

2

Siempre que las DLL estén compiladas con Debug y tenga los PDB, no necesita tenerlo incluido como "referencia de proyecto".

Le solicitará el código fuente, o puede simplemente abrir el código fuente en la solución y establecer un punto de interrupción.

How to show source code in debug when using .lib and dll

+0

+1, yup. Rara vez tiene problemas para encontrar el archivo .pdb, siempre y cuando aún se encuentre en la carpeta de compilación original. –

2

Desarrollen dlls en su propio proyecto o proyectos compartidos. Compítalos y agréguelos a una carpeta lib en sus proyectos que los referencian.
crear un árbol dev así:

/lib 
shareddlls go here 
/src 
solution.sln 
/projectfolder 
    project.proj 
/tools 
testing frameworks 

Al depurar en VS y entra en sus propios archivos DLL que aún debe ser capaz de ver el código por lo que no es necesario añadir los archivos DLL compartidos para un proyecto súper. Si no puede ver el código, trátelo como una caja negra. Depure lo que entra y lo que sale. Si no es lo que espera, entonces el problema está en los dlls compartidos. Vaya y depúrelos en sus propios proyectos.

Utilice un marco de prueba para probar sus dlls compartidos en su propio proyecto. -----

+0

Hay momentos en los que desea desarrollar características que cruzan los dlls compartidos y los dlls de la aplicación. En esos momentos, tener una solución grande paga dividendos. Simplemente parece ser una forma de trabajo que MS no admite. – Squirrel

+0

@Squirrel Para mí ese es un mal diseño. Cada clase debe ser responsable de una cosa y, de manera similar, los proyectos (dlls) deben agrupar una funcionalidad similar. Esfuércese por eliminar dependencias. – skyfoot

+0

Permítanme reformular eso, muy a menudo necesita una sesión de depuración en la que debe seguir una solicitud desde el nivel superior de su servidor a los dlls 'componentes'. Se da cuenta de que hay un problema en el componente que debe solucionarse, pero hacerlo cuando el componente es un DLL que necesita para iniciar la solución del componente, reconstruir el componente y luego tomar los dlls construidos y actualizar los dlls que la aplicación/proyecto es apuntando a. En general, es un poco faf, así que tenemos una gran solución. ninguna de las dos opciones es ideal. ¿Te suena familiar este escenario o solo soy yo? – Squirrel

1

Creo que la respuesta más cercana que he encontrado es que incluye todos los proyectos en la solución y también un proyecto dll que al compilarse enviaría los prod/canned dlls al directorio de salida.

Luego, al usar diferentes configuraciones, pude cambiar entre la configuración de depuración con los proyectos que se están construyendo a la configuración de Release con solo el proyecto dll que se está construyendo.

Se lo probará e informará de nuevo ....

+0

Hola ardilla, ¿cómo te funcionó? Tengo el mismo problema que tu. Gracias. – toddmo

Cuestiones relacionadas