We Keep Coding

Hybrid Winforms/Console Application terminates correctly but "Enter" has to be hit to get consoleprompt back

I have a hybrid app which basically only shows the available commandline modifiers when started from the command prompt. There is then no windows Application code involved or initialized. If started from the commandline I try to attach the console to have ability for seeing output via Console.Writeline. I have now a "--help" command which only prints out the available commands and then exits the application. Basically nothing from the WinForm application is executed or initialized at this stage. The output to the console works fine, however the process is terminated as seen e.g. ProcMon, but I have to hit "Enter" to get the commandline prompt back. I use "FreeConsole", Environment.Exit, Application.Exit or the simple direct "return Exitcode", but it still waits for an "Enter" char until the prompt is back. I'm very sure the process is terminated as I can see the termination in ProcMon. What can be the cause for this behaviour ?
I'm also using the log4net ColoredConsoleAppender whose output could be seen, but I meanwhile removed it from the configuration to have no interference here. This didn't changed also the described behaviour.

Explanation of 'Press Any key to continue.... '

It just came to attention that every time we run the c# console application, at the end it shows text stating "Press any key to continue... ".
And the moment you hit any key, it terminates the console/program.
In actual program there is no mentioning about such text printing on standard output console, then from where and why it comes out on screen?
Can someone explain the logic behind?
Code:
static void Main(string[] args)
{
Console.WriteLine("Test Application");
}
Output:
Test Application
Press any key to continue . . .

It has nothing to do with your application itself. When you double-click on the output EXE file you'll not see it. It is only when we run the app from within Visual Studio without the debugger attached when this behavior is seen.
When you press Ctrl+F5, Visual Studio is running your app in a way that causes the console window to remain open.
I think it comes from cmd parameters that are used. Something like :
%COMSPEC% /k "C:\VS\MyApplication.exe"

Do you use CodeBlocks ?
If yes, it is a Feature of CodeBlocks. That you can read the Output without to write something like getChar() at the end that the console stay open. Otherwise it would close instantly and you can't read the output.

In normal application the console will close when done and that is the expected behaviour. This prompt simply helps you to check the results of your code when you are writing your application and you do not have to put (and remember about later removal) of the:
Console.ReadLine();
in your application just to test it and see what the output is.

Output screen disappears suddenly in C# console application?

I am writing a simple C# console application in VS 2013 but the problem is that output screen flashes for a moment and disappears suddenly . I use the alternate way and write Console.Readline() method in the end and problem is fixed .So but i personally think that this is just a trick to stop the screen and not the proper way.So can anyone explain me the proper way of doing this ??

The program immediately closes because there's nothing stopping it from closing. Insert a breakpoint at return 0; or add Console.Read(); before return 0; to prevent the program from closing.
After you are done with your program, press Ctrl+F5 ( Run without
debugging). This will prompt before closing the window and this is
what you want.
Or use this line at the end
Console.ReadKey();

No, this is the correct way of doing it. Console.ReadLine() and Console.ReadKey() are a blocking statement: they halt the thread to wait for input before continueing. If you wouldn't do this the program would reach its end and thus exit the console.
In a larger console program you might have a while(running) loop instead and a GUI won't have this problem until its GUI thread is explicitly stopped (closing the window), but for a simple console app you can just use this 'trick'.

Yes, as long as you don't stop the application it keeps running and ends when done processing.
That's why you need the Console.ReadLine(), it stops processing and waits until you tell it to continue.

when you run the program in Debug mode if you do'nt have any BreakPoints or if .NET engine does not need to Read IO from user then it just finishes the excution without waiting anymore.
if you want to stop the execution at the end want to see the console screen you can either use any IO Read Statements as below:
Console.ReadLine();
Console.Read();
Console.ReadKey();
OR
You can run your program in without Debugging mode by simply pressing Ctrl+F5

Difference between console and winforms applications when running from cmd

I have a winforms application that sometimes used from the command line.
Here is the code (simplified of course):
[STAThread]
static void Main()
{
AttachConsole(ATTACH_PARENT_PROCESS);
Console.WriteLine("Hello");
/*Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());*/
}
If that was a console application the output could be:
C:\ConsoleApplication\ConsoleApplication.exe
Hello
C:\ConsoleApplication\_
In case of windows application its actually:
C:\WindowsApplication\WindowsApplication.exe
C:\WindowsApplication\Hello
_
Can anyone tell me why do we have such difference and is it possible to make my windows application to behave like console when running from cmd?
edit:
I want my windows application to behave like console when running from cmd:
C:\WindowsApplication\WindowsApplication.exe
Hello
C:\WindowsApplication\_
solution:
As a result I'm running my application as
C:\WindowsApplication\start /wait WindowsApplication.exe

Yes. The difference is that cmd.exe is aware of the kind of executable. It knows to wait for the process to terminate when it is a console mode app. It does not wait when it is a regular Windows gui app. Trusting that it will create its own window. So it displays the command prompt again, your output gets appended to that. You'll also have trouble using Console.ReadLine() btw.
You'd have to start your program with start /wait yourapp.exe to force cmd.exe to wait. Calling AllocConsole() instead is the only universal fix. Also takes care of creating the console when your app gets started from a shortcut.
AllocConsole() is fairly disorienting. Consider writing a tiny console mode app that does nothing but Process.Start + WaitForExit to start your main program. Perhaps also munging the command line arguments. Now you get the blocking behavior back. If you rename the executable to mainapp.com (to start mainapp.exe) then the difference is hidden quite well, a trick that VS uses as well (devenv.exe vs devenv.com).

There is a flag in the exe, telling if this is a console app or gui (winform in your case) app. When you start an app, Windows will detach the console from the program if it is a console app. You can use the following approach to achieve what you want:
Compile you application as gui, name it mytool.exe
Create a doskey alias mytool=start /wait c:\path\mytool.exe $*
In this way, when you start mytool.exe in explorer or shortcut, you start a normal windows application; when you type in mytool in console, you actually start it by "start /wait", which will not detach the console regard less of the flag. (However, you do need to attach to parent console in your app if you want to output/input something from the console.

You want the Windows App to block the Console thread as long as it's running, if I understand you correctly. I have no idea why you would do that, but I can give a shot at how it might work:
Change the WinForms application to a console application, that opens a form. This way it would block the console thread while displaying a window.

What exactly is a "Console"?

I am trying to writing a console application. It has its original console, let's name it console A. And I want this application to do the following things via C#:
Open another console B in another thread, then get input from A and output it to B;
type a command in A, such as dir, and show the output in B;
while doing the above things (still not done yet. X_X ), I find myself lack a through understanding of what a console window is, and how it is assigned to a console application, especially the very first console when my console application starts to run. Could some one shed some light on me?
Is console window physically a memory area in the video memory? Or something else?
Could different threads within the same process have different console of its own for its own I/O?
Many thanks.
Now I am using one console application to start another console application in a new process. Thus I can have 2 consoles output at the same time.
My understanding now is that, for Windows OS, a console is a special window, and it's a system resource that OS assigned to the application without-a-UI as a necessary user interface. Windows OS handles the wiring between the system-prepared console window with our UI-less application.

In Windows terms, a Console is a textual GUI window that you see when you run "cmd.exe". It allows you to write text to, and read text from, a window without the window having any other UI chrome such as toolbars, menus, tabs, etc,..
To get started you'll want to load Visual Studio, create a new project and choose "Console Application". Change the boilerplate code that Visual Studio produces to:
using System;
using System.Text;
namespace MyConsoleApp
{
class Program
{
static void Main(string[] args)
{
Console.Write("Hello, world!");
Console.ReadKey();
}
}
}
When you run your application, a console window will open with the text "Hello, world!" and it'll stay open until you press a key. That is a console application.
Is console window physically a memory area in the video memory? Or something else?
It's not physically a memory area in video memory, it's "something else". The Wikipedia Win32 console page gives a fairly robust descrption of the ins and outs.

A console application has only one window. It does not have window management functions in order to spawn child "consoles".
You can start additional console applications, but these are separate entities.

No. It's a windows GUI subsystem. In WinAPI there are functions to work with console: http://msdn.microsoft.com/en-us/library/ms682073%28VS.85%29.aspx

A (OS) console is a process (containg one or more threads of executions, all of them sharing the same memory space), and this process has:
standard input (a stream of input bytes), what you key in
standard output (a stream of output bytes), what the program prints
standard error (a stream of output bytes), what the program prints when it's complaining about something
So if you want to create another console (from .Net) and link the input/outputs I understand you have to create a process (executing "cmd.exe" by example).
I don't know the API of .Net for process manipulation but if it's like Java you can hook up stdin, out and err so you can play with your created process from the original one.

A windows application can have one console, or no console, it can't have more than one. See the documentation for AllocConsole.
The console is basically an emulation of the 'pre-Windows' days when there would literally be a 'control console' i.e. a keyboard and screen attached to a mainframe computer.
To do what you want you could spawn another process with its own console and communicate between the two, or make a GUI application which looks like a console window.