Depuración de una DLL dinámicamente cargada de otro AppDomain en Runtime

Question

Bien, después de resolver cómo cargar en caliente una DLL en una aplicación en ejecución en Runtime (ver mi previous post), he notado que los puntos de interrupción insertados en la DLL recién cargada no son golpear.

Situación
Tengo una aplicación de servidor que quiero evitar la terminación/volver a ejecutar cada vez que hago un cambio en un archivo DLL cargadas dinámicamente (por reflexión)

Meta
Aquí es lo que estoy tratando de hacer (soy consciente de que esto puede no ser posible per se):

• Run aplicación.exe
• carga en ella Process.dll en newAppDomain y proceso de ejecución
• depuración Process.dll
• Unload Process.dll
• Editar proceso código, recompilar Process.dll
• Recarga dinámicamente en Application.exe
• Debug Pro cess.dll
• etc ...

Problema
he notado que cuando aplicación.exe se pone en marcha en modo de depuración, código que se carga desde otro dominio de aplicación es inalcanzable por el depurador asociado a aplicación.exe (supongo que si simplemente inicie aplicación.exe directamente del archivo ejecutable, no hay manera de conseguir VS depurador para depurar cualquier cosa, inluding el DLL recién cargada)

solución Prossible
Una solución solución (feo) es separar la "inyección" de la DLL en la aplicación se ejecuta en un ejecutable independiente, que sería, entonces, controlable por el VS depurador

I mus admitir que estoy un poco confundido . ¿Alguna idea eficiente y limpia?

Answer 1

¿Poniendo System.Diagnostics.Debugger.Break() en su DLL donde actualmente tiene puntos de interrupción, haga un descanso correctamente?

http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.break.aspx

Si no me siento inclinado a estar de acuerdo con Sam, que descargan está fallando, o va a cargar una biblioteca diferente de lo que piensa.

Answer 2

Dado que puede ayudar a los demás (ya que este fue un resultado de búsqueda superior para mí), descubrí que agregar una referencia al archivo DLL al "otro" proyecto permitía depurar el ensamblado "inyectado". Si bien no implementaré mi solución de esta manera, me permitió al menos depurar el código que se está inyectando para resolver un problema con un código estable.Esto sugiere que el IDE examina las referencias al determinar la identidad del ensamblado (o similar).

En este escenario, un DebugBreak() no hace nada, el depurador VS no se señalará sin la referencia que se agrega. No probé, pero me imagino que cualquier otro depurador habría sido señalado muy bien, así que de nuevo esto sugiere que el IDE está ignorando explícitamente la señal (el otro DebugBreak() funciona bien)

Como desarrollador veterano de .NET tengo decir que este problema es nuevo para mí, es decir. Diría que es una apuesta segura que si cargamos Windows 2000, VS.NET 2001-2002 y este mismo código de prueba, la señal de interrupción está bien.

En función de la publicación previa de OP es muy probable que el ensamblaje que se está cargando se cargue con una identidad distinta, incluso si es el mismo ensamblaje pero se carga desde una ubicación/mecanismo diferente (por ejemplo) el CLR lo identificará como un conjunto único, en consecuencia también lo hará el IDE.

Algunos lectores pueden o no pueden encontrar LoaderOptimization de valor en ciertos escenarios donde están cargando el mismo conjunto entre aplicaciones y notan que el mismo ensamblaje se está cargando varias veces.

HTH alguien, me quedé perplejo durante aproximadamente una hora. Gracias.