Programing

디버그 모드에서 콘솔 응용 프로그램을 실행 한 후 Visual Studio를 일시 중지하려면 어떻게해야합니까?

lottogame 2020. 11. 29. 09:35
반응형

디버그 모드에서 콘솔 응용 프로그램을 실행 한 후 Visual Studio를 일시 중지하려면 어떻게해야합니까?


콘솔 애플리케이션으로 실행하려는 Boost 단위 테스트 모음이 있습니다.

프로젝트에서 작업 할 때 테스트를 실행할 때 테스트를 디버깅 할 수 있고 테스트가 실행 된 후에도 콘솔을 열어두고 싶습니다.

릴리스 모드에서 실행하면 프로그램이 종료 된 후에도 콘솔 창이 계속 표시되지만 디버그 모드에서는 그렇지 않습니다.

'system ( "pause");'를 추가하고 싶지 않습니다. 또는 내 프로그램에 문자를 읽는 것과 같은 다른 해킹. 릴리스 모드에서 실행하는 것처럼 디버깅으로 테스트를 실행 한 후 Visual Studio를 일시 중지하고 싶습니다. 테스트 출력이 Visual Studio의 출력 창 중 하나에서 캡처 된 경우에도 좋겠지 만 그게 당연한 것보다 더 어려워 보입니다.

어떻게 할 수 있습니까?


Boost 테스트는 컴파일이 끝날 때 자동으로 단위 테스트를 실행하고 빌드 창에 출력을 캡처 할 수 있도록 Visual Studio에 대한 다음 사용 권장 사항을 제공합니다 .

이 트릭의 좋은 부작용은 테스트 실패를 컴파일 오류로 처리 할 수 ​​있다는 것입니다. "... 컴파일 오류 분석에 사용하는 일반적인 키보드 단축키 / 마우스 클릭을 사용하여 이러한 오류를 건너 뛸 수 있습니다 ..."


Ctrl+ F5조합으로 응용 프로그램을 실행 해보십시오 .


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

이전 버전에서는 "빈 프로젝트"를 선택한 경우에도 기본적으로 콘솔 하위 시스템 이었지만 2010 년에는 선택하지 않았으므로 수동으로 설정해야합니다. 이렇게하려면 오른쪽 또는 왼쪽의 솔루션 탐색기에서 프로젝트를 선택합니다 (아마도 이미 선택되어 있으므로 걱정할 필요가 없습니다). 그런 다음 메뉴 표시 줄 드롭 다운 메뉴에서 "프로젝트"를 선택한 다음 " project_name 속성"> "구성 속성"> "링커"> "시스템"을 선택하고 첫 번째 속성을 설정하고 드롭 다운 "하위 시스템"속성을 "콘솔 (/ 서브 시스템 : 콘솔) ". 콘솔 창은 이제 평소와 같이 실행 후에도 열려 있어야합니다.


코드의 마지막 줄에 중단 점을 설정합니다.


방금 http://social.msdn.microsoft.com/forums/en-US/Vsexpressvc/thread/1555ce45-8313-4669-a31e-b95b5d28c787/?prof=required 에서 복사했습니다 .

다음은 나를 위해 작동합니다 :-)

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

콘솔이 사라질 수있는 또 다른 이유가 있습니다. 그리고 해결책 :

새로운 Visual Studio 2010에서는 Ctrl+ F5aka "디버깅없이 시작" 을 사용하는 경우에도이 동작을 볼 수 있습니다 . "Win32 콘솔 응용 프로그램"대신 "빈 프로젝트"를 만들었 기 때문일 가능성이 높습니다. 프로젝트를 "Win32 콘솔 애플리케이션"으로 생성하는 경우 적용되지 않으므로 무시할 수 있습니다.

이전 버전에서는 "빈 프로젝트"를 선택한 경우에도 기본적으로 콘솔 하위 시스템 이었지만 Visual Studio 2010에서는 선택하지 않았으므로 수동으로 설정해야합니다. 이렇게하려면 오른쪽 또는 왼쪽의 솔루션 탐색기에서 프로젝트를 선택합니다 (아마도 이미 선택되어 있으므로 걱정할 필요가 없습니다).

그런 다음 메뉴 표시 줄 드롭 다운 메뉴에서 "프로젝트"를 선택한 다음 " project_name 속성"→ "구성 속성"→ "링커"→ "시스템"을 선택하고 첫 번째 속성, 드롭 다운 "서브 시스템"속성을 "콘솔 (/ 서브 시스템 : 콘솔) ". 콘솔 창은 이제 평소와 같이 실행 후에도 열려 있어야합니다.

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


콘솔 애플리케이션 인 경우 Ctrl+를 사용하십시오 F5.


Boost.Test에는 --auto_start_dbg테스트가 실패 할 때 (예외 또는 어설 션 실패시) 디버거에 침입하기위한 매개 변수가 있습니다. 어떤 이유로 그것은 나를 위해 작동하지 않습니다.

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

이러한 이유로 나는 어설 션 실패 또는 예외가있을 때 디버거에 침입 할 사용자 지정 test_observer를 만들었습니다. 이것은 우리가 디버거에서 실행할 때 디버그 빌드에서 활성화됩니다.

내 단위 테스트 EXE 파일의 소스 파일 중 하나에 다음 코드를 추가했습니다.

#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

system("pause")해킹 을 사용하고 싶지 않다고합니다 . 왜 안돼?

If it's because you don't want the program to prompt when it's not being debugged, there's a way around that. This works for me:

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);

I just paste this code into each new console application I'm writing. If the program is being run from a command window, the cursor position won't be <0,0>, and it won't call atexit(). If it has been launched from you debugger (any debugger) the console cursor position will be <0,0> and the atexit() call will be executed.

I got the idea from a sample program that used to be in the MSDN library, but I think it's been deleted.

NOTE: The Microsoft Visual Studio implementation of the system() routine requires the COMSPEC environment variable to identify the command line interpreter. If this environment variable gets messed up -- for example, if you've got a problem in the Visual Studio project's debugging properties so that the environment variables aren't properly passed down when the program is launched -- then it will just fail silently.


It would actually be more effort, but you could just build in VS.Net, run it from the regular command line (cmd.exe), and then attach to the process after it starts running. This is probably not the solution you are looking for however.


Or you could use boost_test "Test Log Output."

http://www.boost.org/doc/libs/1_47_0/libs/test/doc/html/utf/user-guide/test-output/test-log.html

Then it won't matter whether the console window shows up at all AND your build logging can preserve the unit testing output as an artifact for examination on failed builds...


I would use a "wait"-command for a specific time (milliseconds) of your own choice. The application executes until the line you want to inspect and then continues after the time expired.

Include the <time.h> header:

clock_t wait;

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

You could also setup your executable as an external tool, and mark the tool for Use output window. That way the output of the tool will be visible within Visual Studio itself, not a separate window.


I start the app with F11 and get a breakpoint somewhere in unit_test_main.ipp (can be assembly code). I use shift-f11 (Step out) to run the unit test and get the next assembly instruction in the CRT (normally in mainCRTStartup()). I use F9 to set a breakpoint at that instruction.

On the next invocation, I can start the app with F5 and the app will break after running the tests, therefore giving me a chance to peek at the console window


Adding the following line will do a simple MS-DOS pause displaying no message.

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

And there is no need to Ctrl+F5 (which will make your application run in Release Mode)


Just use a logging library, like log4net, and have it log to a file appender.


Do a readline at the end (it's the "forma cochina", like we say in Colombia, but it works):

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

참고URL : https://stackoverflow.com/questions/193469/how-do-i-make-visual-studio-pause-after-executing-a-console-application-in-debug

반응형