Avoiding “Press any key to continue” when running

Question

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.

Answer 1

Have you tried (c#)?

Environment.Exit(0)

Answer 2

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.

Answer 3

Well, at least in Visual Studio 2010, typing

 Console.ReadKey(true);

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

Answer 4

There's a great answer here in a very related question:

https://stackoverflow.com/a/15135181/122687

I think it's better than the accepted answer because it doesn't require you to call AllocConsole and do set up any IO redirection. I don't know how easily and robustly IO redirection can be set up.

Answer 5

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.