Develop Reference

C# Console-Application with no console but winforms

We have an application that is a WinForms-Application. It accepts startup parameters and can perform certain jobs with no UI by using the command line.
Now, we also want some console-output, like for example when using application.exe /help.
The Issue we are now facing is: How to bring both worlds together in a "nice" way:
When setting the Output Type to "Windows Application",all the UI stuff works fine, but Console.WriteLine() doesn't show results when used from cmd.
When setting the Output Type to "Console", generally both things work, BUT: The Application (when used in UI-Mode so to say) raises a console window, that stays open until the application terminates.
Is there a way to bypass the visibility of the console-window?
In the real world, I can find applications using one of three approaches - but I don't like either of them:
Leave the console window open when running in UI-Mode, who cares?
Use user32.dll to hide the window (it still flashes, tho)
Use Windows-Application as Output-Type and show Console-Output as "message boxes", when used from the command line.

I've figured out a solution, thx to #Luaan s comment:
I'm now using the Output Type Windows Application (so, no console window) - but simply registering the Console with the Applications "Parent" Console.
This now behaves as expected:
No console is shown during normal startup.
When used from within an existing console window (ps / cmd) the output is printed, because that consoles are then technically the parent-console of the application.
public class GUIConsoleWriter
{
[System.Runtime.InteropServices.DllImport("kernel32.dll")]
private static extern bool AttachConsole(int dwProcessId);
private const int ATTACH_PARENT_PROCESS = -1;
public static void RegisterGUIConsoleWriter()
{
AttachConsole(ATTACH_PARENT_PROCESS);
}
}
And then, firstline in Main():
static void Main(String[] args)
{
GUIConsoleWriter.RegisterGUIConsoleWriter();
}
Now, using regular Console.WriteLine() works. Ofc. this is limited to writing output, but for the scope of my projects that is sufficent, as input has to be provided with arguments, no interactive console-options.
When another application needs to fetch output programmatically, you ofc. can't do myApp.exe /doSomething but need to do cmd /C myApp.exe /doSomething because the application itself doesn't own a console.
AND you have to manually take care to "exit" your application, after providing output, otherwhise the process won't return.

Console application closes immediately after opening in visual studio

I am trying to open a console application in visual studio built in C#. As soon as I open it, it closes immediately.
I know windows sets this is a a safety default (atleast I think). How do I fix this?
I know I can compile it and create a shortcut and modify the target so it has the location of the command prompt in it before the applications location. Although the programmer who created this has it generating information into the output of visual studio, so it's imperative that I only open it there.
It happens with most applications and not just in visual studio, just in this case I need it to open in VS 2010. I am using Windows 7.

This is an ancient problem and has inspired several funny cartoons:
Let's fix it. What you want to do is prompt the user to press the Any key when the console app was started from a shortcut on the desktop, Windows Explorer or Visual Studio. But not when it was started from the command processor running its own console. You can do so with a little pinvoke, you can find out if the process is the sole owner of the console window, like this:
using System;
class Program {
static void Main(string[] args) {
Console.WriteLine("Working on it...");
//...
Console.WriteLine("Done");
PressAnyKey();
}
private static void PressAnyKey() {
if (GetConsoleProcessList(new int[2], 2) <= 1) {
Console.Write("Press any key to continue");
Console.ReadKey();
}
}
[System.Runtime.InteropServices.DllImport("kernel32.dll")]
private static extern int GetConsoleProcessList(int[] buffer, int size);
}

You can also run the application by pressing (Ctrl + F5) .. This will allow it to run in 'Release' mode, and by default, you will need to press 'return' to close the window.

Try adding Console.ReadKey(); at the end of Main() method. This is a quick and dirty way of stopping the window from closing by itself.

You need to wait for user input. Use either Console.ReadLine(), Console.Read(), or Console.ReadKey().

So, according to here
If your process is the only one attached to the console, then the
console will be destroyed when your process exits. If there are other
processes attached to the console, then the console will continue to
exist (because your program won’t be the last one).
And if we adapt the code to C# you would end up something like this:
using System;
using System.Runtime.InteropServices;
namespace CheckIfConsoleWillBeDestroyedAtTheEnd
{
internal class Program
{
private static void Main(string[] args)
{
// ...
if (ConsoleWillBeDestroyedAtTheEnd())
{
Console.WriteLine("Press any key to continue . . .");
Console.ReadKey();
}
}
private static bool ConsoleWillBeDestroyedAtTheEnd()
{
var processList = new uint[1];
var processCount = GetConsoleProcessList(processList, 1);
return processCount == 1;
}
[DllImport("kernel32.dll", SetLastError = true)]
static extern uint GetConsoleProcessList(uint[] processList, uint processCount);
}
}

How can a Windows Service create a process?

I want to create program that run all the time (not a Windows Service exactly). I want it to have no view to the user.
I would like it to be a process, the reason I don't want it to be service is because I want to create to process and I want one service to start them.
I don't know how to create the program without any UI as if I create console application the CMD open when I run the program.

I'm taking a guess as to what you're trying to do, but here's a really simple console application that runs until you hit the ENTER key. It will print out a line to the console every second.
class Program
{
static void Main(string[] args)
{
using (System.Threading.Timer processTimer = new System.Threading.Timer(DoSomething, "fun", 0, 1000))
{
Console.ReadLine();
}
}
static void DoSomething(object data)
{
Console.WriteLine("doing something {0}...", data.ToString());
}
}
You can replace the contents of DoSomething with what you need your console runner to do.
I hope this helps.

C#: Is it possible to have a single application behave as Console or Windows application depending on switches?

I have a simple application that I would like to sort of automate via switches. But when I do run it via switches I don't really want a user interface showing. I just want it to run, do it's job, print stuff out in the console, and exit. On the other hand if I don't run it with any switches I want the user interface to pop up. And in this case I don't really want a console window hanging around in the background.
Is there any way I can do this, or do I have to create two separate projects, one Console Application and one Windows Application?

Whilst not exactly what you have asked, I've achieved the appearance of this behaviour in the past by using the FreeConsole pInvoke to remove the console window.
You set the output type of the project to be a console application. You then define the extern call to FreeConsole:
[DllImport("kernel32.dll", SetLastError=true)]
private static extern int FreeConsole();
Then, in you Main method you switch based on your conditions. If you want a UI, call FreeConsole before opening the form to clear the console window.
if (asWinForms)
{
FreeConsole();
Application.Run(new MainForm());
}
else
{
// console logic here
}
A console window does briefly appear at startup, but in my case it was acceptable.
This is a bit of a hack though and has a bad smell, so I'd seriously consider whether you do want to go down this route.

From 'The Old New Thing'
How do I write a program that can be run either as a console or a GUI application?
You can't.
(I'll let you click on the article for the details of how to fake it)

Sure, just put a switch statement (or if else construction) in the static main(string[] args), based on arguments passed in command line. I also do this to switch between executing as a service or as a console...
NOTE: Set project type as Console App
[DllImport("kernel32.dll", SetLastError=true)]
private static extern int FreeConsole();
[STAThread]
static void Main(string[] args)
{
if (args.Length == 0 && args[0] == "C") // Console
{
// Run as console code
Console.WriteLine("Running as Console App");
Console.WriteLine("Hit any Key to exit");
Console.ReadLine();
}
else
{
//Console.SetWindowSize(1,1);
//string procName = Assembly.GetExecutingAssembly().FullName;
//ProcessStartInfo info = new ProcessStartInfo(procName );
//info.WindowStyle = ProcessWindowStyle.Minimized;
// EDIT: Thanks to Adrian Bank's answer -
// a better approach is to use FreeConsole()
FreeConsole();
Application.Run(new MyForm());
}
}
EDIT: Thanks to Adrian Bank's answer, FreeConsole() is much better approach to "dispense" with Console window than just minimizing it...

They are two different paradigms, I don't think that using a command line switch like this is a good idea. Why not build the core logic into a console application and then call that from the GUI when needed? This would nicely separate the UI from the implementation but would still provide a way to use the Console app stand alone when needed.

I believe the answer is no, or it was last time I looked into this problem.
The executable is marked as either a windowed application or a console application. You can see this in the properties for you project in Visual Studio, under application, Output type
You could simulate the behavior by having two application, a console application that if executed with no arguments launches the GUI application. You may see a console window flash, unless you ran in from an already open console.

Without implementing your own version of a console window the answer is no. When Windows loads you executable it decides whether or not to give you a console window based on data in the PE header. So you can make a windowed app not have a window but you can't make a windoed app have a console.

You can, but with some drawbacks:
You can prevent having this black window on start up if you compile for subsystem Windows.
But then you have to attach the process to the calling console (cmd.exe) manually via AttachConsole(-1)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681952%28v=vs.85%29.aspx
This alone does not do the job. You also have to redirect the three std streams to the console via these calls:
// redirect unbuffered STDOUT to the console
lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen( hConHandle, "w" );
*stdout = *fp;
setvbuf( stdout, NULL, _IONBF, 0 );
fp = _fdopen( hConHandle, "r" );
*stdin = *fp;
setvbuf( stdin, NULL, _IONBF, 0 );
// redirect unbuffered STDERR to the console
lStdHandle = (long)GetStdHandle(STD_ERROR_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen( hConHandle, "w" );
*stderr = *fp;
setvbuf( stderr, NULL, _IONBF, 0 );
// make cout, wcout, cin, wcin, wcerr, cerr, wclog and clog
// point to console as well
ios::sync_with_stdio();
Sample from: http://cygwin.com/ml/cygwin/2004-05/msg00215.html
The problem with your WinMain call is that windows already has forked out your process so the calling cmd.exe console will have returned from your .exe already and proceed with the next command.
To prevent that you can call your exe with start /wait myexe.exe
This way you also get the return value of your app and you can check it with %errorlevel% as usual.
If there is a way to prevent that process forking with subsystem windows please let me know.
Hope this helps.

how to run a winform from console application?

How do I create, execute and control a winform from within a console application?

The easiest option is to start a windows forms project, then change the output-type to Console Application. Alternatively, just add a reference to System.Windows.Forms.dll, and start coding:
using System.Windows.Forms;
[STAThread]
static void Main() {
Application.EnableVisualStyles();
Application.Run(new Form()); // or whatever
}
The important bit is the [STAThread] on your Main() method, required for full COM support.

I recently wanted to do this and found that I was not happy with any of the answers here.
If you follow Marc's advice and set the output-type to Console Application there are two problems:
1) If you launch the application from Explorer, you get an annoying console window behind your Form which doesn't go away until your program exits. We can mitigate this problem by calling FreeConsole prior to showing the GUI (Application.Run). The annoyance here is that the console window still appears. It immediately goes away, but is there for a moment none-the-less.
2) If you launch it from a console, and display a GUI, the console is blocked until the GUI exits. This is because the console (cmd.exe) thinks it should launch Console apps synchronously and Windows apps asynchronously (the unix equivalent of "myprocess &").
If you leave the output-type as Windows Application, but correctly call AttachConsole, you don't get a second console window when invoked from a console and you don't get the unnecessary console when invoked from Explorer. The correct way to call AttachConsole is to pass -1 to it. This causes our process to attach to the console of our parent process (the console window that launched us).
However, this has two different problems:
1) Because the console launches Windows apps in the background, it immediately displays the prompt and allows further input. On the one hand this is good news, the console is not blocked on your GUI app, but in the case where you want to dump output to the console and never show the GUI, your program's output comes after the prompt and no new prompt is displayed when you're done. This looks a bit confusing, not to mention that your "console app" is running in the background and the user is free to execute other commands while it's running.
2) Stream redirection gets messed up as well, e.g. "myapp some parameters > somefile" fails to redirect. The stream redirection problem requires a significant amount of p/Invoke to fixup the standard handles, but it is solvable.
After many hours of hunting and experimenting, I've come to the conclusion that there is no way to do this perfectly. You simply cannot get all the benefits of both console and window without any side effects. It's a matter of picking which side effects are least annoying for your application's purposes.

Here is the best method that I've found:
First, set your projects output type to "Windows Application", then P/Invoke AllocConsole to create a console window.
internal static class NativeMethods
{
[DllImport("kernel32.dll")]
internal static extern Boolean AllocConsole();
}
static class Program
{
static void Main(string[] args) {
if (args.Length == 0) {
// run as windows app
Application.EnableVisualStyles();
Application.Run(new Form1());
} else {
// run as console app
NativeMethods.AllocConsole();
Console.WriteLine("Hello World");
Console.ReadLine();
}
}
}

It´s very simple to do:
Just add following attribute and code to your Main-method:
[STAThread]
void Main(string[] args])
{
Application.EnableVisualStyles();
//Do some stuff...
while(!Exit)
{
Application.DoEvents(); //Now if you call "form.Show()" your form won´t be frozen
//Do your stuff
}
}
Now you´re fully able to show WinForms :)

You can create a winform project in VS2005/ VS2008 and then change its properties to be a command line application. It can then be started from the command line, but will still open a winform.

All the above answers are great help, but I thought to add some more tips for the absolute beginner.
So, you want to do something with Windows Forms, in a Console Application:
Add a reference to System.Windows.Forms.dll in your Console application project in Solution Explorer. (Right Click on Solution-name->add->Reference...)
Specify the name space in code: using System.Windows.Forms;
Declare the needed properties in your class for the controls you wish to add to the form.
e.g. int Left { get; set; } // need to specify the LEFT position of the button on the Form
And then add the following code snippet in Main():
static void Main(string[] args)
{
Application.EnableVisualStyles();
Form frm = new Form(); // create aForm object
Button btn = new Button()
{
Left = 120,
Width = 130,
Height = 30,
Top = 150,
Text = "Biju Joseph, Redmond, WA"
};
//… more code
frm.Controls.Add(btn); // add button to the Form
// …. add more code here as needed
frm.ShowDialog(); // a modal dialog
}

This worked for my needs...
Task mytask = Task.Run(() =>
{
MyForm form = new MyForm();
form.ShowDialog();
});
This starts the from in a new thread and does not release the thread until the form is closed. Task is in .Net 4 and later.

You should be able to use the Application class in the same way as Winform apps do. Probably the easiest way to start a new project is to do what Marc suggested: create a new Winform project, and then change it in the options to a console application

Its totally depends upon your choice, that how you are implementing.
a. Attached process , ex: input on form and print on console
b. Independent process, ex: start a timer, don't close even if console exit.
for a,
Application.Run(new Form1());
//or -------------
Form1 f = new Form1();
f.ShowDialog();
for b,
Use thread, or task anything,
How to open win form independently?

If you want to escape from Form Freeze and use editing (like text for a button) use this code
Form form = new Form();
Form.Button.Text = "randomText";
System.Windows.Forms.Application.EnableVisualStyles();
System.Windows.Forms.Application.Run(form);