Tuesday, August 28, 2012

PowerShell: Redirecting Console Output and Error Output to a Variable and E-mailing it

I recently had the need to script the execution of a command-line utility and thought it would be a good learning experience to try doing it with PowerShell.  The utility would sometimes output to the STDOUT, but would also send its output to STDERR if there was a problem.  This seemed to involve many different problems all at once including:

  • Running an EXE with a space in the path and multiple command-line parameters
  • Capture both STDERR and STDOUT to a variable
  • Escaping special characters/using special characters
  • Doing string concatenation
  • Doing explicit type conversion
  • Sending an email
  • Joining a string array to a single string variable
  • Doing a "FOR" loop (optional but fun).

Anyway, here's the script I came up with that runs a command-line app and takes all the output (including the error stream) and joins it into a string and then sends it in an email to me.  It's a bit ugly because I am a PowerShell novice, but it does work.  The only trouble I've noticed is that sometimes the error lines will be a bit out of sequence from the corresponding stdout lines.  If someone knows how to fix that, please let me know in the comments!!!

 

#Setup the command string - notice the `" to escape the double-quotes inside the string (deals with spaces in path)

# and the old batch file trick of doing 2>&1 to ensure STDERR is piped to STDOUT.

$command = "& `"C:\Users\myprofile\Documents\visual studio 2010\Projects\TestOutput\TestOutput\bin\Debug\testoutput.exe`" someparameter -xyz someotherparameter -abc someotherthing -rfz -a somethinghere 2>&1"
#Execute the command and put the output in an array.

$console_output_array = invoke-expression $command

#loop through the array and print out the results to the command line (optional)

for ($i=0; $i -lt $console_output_array.length; $i++)
{
    [string]$i + "=<" + $console_output_array[$i] + ">"
}

#create a single string by joining together the array

$console_output_string = [string]::join("`r`n",$console_output_array)

#send an email with the results

$emailFrom = "fromemail@example.com"
$emailTo = "toemail@example.com" 
$subject = "Email subject goes here"
$smtp = new-object Net.Mail.SmtpClient("yoursmtpserver.example.com", 25)
$smtp.Send($emailFrom, $emailTo, $subject, $console_output_string)

Tuesday, August 14, 2012

Fix: Crystal Reports Shows Red X Across Entire Page When Report Run Inside Visual Studio

I was googling (with Bing AND Google) like crazy for a solution to this, but didn't find one from any of the open resource sites, so I figured I'd blog about my fix for this to help the next poor dev to come along.

I was getting user feedback that one of the Crystal Reports in an application that I support was intermittently crashing.  When I ran the report in Visual Studio, on certain pages of the report, I observed a red X across the whole screen with a white field.  Obviously something was very wrong here!!!

Red X on Crystal Report 

It boiled down to that there was a null value being used in one of my formula fields, and Crystal seems to raise an exception for nulls when they are used as part of certain types of formulas and not converted manually to an actual value first.  I didn't know which field was causing the issue so I just started a divide and conquer approach.  I suppressed all fields and confirmed that the report worked (select a bunch of fields, Right Click... Format Multiple Objects... Suppress).  Then I started un-suppressing a few objects at a time until the report started failing again.  Now I knew where the problem was (or at least one of the problems).

I then right-clicked one of the formula fields and chose "Find In Formulas" to open the formula workshop.  I drilled down to the formula field (it could be in any of the sections) and found the offending one.  Note that it could be a "normal" formula field or even one of the special formatting formulas (like "if this field's value is true, format as green").

image

I believe the "right way" to fix it is to handle NULLs properly using ISNULL() (which returns a boolean unlike the T-SQL ISNULL() ) or another appropriate method in Crystal for each and every one of your formulas.  This MSDN article describes that.  However, there exists another workaround as well which should be fine for most simple cases.  On the top of each formula when you click into the white field where the code actually lives, you can change this box:

Exceptions For Nulls

To say this:

Default Values for Nulls

If you choose "Default Values For Nulls", Crystal will substitute "" for null strings and an appropriate flavor of 0 for numeric fields.  Here's some documentation that oddly seems to skip booleans.

This dropdown selection is per-formula, so it might take a lot of work to go through and change every formula in the tree view (don't forget to look at the formatting formulas too!!!), but if your report is crashing with the dreaded red X and you don't know why, this may get it working again.