visual studio puntos paso modo interrupcion encuentra ejecutar debuggear como aplicacion c++ visual-studio unit-testing boost console

c++ - puntos - ¿Cómo hago para que Visual Studio se detenga después de ejecutar una aplicación de consola en modo de depuración?



la aplicacion se encuentra en modo de interrupcion visual studio 2017 (16)

Tengo una colección de pruebas de la unidad Boost que quiero ejecutar como una aplicación de consola.

Cuando estoy trabajando en el proyecto y ejecuto las pruebas, me gustaría poder depurar las pruebas, y me gustaría que la consola permanezca abierta después de que se ejecuten las pruebas.

Veo que si ejecuto en modo de lanzamiento, la ventana de la consola permanece activa después de que el programa sale, pero en el modo de depuración este no es el caso.

No quiero agregar ''sistema ('' pausa '');'' o cualquier otro truco como leer un personaje en mi programa. Solo quiero hacer que Visual Studio se detenga después de ejecutar las pruebas con la depuración como lo haría si estuviera ejecutando en modo de lanzamiento. También me gustaría que la salida de las pruebas se capturara en una de las ventanas de salida de Visual Studio, pero también parece ser más difícil de lo que debería ser.

¿Cómo puedo hacer esto?


Acabo de copiar desde http://social.msdn.microsoft.com/forums/en-US/Vsexpressvc/thread/1555ce45-8313-4669-a31e-b95b5d28c787/?prof=required :

Lo siguiente funciona para mí :-)

////////////////////////////////////////////////// ///////////////////////////////////

Aquí hay otra razón por la cual la consola puede desaparecer. Y la solución:

Con el nuevo Visual Studio 2010, puede ver este comportamiento incluso cuando usa Ctrl + F5, también conocido como "iniciar sin depuración". Esto es más probable porque creó un "proyecto vacío" en lugar de una "aplicación de consola Win32". Si crea el proyecto como una "aplicación de consola Win32" puede ignorar esto ya que no se aplica.

En las versiones anteriores, se usaría el subsistema de la consola de forma predeterminada incluso si seleccionó "proyecto vacío", pero no en Visual Studio 2010, por lo que debe configurarlo manualmente. Para ello, seleccione el proyecto en el explorador de soluciones a la derecha o a la izquierda (probablemente ya esté seleccionado para que no tenga que preocuparse por esto).

Luego seleccione "proyecto" en los menús desplegables de la barra de menú, luego seleccione "propiedades de nombre de proyecto" → "propiedades de configuración" → "enlazador" → "sistema" y configure la primera propiedad, la propiedad de "subsistema" desplegable como "consola (/ SUBSISTEMA: CONSOLA) ". La ventana de la consola ahora debería permanecer abierta después de la ejecución como de costumbre.

////////////////////////////////////////////////// ///////////////////////////////////


Agregar la siguiente línea hará una pause simple de MS-DOS que no muestra ningún mensaje.

system("pause >nul | set /p /"=/"");

Y no hay necesidad de Ctrl + F5 (que hará que su aplicación se ejecute en modo de lanzamiento)


En Boost.Test, existe el parámetro --auto_start_dbg para irrumpir en el depurador cuando falla una prueba (en una excepción o en una falla de aserción). Por alguna razón, no funciona para mí.

Ver http://www.boost.org/doc/libs/1_40_0/libs/test/doc/html/utf/usage-recommendations/dot-net-specific.html

Por esta razón, he creado mi test_observer personalizado que irrumpirá en el depurador cuando hay una falla de aserción o una excepción. Esto está habilitado en las compilaciones de depuración cuando estamos ejecutando bajo un depurador.

En uno de los archivos fuente de mi unidad de archivo EXE de prueba, he agregado este código:

#ifdef _DEBUG #include <boost/test/framework.hpp> #include <boost/test/test_observer.hpp> struct BoostUnitTestCrtBreakpointInDebug: boost::unit_test::test_observer { BoostUnitTestCrtBreakpointInDebug() { boost::unit_test::framework::register_observer(*this); } virtual ~BoostUnitTestCrtBreakpointInDebug() { boost::unit_test::framework::deregister_observer(*this); } virtual void assertion_result( bool passed /* passed */ ) { if (!passed) BreakIfInDebugger(); } virtual void exception_caught( boost::execution_exception const& ) { BreakIfInDebugger(); } void BreakIfInDebugger() { if (IsDebuggerPresent()) { /** * Hello, I know you are here staring at the debugger :) * * If you got here then there is an exception in your unit * test code. Walk the call stack to find the actual cause. */ _CrtDbgBreak(); } } }; BOOST_GLOBAL_FIXTURE(BoostUnitTestCrtBreakpointInDebug); #endif


En realidad, sería más esfuerzo, pero podría simplemente construir en VS.Net, ejecutarlo desde la línea de comando regular (cmd.exe), y luego adjuntarlo al proceso después de que comience a ejecutarse. Probablemente esta no sea la solución que está buscando.


Establezca un punto de interrupción en la última línea de código.


Haga una línea de lectura al final (es la "forma cochina", como decimos en Colombia, pero funciona):

static void Main(string[] args) { . . . String temp = Console.ReadLine(); }


Inicié la aplicación con F11 y obtengo un punto de interrupción en algún lugar de unit_test_main.ipp (puede ser un código de ensamblaje). Utilizo shift-f11 (Step out) para ejecutar la prueba unitaria y obtener la siguiente instrucción de ensamblaje en el CRT (normalmente en mainCRTStartup ()). Uso F9 para establecer un punto de interrupción en esa instrucción.

En la siguiente invocación, puedo iniciar la aplicación con F5 y la aplicación se romperá después de ejecutar las pruebas, por lo tanto, me da la oportunidad de echar un vistazo a la ventana de la consola


Intenta ejecutar la aplicación con la combinación Ctrl + F5 .


La prueba Boost ofrece las siguientes recomendaciones de uso para Visual Studio que le permitirán ejecutar las pruebas unitarias automáticamente al final de la compilación y capturar el resultado en la ventana de compilación.

El buen efecto secundario de este truco es que le permite tratar las fallas de prueba como errores de compilación. "... podría pasar por alto estos errores utilizando los métodos abreviados de teclado / clics del mouse habituales que utiliza para el análisis de errores de compilación ..."



Si se trata de una aplicación de consola, use Ctrl + F5 .


Solo use una biblioteca de registro, como log4net, y haga que se registre en un archivo appender.


También puede configurar su ejecutable como una herramienta externa y marcar la herramienta para Usar la ventana de resultados . De esta forma, la salida de la herramienta será visible dentro de Visual Studio, no una ventana separada.


Usaría un comando "esperar" por un tiempo específico (milisegundos) de su elección. La aplicación se ejecuta hasta la línea que desea inspeccionar y luego continúa después de que expire el tiempo.

Incluya el encabezado <time.h> :

clock_t wait; wait = clock(); while (clock() <= (wait + 5000)) // Wait for 5 seconds and then continue ; wait = 0;


Usted dice que no quiere usar el system("pause") hackeo. Por qué no?

Si es porque no desea que el programa le pregunte cuándo no se está depurando, hay una forma de evitarlo. Esto funciona para mí:

void pause () { system ("pause"); } int main (int argc, char ** argv) { // If "launched", then don''t let the console close at the end until // the user has seen the report. // (See the MSDN ConGUI sample code) // do { HANDLE hConsoleOutput = ::GetStdHandle (STD_OUTPUT_HANDLE); if (INVALID_HANDLE_VALUE == hConsoleOutput) break; CONSOLE_SCREEN_BUFFER_INFO csbi; if (0 == ::GetConsoleScreenBufferInfo (hConsoleOutput, &csbi)) break; if (0 != csbi.dwCursorPosition.X) break; if (0 != csbi.dwCursorPosition.Y) break; if (csbi.dwSize.X <= 0) break; if (csbi.dwSize.Y <= 0) break; atexit (pause); } while (0);

Simplemente pego este código en cada nueva aplicación de consola que estoy escribiendo. Si el programa se está ejecutando desde una ventana de comando, la posición del cursor no será <0,0>, y no llamará a atexit() . Si se ha iniciado desde su depurador (cualquier depurador), la posición del cursor de la consola será <0,0> y se ejecutará la llamada atexit() .

Obtuve la idea de un programa de ejemplo que solía estar en la biblioteca de MSDN, pero creo que se ha eliminado.

NOTA: La implementación de Microsoft Visual Studio de la rutina system () requiere que la variable de entorno COMSPEC identifique el intérprete de línea de comando. Si se descompone esta variable de entorno, por ejemplo, si tiene un problema en las propiedades de depuración del proyecto de Visual Studio para que las variables de entorno no se pasen correctamente cuando se inicia el programa, entonces fallará de forma silenciosa. .


http://connect.microsoft.com/VisualStudio/feedback/details/540969/missing-press-any-key-to-continue-when-lauching-with-ctrl-f5

En las versiones anteriores, se usaría el subsistema de la consola de forma predeterminada incluso si seleccionó "proyecto vacío", pero no en 2010, por lo que debe configurarlo manualmente. Para ello, seleccione el proyecto en el explorador de soluciones a la derecha o a la izquierda (probablemente ya esté seleccionado para que no tenga que preocuparse por esto). Luego seleccione "proyecto" en los menús desplegables de la barra de menús, luego seleccione "propiedades de nombre de proyecto"> "propiedades de configuración"> "enlazador"> "sistema" y establezca la primera propiedad, la propiedad de "subsistema" desplegable como "consola (/ SUBSISTEMA: CONSOLA) ". La ventana de la consola ahora debería permanecer abierta después de la ejecución como de costumbre.