This post was most recently updated on April 28th, 2019.Reading Time: 3 minutes.
Every now and then, you run into a situation, where you’ll need to somehow dump the console output (or transcript) of running a console application. I’m actually going to argue it happens a lot more often than one would think – in my case, any time a customer requires a webjob or a function, that one would normally deploy to Azure, being ran on the servers of the customer. This post describes how to do that.
Something breaks or the app crashes, and the error is logged to event log… But just the error, not the whole transcript. You’d like to get it all, to figure out what’s actually going on, but event log is not the way to go.
Or, maybe you’re investigating an error that happened to someone else, but only get screenshots of console or event log errors, whereas you’d want to get all the possible information about the problem instead.
What to do?
Solution: redirection operator > to the rescue!
It’s luckily pretty easy. There are multiple ways to pipe, dump, redirect, log, mirror or just save the output to almost any imaginable target medium, but since I hate always googling for them (and for the life of me, I can’t seem to remember it by heart), I’m documenting my preferred way here.
How to redirect output to file in Powershell?
You can direct the whole console output (and hence the whole PowerShell transcript for your executable) to a text file by doing something like this:
executable.exe > output.txt 2>&1
executable.exe *>&1 > output.txt
This method just writes everything from the console window to a file – as simple as that!
In these examples, the following parameters affect the outcome:
|Redirection operator: >||Writes the command output to a file or a device, such as a printer, instead of the Command Prompt window.|
|2>&1||These parameters cause this command to first redirect stdout (Standard Output Stream) to the output file, and then redirects stderr (Standard Error Stream) there as well.|
Okay – so now it’s finally documented. Maybe I won’t have to google it the next time :)
Wait… But how is this better than copypasting from a console window?
If you’re not running your application unattended, you could just run the application and copy-paste from the window to your preferred location. That’s nice and easy! So what makes this method better?
A couple of things come to mind:
Why dumping console output to a file is better than just copypasting
- You can get the transcripts unattended. You don’t have to do anything yourself.
- This way, You won’t mess the copying up by selecting from areas of the output.
- I don’t know about you, but I often mess up the copy-pasting from a console or PowerShell window. This method makes that impossible.
- This is the easiest way I’ve found to ask other people for the whole output/transcript of a console application run.
- That’s really useful, because when I’m debugging, I really want the whole log, and not just the last few lines of red text!
However, a far more advanced scenario would be to save the output directly to Application Insights or something similar. For a lot of cases, this would be like shooting a fly with a bazooka, but for larger deployments, why not. Maybe worth a blog post later! :)
He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.
This is his personal professional (e.g. professional, but definitely personal) blog.
Latest posts by Antti K. Koskela (see all)
- IE11 fails to load a (server-side) Blazor web app - November 13, 2019
- How to instantiate your DbContext outside your Data project? - November 11, 2019
- Another year, another Hacktoberfest (2019)! - November 1, 2019