problema redirigir la salida de depuración en un archivo mediante escucha de seguimiento

Question

He creado un oyente de depuración para redirigir la salida de la ventana de depuración/consola a un archivo (con una pila de llamadas), usando el siguiente código:

void SomeMethod() 
{ 
    // Create a file for output .txt. 
    Stream debugFile = File.Create(fileName); 

    // create TextWriterTraceListener named "file" 
    TextWriterTraceListener debugWriter = new TextWriterTraceListener(debugFile, "file"); 

    // add to debug listeners 
    Debug.Listeners.Add(debugWriter); 
    // set callstack to be shown 
    Debug.Listeners["file"].TraceOutputOptions |= TraceOptions.Callstack; 
    // set auto-flush 
    Debug.AutoFlush = true; 
} 

pero la salida no redirigirá al archivo que especifiqué, siempre está vacío.

Llamo esto desde el constructor en mi formulario principal. ¿El lugar donde lo llamo es un problema?

Lo que estoy tratando de lograr aquí es tener las excepciones a la ventana de resultados de depuración colocado en un archivo con una pila de llamadas, para que pueda encontrarlos y corregirlos.

ACTUALIZACIÓN: Después de algunas investigaciones que llegó a la conclusión de que la adición de un nuevo TraceListener a la colección de depuración Listeners no redirige la salida de la depuración/consola. En realidad, solo responde a los métodos Write, WriteLine etc. al igual que el escucha predeterminado. El problema persiste: ¿Cómo capturar el resultado de la ventana Depuración/Consola y cómo obtener el seguimiento de la pila de las excepciones que aparecen allí?

¿Alguien tiene alguna idea?

Answer 1

He aquí un artículo que responde a una parte de mi pregunta: http://www.codeproject.com/KB/trace/DbMonNET.aspx

es decir, la forma de capturar la salida de la ventana de depuración/consola. Pero, parece que no hay forma de obtener el seguimiento de la pila de esta salida. Mirando desde esta perspectiva, parece un mal enfoque de todos modos.

nuevas investigaciones: Parece que estas excepciones están apareciendo porque se manejan de alguna otra DLL que no está vinculada correctamente, y que se manejan allí en vez de mis bloques try/catch. Este es probablemente el lugar donde debería buscar mi error, es decir, donde hay una referencia de DLL, debería agregar una referencia de proyecto.

más investigación: Habilitar romper a excepciones en el menú principal de Visual Studio: Depuración -> Excepciones -> Comprobar el tipo de excepciones que desea la aplicación para romper al (Common Language Runtime) ... No hay mejor forma de lidiar con las excepciones.