Output Console.WriteLine from WPF Windows Applications to actual console

Question

Background: I am struggling to add command line and batch processing capabilities to an existing WPF Windows Application. When I detect some options at startup I suppress the window from appearing, do some processing and quit immedietally. Now, because there's no UI I'd like to output some messages to stdout/stderr. Consider following code:

namespace WpfConsoleTest
{
    public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            Console.WriteLine("Start");
            System.Threading.Thread.Sleep(1000);
            Console.WriteLine("Stop");
            Shutdown(0);
        }
    }
}

When I run from command line I would expect following output:

Start
Stop

But instead:

C:\test>WpfConsoleTest.exe

C:\test>

You can redirect output, though:

C:\test>WpfConsoleTest.exe > out.txt

C:\test>type out.txt
Start
Stop

Redirecting to CON does not work, unfortunately:

C:\test>WpfConsoleTest.exe > CON

C:\test>

Another problem is that WpfConsoleTest.exe quits immedietaly after start. So:

C:\test>WpfConsoleTest.exe > out.txt & type out.txt

C:\test>

But:

C:\test>WpfConsoleTest.exe > out.txt & ping localhost > nul & type out.txt
Start
Stop

The best solution I was able to come with so far is to use start /B /wait:

C:\test>start /B /wait WpfConsoleTest.exe > out.txt & type out.txt
Start
Stop

This approach is mostly ok - if you wrap it up in a bat you can preserve error code and so on. The one huge downfall is that you get output after application ends, i.e. there's no way you can track progress, you have to wait for whatever is going on to finish.

Therefore, my question is: How to output to parent console from WPF Windows Application? Also, why is so hard to grab stdout/stderr from WPF?

I know that I could change application type to Console Application in project settings, but this has a nasty side effect - console window is visible all the time, even if you simply double click the exe. This solution also won't do, because it create a new console, even if application was run from cmd.

EDIT: to clarify, I want my app to output to the existing console if there is one and not to create a new one if it is missing.

Answer 1

After digging up a bit, I found this answer. The code is now:

namespace WpfConsoleTest
{
    public partial class App : Application
    {
        [DllImport("Kernel32.dll")]
        public static extern bool AttachConsole(int processId);

        protected override void OnStartup(StartupEventArgs e)
        {
            AttachConsole(-1);
            Console.WriteLine("Start");
            System.Threading.Thread.Sleep(1000);
            Console.WriteLine("Stop");
            Shutdown(0);
        }
    }
}

Calling the exe directly still has a nasty side effect, connected with the call returning immediately:

C:\test>WpfConsoleTest.exe

C:\test>Start
Stop

^^^^
The cursor will stay here waiting for the user to press enter!

The solution is, once again, to use start:

C:\test>start /wait WpfConsoleTest.exe
Start
Stop

Thanks for input!

Answer 2

What I've done in the past is to make it a console application and call P/Invoke to hide the app's associated Console window once I've shown my WPF Window:

//added using statements per comments...
using System.Diagnostics;
using System.Runtime.InteropServices;

    internal sealed class Win32
    {
        [DllImport("user32.dll")]
        static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);

        public static void HideConsoleWindow()
        {
            IntPtr hWnd = Process.GetCurrentProcess().MainWindowHandle;

            if (hWnd != IntPtr.Zero)
            {
                ShowWindow(hWnd, 0); // 0 = SW_HIDE
            }
        }
    }

Answer 3

A WPF application will not have a console by default, but you can easily create one for it and then write to it just like in a console app. I've used this helper class before:

public class ConsoleHelper
{
    /// <summary>
    /// Allocates a new console for current process.
    /// </summary>
    [DllImport("kernel32.dll")]
    public static extern Boolean AllocConsole();

    /// <summary>
    /// Frees the console.
    /// </summary>
    [DllImport("kernel32.dll")]
    public static extern Boolean FreeConsole();
}

To use this in your example, you should be able to do this:

namespace WpfConsoleTest
{
    public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            ConsoleHelper.AllocConsole(); 
            Console.WriteLine("Start");
            System.Threading.Thread.Sleep(1000);
            Console.WriteLine("Stop");
            ConsoleHelper.FreeConsole();
            Shutdown(0);
        }
    }
}

And now, if you run it from the command line, you should see "Start" and "Stop" written to the console.

Answer 4

Till now, I have found no best solution if I want to have

1. Be able to redirect the output to other output stream, such as a file using ">" in command line
2. Support powershell output

So maybe the correct answer is:

1. Split your GUI app with your Console App for example, GUI called Tool.exe, and Console App called ToolConsole.exe.
2. Mark Tool.exe type to be "Windows Application" while ToolConsole.exe to be "Console Application" in VS
3. Put a bath file called "Tool.bat" and it can have the following content:

ToolConsole.exe %1 %2 %3 %4

4. Then when you call Tool Param1 Param2... you are actually called ToolConsole.exe and when you directly runs Tool.exe by double click it, you are using Tool.exe GUI

That is my solution, if anyone have an idea to solve all cases I mentioned, glad to hear.

Answer 5

Adapted from the answers from @gwiazdorrr and @MattBurland, converted into VB.NET. Show how to deal with issues related to debugging from Visual Studio.

' VB
''' <summary>Get the process ID.</summary>
Public Declare Function GetCurrentProcessId Lib "kernel32" () As Integer

''' <summary>Allocates a new console for current process.</summary>
Public Declare Function AttachConsole Lib "kernel32" (processID As Integer) As Boolean

''' <summary>Frees the console.</summary>
Public Declare Function FreeConsole Lib "kernel32" () As Boolean

''' <summary>Get a list of the process IDs currently attached to the console.</summary>
Public Declare Function GetConsoleProcessList Lib "kernel32" (processList As UInt32(), processCount As UInt32) As UInt32

Private Sub ShowCommandLine()
    ' Attach a console to this WPF application
    AttachConsole(-1)

    ' Output will not be visible if debugging from Visual Studio. Check whether a console is attached and
    ' that a debugger is not attached.
    Dim processList As UInt32()
    ReDim processList(64)
    Dim processesAttachedToConole As UInt32 = GetConsoleProcessList(processList, 64)
    Dim debuggerAttached As Boolean = System.Diagnostics.Debugger.IsAttached
    If (processesAttachedToConole = 0) OrElse (debuggerAttached) Then
        ' Don't display anything on the console window
        ' You could pop up a WPF message here...
    Else
        ' Show help in the console window
        Console.WriteLine()

        ' Version information (by way of example)
        Dim myAssembly As Assembly = Assembly.GetEntryAssembly()
        Dim myName As String = myAssembly.GetName().Name
        Dim myVersion As FileVersionInfo = FileVersionInfo.GetVersionInfo(myAssembly.Location)
        Console.WriteLine(String.Format("{0} v{1}", myName, myVersion.FileVersion))
        Console.WriteLine()

        ' Force a RETURN keypress, otherwise the user must hit RETURN themselves
        SendKeys.SendWait("{ENTER}")
    End If

    ' Detach the console
    FreeConsole()
End Sub

Answer 6

In the project properties, you can change the project type from a Windows application to a Console application, and AFAIK the only difference is that you get a console to use throughout the application's lifetime. I haven't tried it with WPF though.

If you want to open and close a console, you should use Alloc/FreeConsole, but it is usually simpler to change the project type.