3

I just wrote a clever program called helloworld. It's a C#/.NET 4.5 console app. Deep within the twisted nested mazes of logic there's use of Console.WriteLine().

When I'm running this at a command line, it runs and I see the output. I can do other commands and mess around a bit, and later scroll up to see the output again.

Now I'm in Visual Studio, tweaking the source ("Hi" is more efficient than "Hello") and testing by tapping F5. What happens is a console window pops up and immediately vanishes. I have no idea what the program printed. How can I see the output?

I don't want to modify my source at all. After searching for solutions, I find some who say to use Console.ReadKey() - but then it would suck to be using the program at the command line. There's no real reason the user should have to tap a key when the program has already done its work. Even if i go with this, there's the problem of the output disappearing when the console window closes after a key tap.

I don't want to use Debug.WriteLine() which does write to the output window in VS, but doesn't write ordinary output for the end user to see.

I have discovered ctrl-F5, which runs the program as if it had a final Console.ReadKey() line, but there's still the problem of when I tap any key, all the output vanishes along with the window. Three minutes later, I'm thinking "Oh wait, did it print 'Hello' or 'Helo'?" No way to check.

Seems like the Visual Studio IDE should somehow capture all that a freshly built program writes to its stdout or the Microsoft equivalent thereof, and show it in its "Output" panel, or some panel, for later scrutiny. Maybe it does do this, and I don't yet know the trick to it? Seems like this would be a common desire among millions of C# developers.

DarenW
  • 16,549
  • 7
  • 63
  • 102
  • Good question. The only persistent state is in the output window, so it sounds like you would need to write twice. Once to the console, and once to the debugger. – BradleyDotNET Dec 18 '14 at 22:44
  • Personally speaking, I wouldn't want the IDE to try to second guess what I wanted it to do, I'd want consistent behaviour regardless of from where the code was being executed. – dyson Dec 18 '14 at 22:58
  • Have you heard about TraceListeners? One stream, with multiple possible destinations. – Ben Voigt Dec 18 '14 at 23:09
  • possible duplicate of [Preventing console window from closing on Visual Studio C/C++ Console application](http://stackoverflow.com/questions/1775865/preventing-console-window-from-closing-on-visual-studio-c-c-console-applicatio) – DarenW Dec 31 '14 at 21:07

4 Answers4

1

If you're working on a .NET Core console application (or .NET Framework via the .NET SDK) using Visual Studio 2019, the behaviour of leaving the console window open after the program has executed will now happen by default:

The Microsoft Visual Studio Debug Console window

Specifically:

This should prevent the need to add Console.Read() calls to console apps to prevent the console window from closing immediately after the program has finished executing. The launched console window is also re-used for subsequent runs, so if you’re used to using ctrl+f5, you won’t have lots of console windows to close after you’ve launched your application a few times.

Rob
  • 45,296
  • 24
  • 122
  • 150
0

The reason it closes automaticly is because it's done running the program. If you want to see what it did, make it need a new command like hitting any key. The Console.ReadKey(); pauses it and waits for a User to hit a key to continue. Put that command after the commands of instruction you are doing and it will pause it until you hit any key.

Console.ReadKey(); // Pauses until you hit any key

0

You can also run your program pressing F10 (executes one line by one), with F11 (goes inside a function).

The other option you have is to set breakpoints in Visual Studion and run the program by pressing F5 - it will stop at the next breakpoint. And the breakpoints can have conditions - i.e. conditional breakpoints.

msporek
  • 1,187
  • 8
  • 21
0

Some options are: 1. wrap #if DEBUG around Console.ReadKey() 2. run directly from an open terminal 3. create a Test project - but again you'll need Console.ReadKey() to stop it closing.

Bacchus
  • 121
  • 2