Installing the Cascadia Code Font (using PowerShell)

In a recent article, I wrote about the new font Microsoft has created, Cascadia Code. I just love the new font and am using it with PowerShell, VS Code and more. I also use it in a variety of VMs, so automating the download and installation is important.

It turns out that downloading and installing a new font is relatively straightforward, like this:

# Install Cascadia Code
# 1. Download Cascadia Code font from GitHub$DLPath = 'https://github.com/microsoft/cascadia-code/releases/'+          'download/v1911.20/Cascadia.ttf'$DLFile = 'C:\Foo\Cascadia.TTF'Invoke-WebRequest -Uri $DLPath -OutFile $DLFile

# 2. Now Install it $Font = New-Object -Com Shell.Application$Destination = (New-Object -ComObject Shell.Application).Namespace(0x14)$Destination.CopyHere($DLFile,0x10)

Simples as they say.

One thing - the URL download path is hardcoded. You may need to adjust it going forward. Maybe someone can show me how to work out the latest version programmatically. 

PowerShell 7 Preview 6 ships - Get It Now!

The PowerShell team have released another preview of PowerShell 7. This release, which I expect to be the final preview before release of PowerShell 7 early in 2020, comes with a number of fantastic new features. Over on the PowerShell blog, super-star Steve Lee notes the cool features. A total smorgasbord of wonderfulness. Read Steve's excellent post here: https://devblogs.microsoft.com/powershell/powershell-7-preview-6/.

One particular feature that caught my eye was the improvements in Test-NetConnection. As many of you know, Ping.Exe, which has been around pretty much since the dawn of IP  (as in TCP/IP). uses ICMP echo request/reply. Due to ICMP attacks, many organisations turn off ICMP - thus using Ping would show no system, even though port 80 is open and working just fine. Test-NetConnection allows you to both ping (eg using ICMP) as well as test the connection to a specific port This is a huge improvement, although the command is very slow due to it being based on WMI.

In P.6 this has been re-implemented using not WMI but .NET. And the results are pretty awesome! Here is what it looked like in PowerShell 5.1:

But take a look at the performance of PowerShell 7 P6:

That is a pretty significant improvement! And by way of comparison, using Ping.Exe would have taken over 3 seconds!

This is another example of how PowerShell 7 is set to become a worthy successor to Windows PowerShell 5.1. 

Displaying Errors in PowerShell 7 - It Gets Better

In a recent blog post, I described the new approach taken in PowerShell 7 to displaying errors. In that post, I concentrated on the new look and feel of error messages as well as the use of $ErrorView built-in variable. One thing I missed in that post was the new look for run time errors.

To demonstrate the new method of displaying run time errors, consider this script:

Ok - nothing overly exciting but that's not the point. The script should generate two errors.

In Windows PowerShell (OR if you are running PowerShell 7 with $ErrorView set to "NormalView"), running this script looks like this:

That old familiar Wall of Red Ink! Hard to see the wood for the trees. But you can see the information if you read.

Now - PowerShell 7,. if you are set $ErrorView to "ConciseView" and rerun the script you still get the terrors (or course!), but PowerShell displays them like this:

I hope you'd agree this is a great improvement in displaying runtime errors. And you can always use the new Get-Error command to get all the nitty-gritty if you need it.

As I said in that prior post, I have always loved how PowerShell displays error messaged. I have enough practice to read through that first Wall of Red Ink to see the errors quickly and easily. PowerShell 7 just makes significantly easier. 

Viewing Errors in PowerShell 7 - Improving on Greatness

As a very long time PowerShell fan, I've always been impressed with the way PowerShell displays errors that occur in scripts or at the command line. PowerShell users are well-acquainted with the "Wall of Red Ink, as I call it:

But once you get over the visual shock and start to actually READ the error message, you begin to appreciate how good these error message actually are. They tell you what the error is and where it happened. I have long evangelised how good these messages are, once you learn to read them. B

But that is not to say things can't be improved. And indeed, in PowerShell 7, you'll find some nice improvements. NB: This blog post is being written using the latest build of the day. By the time PowerShell 7 ships, things may look the same - or different. As an aside, the daily build of PowerShell 7 in incredibly stable - hats off to the engineering team for managing that!

So in PowerShell 7, we have a new built-in variable and a new way of displaying errors. The Variable is $ErrorView which holds an object of the type: System.Management.Automation.ErrorView. This variable can hold one of three values: NormalView, CategoryView, ConciseView. With PowerShell 7, any time an error message is to be displayed, you see different views based on the value of $ErrorView.

A value of  'NormalView' results in the traditional display. But the new default setting, ConciseView, results in just the error message itself, like this:

For day to day use, ConciseView is awesome. BUT, I hear you say, where's all that detail gone. Do you HAVE to use the $Error error record collection?  NO - there's now a cmdlet for that: Get-Error.

With Get-Error you get ALL the error information inside each error record all expanded out nicely. ALL the information without having to expand error records to get to the exception details, etc.

This new feature allows you to limit the Wall of Red Ink to a Line Of Red Ink, and get the error information when you need more details.

What a great new feature!