Avoiding "Press any key to continue" when running console application from Visual Studio
Asked Answered
A

7

33

When running a console application in Visual Studio via "Start without Debugging" (Ctrl+F5), the console remains open at the end of the run asking to

Press any key to continue . . .

thus requiring to activate the window and hit a key. Sometimes this is not appropriate.

Why this matters: At the very moment I write json serialisation code, my workflow goes like this:

  • adapt c# code
  • run a console app that writes file out.json
  • view out.json in the browser with a json viewer

do this again and again, no need to debug anything, just trimming serialisation and check output is good.

It is workflows like this, where the "press any ..." behavior is hindering as it requires the steps

  • activate the console window
  • press key .

No answers:

  • Starting the application outside VS in a separate console is not an answer.
  • Saying, you dont need this.
Adallard answered 27/7, 2013 at 12:18 Comment(8)
There is no great benefit to first having to start a large program like VS, only to start your console app. You avoid the message by creating a shortcut to your program on the desktop.Neglectful
Would automatically running the application after each build be acceptable? I.e. set "$(TargetPath)$" as the post-build command line.Liatrice
thx reima, "$(TargetPath)" is in fact a cool idea ;-)Adallard
It's been a while since I've written a console application but does changing it to Release mode have any effect?Millsap
@brad: does not changeAdallard
@hans passant, great insight, apparently 2 folks helped it, me not, as stated, "Starting the application outside VS in a separate console is not an answer.", sorry.Adallard
Not much point in changing the question and then pointing out that my comment isn't helpful, is there? Don't mistake a comment for an answer btw.Neglectful
Remember, there is a history function here, you can use it to proove the statement was in since version 1.Adallard
J
16

I'm pretty sure that you cannot affect or change this behavior.

As you mention, it has nothing to do with your application itself, because it doesn't do it when you double-click on the EXE. You only see this effect when you run the app from within Visual Studio without the debugger attached.

Presumably, when you invoke Ctrl+F5, Visual Studio is running your app in a particular way that causes the console window to remain open. I can think of two ways it might be doing it:

%COMSPEC% /k "C:\Path\To\YourApplication.exe"

or

%COMSPEC% /c ""C:\Path\To\YourApplication.exe" & pause"

With either of these, the pausing behavior you're seeing is baked right into the command used to launch your app and is therefore external to your application. So unless you have access to the Visual Studio sources, you're not going to change it. Calling an exit function from your app won't have any effect because your app has already quit by the time that message appears.

Of course, I can't see why it really matters, aside from an issue of curiosity. This doesn't happen when you start the app with the debugger attached, which is what you'll be doing 99% of the time when you launch the app from the IDE. And since you don't ship Visual Studio along with your app, your users are going to be starting the app outside of VS.


In response to the updates made to your question, the best solution would be to change your app so that it is not a console application. This behavior doesn't affect standard Windows applications; when they get closed, they close for good.

If you do not require any output on the console window, then this is very simple to do: just change the "Application type" in your project's properties. A Windows Forms application will work just fine. If you do not display a window (aka form), one will not be automatically created. This is the difference between regular Windows applications and console applications, which always create a console window, whether you need one or not.

If you do need to display output on the console window, you have a couple of options:

  1. Create and use a simple form with a ListBox or ListView control. Each line that you would normally output to the console, you add as a new item to the list control. This works well if you're not using any "advanced" features of the console.
  2. P/Invoke and call the AllocConsole function to create a console that your Windows application can use. You do not need a form for this.
Janeyjangle answered 27/7, 2013 at 12:54 Comment(4)
Changing output type to "Windows Application" causes exactly the behavior I was looking for, cool, thx.Adallard
@CodyGray "I can't see why it really matters" Because sometimes you want a rapid compile/execute cycle without attaching the debugger (which slows down application startup). For instance, I'm testing an app that outputs a document file. The documents contents are reflected in real time in an external application. I'm doing visual tweaks, via code, and I really just want to tweak, tweak, run, tweak, run. I don't want to start the debugger, and I don't want to dismiss the console window every time.S
When I set the debug mode to release and hit F5 there is no pause break.Laomedon
One funny thing is that VS 2015 does this even for a DLL. I.e. I had a DLL with /SUBSYSTEM:CONSOLE (C++ here) and the debugger is set to run the mother application (which is not console), but VS still displayed the keypress prompt. I'd call this a bug (a shortcut of VS developers). Fixed by setting /SUBSYSTEM:WINDOWS in DLL.Mixon
L
10

I found a solution that works if you are using python (I could not test anything else). You need to go to

Tools -> Options -> Python Tools -> Debugging

Uncheck Wait for input when process exits normally.

I hope you can apply this somehow to your problem.

Laruelarum answered 27/5, 2014 at 15:35 Comment(0)
P
5

2020 UPDATE : Microsoft has listened.

enter image description here

It also closes the console in "Start Without Debugging" mode ;)

The setting is a little buried, but works :

enter image description here

Pronouncement answered 16/9, 2020 at 7:56 Comment(3)
As I stated, funnily enough it also works when you lauch Without debugging, so I felt it still applied to you question, 7 years later..Pronouncement
i tried it, for a basic c# console project it had no effect tough. at least i checked it, who knows what its good for ;)Adallard
I really only saw this very recently, you have the latest VS version ?Pronouncement
O
1

Well, at least in Visual Studio 2010, typing

 Console.ReadKey(true);

Removes the "Press any key to continue....."

Odont answered 25/3, 2016 at 13:56 Comment(1)
Yes, I realized this magic . For my situation this did not help since it adds handcoded keypress instead .Adallard
S
1

According to the VS2019 documentation:

Automatically close the console when debugging stops: Tells Visual Studio to close the console at the end of a debugging session.

It works, but only if you make sure your project starts with the debugger on. This sounds trivial, but I was trying at first with a solution with two projects, one Console one to copy files to use in my app, the other to run the actual app. I set the Console one to Start without debugging because I don't need debugging on it, but that did not close it after it ran. Only when setting it to Start (with debugging) this option worked.

Sulphurize answered 12/11, 2020 at 4:44 Comment(0)
M
1

I found a fix and its very easy. I tested this with a C++ console application so it might not work with something else but you can still give it a shot. With this you can remove the Press a key to continue... also if you use Start without debugging and you don't need to set Automatically close the console when debugging stops.

All you have to do is to go to:

Solution(Right Click) > Properties > Linker > System

the set:

Subsystem > Not Set
Moke answered 1/2 at 22:42 Comment(0)
F
-1

In vs2017 you have to uncheck the python environment setting under the vs-options:

in german: Auf Eingabe warten, wenn der Prozess normal beendet wird

Fond answered 5/9, 2020 at 14:59 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.