ConsoleControl: embedding a console in a WinForms or WPF application

A console in a panel

ConsoleControl is described as a C# class library that lets you embed a console in a WinForms or WPF application, and the console can be used for input and output for a process. The README's summary of the use case is short: it is great for making tools and utilities.

That describes a specific and common gap in Windows desktop development. A tool that wraps a command line program, a build step, a version control command or a diagnostic utility normally has to either show the output in a separate console window, which pops up and steals focus, or capture the text and re-render it in a control, which means writing the pipe handling, the thread marshalling and the encoding yourself.

ConsoleControl is that middle layer. The library hosts the console, and the application talks to it through a control it drops onto a form.

Two details in the README set the boundaries. It is a Windows desktop library by construction, since WinForms and WPF are the two frameworks it supports, and the console it embeds is a real console rather than a text box, which is why it can carry the behaviour a text box cannot: colours, cursor movement and the rest of what a command line program expects to write to.

That last point is the difference between this and catching standard output into a text box. A program that redraws a progress bar with carriage returns or uses colour codes needs a terminal, not a label.

Two packages, one per framework

Installation is through NuGet, and the README says outright that it could not be easier.

The package name depends on the framework you are targeting. For WinForms:

PM> Install-Package ConsoleControl

And for WPF:

PM> Install-Package ConsoleControl.WPF

The split is because a WinForms control and a WPF control are different types with different hosting models, and a single package cannot serve both without conditional dependencies that the tooling would handle badly.

The package is also searchable in the NuGet gallery by name, so the install command is the short route rather than the only one, and the README describes the process as searching for ConsoleControl or installing directly.

For an application that targets both frameworks, or that shares a core library with a desktop front end, the practical consequence is that the shared code talks to the control through the common base, and the front end picks the package that matches it. That arrangement is the reason the library exists in two packages rather than one, and it is worth checking against your own project layout before you start.

Using the control

The usage section is short, and it is the whole of the API in three sentences.

Once you have installed the package, the control is available in the toolbox. You add a ConsoleControl to your WPF or WinForms project and call StartProcess to start a new process. The process runs and all of its output is directed to the control. You can also optionally enable input from the control.

That last sentence is the one that matters for the design of the surrounding application. A console that only displays output is a log viewer, and every one of those could be replaced by redirecting to a file. A console that accepts input is a terminal, and it means your application can prompt, and the user can type an answer, inside your own window.

So the practical pattern is that the child process is started by the control rather than by the application, because the control is what owns the pipes to it. The application then has a control that is both a display and an input surface, and the process is unaware that it is not attached to a real terminal.

The README points at a screenshot in the documentation directory, which is the quickest way to see the result before you install anything.

Building it, and where the idea came from

The developer guide tells you to open the main solution in the source directory to build and run any of the code or samples, and it also offers a script for the same job from the command line.

The build script in the repository is the PowerShell file named build.ps1.

So the repository carries a full solution with samples, and a PowerShell script for the cases where you would rather not open an IDE.

The origin story is worth knowing, because it tells you what to expect. The README says you can learn how the ConsoleControl was created by reading the article Embedding a Console in a C# Application on CodeProject. That is a design write-up of the trick the library performs, which makes it the right first document if you want to understand why the library is structured the way it is, or if you want to know whether a direct implementation in your own code would be simpler.

That last question is legitimate. The library is small, the article explains the mechanism, and if your application only needs to display the output of one process, the article may be enough. The library earns its place when you want the same behaviour across several screens and frameworks without maintaining that code.

Releases, automation and the state of the project

The release procedure is described in full, and it is a conventional manual tagging flow with automated publishing afterwards.

The steps are: update the version number in the shared assembly info file, create a new version tag, and push it with the follow tags option. AppVeyor then builds and publishes a new NuGet package, as long as a new semver tag is pushed.

So the version number lives in one file in the source tree, the tag is the release signal, and the build server does the packaging. That is a sensible arrangement for a library of this size, and it is also the kind of setup that quietly stops working if the build server configuration is not maintained.

The repository itself is small, with the source directory holding the solution, the documentation directory holding the screenshot and the other documents, the AppVeyor configuration file, and a licence file. There is also a GitHub directory for issue and pull request templates.

The release tags tell the story of the cadence. The versions are 1.3.0 from 2020-05-22, 1.2.1 from 2019-04-08 and 1.2.0 from 2018-11-28, and the last push was on 2026-09-10.

So there is a gap of several years between the newest tag and the newest commit, with work continuing on the branch in between. For a library whose last release is from 2020, that is the detail to weigh, and it is the reason the conclusion of this article is cautious rather than enthusiastic. The licence is MIT, with the licence file at the root of the repository, and the README also carries badges for the build status, a code scanning service and a sponsorship link.

Editorial conclusion

ConsoleControl suits a developer building a Windows desktop tool that launches a command line utility and wants its output in a panel of the application rather than in a separate console window, because the library does the pipe handling and the rendering for you and gives you input as well as output. It is the wrong choice for a cross platform application, since the whole design is Windows specific, and the wrong choice if the child process is the point rather than the interface, because a real console window is simpler and better behaved. Verify first which of the two packages your project needs, that the child process writes to standard output rather than requiring a real console, and that the version you install matches the framework you build against, since the newest tag on the repository is from 2020.

Frequently asked questions

Official sources

1. dwmkerr/consolecontrol on GitHub
2. Issues
3. License: MIT
4. README
5. Releases