2010-05-26 14 views
6

Esto es similar a Add Non-GAC reference to project pero las soluciones presentadas allí no parecen ayudar.Versión de DLL de referencia no GAC en Visual Studio 2010

Tengo una biblioteca WinForms UI (Krypton de ComponentFactory) instalada en el GAC. Hay un error que quiero rastrear en esa biblioteca, así que agregué el código fuente a mi solución, eliminé las referencias antiguas de mi proyecto WinForms a las DLL Krypton, las volví a agregar como referencia de proyecto, me aseguré de que Copy Local está establecido en verdadero, comprobé dos veces que la ruta (en la pestaña de propiedades de referencia) apunta a mi proyecto local, y ...

... la versión GAC se sigue utilizando durante la depuración. No puedo establecer un punto de interrupción en la fuente de Krypton, Debugger.Break() u otros cambios de código para no ejecutar, y cuando inicio el depurador de Visual Studio 2010, veo un mensaje Cargando desde ... GAC_MISL relacionado con las DLL de Krypton en el VS 2010 barra de estado. Los archivos DLL no se copian en la carpeta de depuración de WinForm.

¿Cómo puedo hacer referencia a la versión de "proyecto" de los archivos al depurarlos mientras los dejo registrados en el GAC?

Respuesta

5

El CLR será siempre mira primero en el GAC. No dude en utilizar gacutil.exe/u para eliminarlos. La piratería de [AssemblyVersion] también funcionaría para que la copia de GAC no coincida.

+0

gacutil parece estar ubicado en varios lugares: intente buscar en 'C: \ Archivos de programa (x86) \'. Esta es una de las rutas en mi servidor: 'C: \ Archivos de programa (x86) \ Microsoft SDKs \ Windows \ v8.0A \ bin \ NETFX 4.0 Tools \ x64' – northben

+0

¿Sigue siendo cierto? ¿Hay ahora forma de priorizar el proyecto al que se hace referencia en lugar del GAC? Me parece una gran falla en un contexto de depuración; Microsoft debe abordar este mi humilde opinión. –

+0

Era cierto, sigue siendo cierto, siempre será cierto. Tendrás que hablar con Microsoft, pero puedes estar seguro de que van a ignorarte completamente :) Abusar del GAC en tu máquina de desarrollo es simplemente una mala idea, es un detalle de implementación que solo importa en el máquina del usuario Esa es la verdadera víctima de DLL Hell. Tener el infierno en una máquina de desarrollo es un problema autoinfligido. –

Cuestiones relacionadas