Get-ChildItem on version 2.0 vs 3.0

Question

Not sure if this has been discussed or is known, but I found an interesting issue when running Get-ChildItem on version 2.0 vs 3.0
So I have the simple command of
$files = Get-ChildItem -Path $Source -Recurse -ErrorAction SilentlyContinue -ErrorVariable myError
If $Source only contains 1 file, then $files is of type System.IO.FileInfo, whereas, if there are more than one, it would be of type Syste.Array. I actually thought $files would always be a collection, no mater if there was one or multiple files, but obviously
I was wrong.
So with thinking it will always be a collection, I used $files.Count for my Write-Progress
Write-Progress -Activity "Backing up Files" -Status "File: $src-->$dest" -PercentComplete ($counter / $files.Count*100)
Everything on my machine worked and I am running version 3.0, so I put the script on a machine that was running 2.0 and the Write-Progress failed with cannot divide by zero..hmmmmm
So doing a little testing, I ran the Get-ChildItem command on version 2.0 and then did $files.Count which returned nothing due to $files being System.IO.FileInfo, and it doesn't have a property of Count, but if you run it on version 3.0 and then do $files.Count,
even though $files doesn't have a Count property when it is of type Syste.IO.FileInfo or System.IO.DirectoryInfo, it will return 1
If you find that my post has answered your question, please mark it as the answer. If you find my post to be helpful in anyway, please click vote as helpful.
Don't Retire Technet

Answer 1

In PowerShell 3.0 or later, you can check a .Count property on any value (even $null.Count); it was added along with the Member Enumeration feature.  This works for .Length as well.  If no property / field named Count or Length exists on the object,
PowerShell will enumerate it for you and return the number of objects
When you're needing to support PowerShell 2.0, you need to be more careful.
On a side note, use the syntax in Boe's last post, with the @() operator around the command that you ran.  There's a subtle difference between these two:
$files = @(dir DoesNotExist.txt -ErrorAction SilentlyContinue)
$temp = dir DoesNotExist.txt -ErrorAction SilentlyContinue
$files2 = @($temp)
$files.Count # 0
$files2.Count # In PowerShell 2.0, this will be 1. In 3.0 or later, it's 0.
This is because there are technically two different kinds of Null values that the PowerShell engine recognizes:  actual null references, and a value called AutomationNull, which is used to represent a command which didn't output anything.  In PowerShell
2.0, when you assign the result of a command to a variable, it didn't keep track of whether the result was AutomationNull or not, resulting in this weird behavior.  3.0 and later correct this.
Here are a couple of other demonstrations of this in action:
$array1 = @($null)
$array2 = @([System.Management.Automation.Internal.AutomationNull]::Value)
$array1.Count # 1
$array2.Count # 0
function ReturnsNull { return $null }
function ReturnsNothing { }
$array1 = @(ReturnsNull)
$array2 = @(ReturnsNothing)
$array1.Count # 1
$array2.Count # 0