⏱️Overview

BuildConsole (BC) is the program I created and developed at work*, using C# (syntax here), in WinForms.
Specifically to visualize output from build process. It surely is my biggest and most useful C# project so far.
Unfortunately I can not open source it’s code because of that*. But I can share my experience from this process.

📷Gallery

Screenshots here. Starting with latest version from 2021 and its features, then with older until first from 2017.

⚙️How it works

At its core, BuildConsole replaces the Windows cmd.exe command prompt (terminal) and will run any command too.

It does so, by creating a process and redirecting its output, error and input streams.
For the core part, it was quite useful to browse ConsoleControl code and many stackoverflow answers as usual.

The main needed part of creating process is located here with redirecting (all 3 RedirectStandard*).
It is also using BackgroundWorker classes (e.g. outputWorker) that run on own threads and read those redirected streams, to show output immediately when it comes.

Textbox

I used the richTextbox control (included in WinForms) since the beginning. It turned out to be garbage for this purpose.
It makes few easy operations really too difficult:

• Centering view to a line not even possible.
• Adding a text line, is slowing down the more lines it already has.
• View always jumped a little (jittered) when adding lines.
• Having a user selection while adding text was a PITA, got it almost working.
• Had to be unfocused before browsing text above.
  Otherwise new added lines would jump to end (even if turned off).
• Finding text needed a lot of code. Mark all was painfully slow.

So I recently found and adapted BC to use the FastColoredTextBox control instead. Which is on the other side of spectrum. It is so feature packed (almost like a real IDE) that I probably only use 10% of it.
Still, it is way faster at drawing text, has all needed features and even some extras already (like bookmarks). It needs using only fixed width fonts though (I used variable before). But it is understandable that e.g. selecting text (block mode too) was much easier to implement because of that.

✍️Motivation and rants

Well everybody in company was using just cmd.exe to build (nearly all) projects, with a custom .bat file. I can’t post how it looked like exactly, but I can surely tell that at some point, it looked like a black and white TV noise. It happened when building with VxWorks started, using GCC (which is awesome). But here, it was outputting full build command, for each file, with all include paths too (like 8 lines of junk). In other words, it seemed like somebody was shoving a black and white sand at my face. Well I couldn’t even ?.

About 6 months after I started working there, I was building a project very often, to test an upmerge of some stupidly outdated branch. This required to look for build errors in that white text sandbox. It is when I realized I seriously can’t look at this trash and I simply can make a program, that filters out and colors this junk (firstly errors).

So after asking and getting approval, I started implementing it. Then after about 2 weeks I had a first working release. It was pretty basic, but already way more useful. It still had a couple of bugs, which I fixed later.

Screenshot

Now I can’t provide a real work example (also because of that*), so I’m including an artificial example on the screenshot (above). Output is similar to real and more general.
The good part is that it has like 1 to 3 lines of each common message. Normally there are many similar lines on one screen, but only few unique. This way screenshot shows the whole process on one screen with already most of line types included.

📊Features

Here is a list of all program features from current version. Starting from basic, first implemented and ending with additional extras, added much later (not essential, but useful). I am describing them in place.

🔨Basic

• Changing font on Settings tab.
  Zooming already present, with Ctrl-Wheel or Ctrl-Num+
• Unlimited buffer scrollback.
  cmd.exe has very small default value, and even doesn’t allow more than 9999 lines, in settings.
• Settings in a XML file, saved in user folder.
  I’d say a standard thing. Holds both user set options and all line rules (find text, color, skip and more).
• Combo boxes for user paths and commands.
  With buttons on left to add, delete, set as default.
• Filtering (skipping) useless lines.
  There is a lot of rubbish, e.g. coming from MSBuild (also visible in Visual Studio), like:
  “Compiling…”, “Generating code…”, something up to date, lines with just “Microsoft Visual Studio” (a greeting commercial) and more.
  With a simple xml option to skip a line, the final output becomes cleaner and to the point.
  There is a textbox with last line present (just below console) that shows those skipped ones too.
• Coloring lines
  By regular expression (RegEx), more info on its syntax here.
  • Later replaced (and extended) by simple find (String.Contains).
  • Advanced RegExes
    Use groups and replace (change) the incoming line (to make it cleaner and shorter).
    Still doing a simple string check first, to make the whole process faster.

⚙️Utility

• Progress list. On right, it has just key build steps.
  Copied from output with time since start. It shows only 0:00 here because this test was fast.
• Double click on a line in progress list jumps to it in console.
  This was pretty easy with FastColoredTextBox and it also centers (impossible and awful in richTextbox).
• Find.
  Searching for text in console, with:
  find next, previous, mark all and clear marks.
• Program icon turning green when idle, yellow when running, red when build has errors.
• Saving current console output to a text file.
  Loading saved files into console, to view them later, in same colors.
• Log file, optional.
  Auto incremented for more program instances.
  There are checkboxes for disabling line skip in log file or in console.
• Tooltips with info text for nearly all controls.
• Icons for most controls, also in menu.
• Help menu with full documentation in about 10 chapters.
  Also Changelog and nice About dialog.
• Opening VS solution and VxWorks with workspace
  By button (all with hotkeys), you could open the project in path quickly.
  There sometimes were more in one path, so new settings were added in xml.

🛠️Advanced

• Auto loading settings.xml file when it changed.
  Open by button on Settings tab, and on save in editor, program already loads it.
  Useful with many instances, all will do it. Also if one saves settings, other will load it too.
• Queue.
  Ability to run a command in a number of paths sequentially. Done in settings.xml.
  Main thing here is that if a build fails in path the queue will quit, leaving the failing project path in combo.
• Actions.
  Ability to start or kill a process, at command start, end or fail (build error).

💡Observations

So first, just as a warning, this is my point of view.

There is a number of things I realized here, some I still don’t get and can only suspect.

It is certain that I made an extremely useful tool. What bothers me here, is that nobody did it, in like 10 years. Well, I guess I’m the one guy who could create it so far and that is rare.

Next, which is even more odd, some people still don’t use it. I can only suspect a few factors here, they:

• Don’t know of it.
  It is obvious for me that even the best software (FOSS, well made and useful) will go unnoticed without promotion (or commercials) and spreading information about it. That’s why I am always announcing each new release in local emails and some also further.
• Are too lazy to try.
  Sure all programs have a learning curve, but this one is easy and well documented.
  Sadly that can happen, even worse if it takes years. I guess I can’t really expect ability to change especially from people who work for too long in one place.
• Are so addicted to old methods, that they can touch the future. Actually the present, for nearly 2 years. That’s for me even worse than laziness.

⏳Conclusions

Whatever the case, it doesn’t matter that much.
A software engineer has to deal with users. Sometimes even those who “didn’t even try turning it off and on again”.
Also, developers need to balance listening to already users (wanting something) versus shouting at not yet users (to gain new ones).

Lastly, I’m glad I could develop this tool, because otherwise I would hate building even more (now it is nice to look at, just old and inefficient). Also I’m glad if anyone found it useful (beside me).