Summary: Ed Wilson, Microsoft Scripting Guy, talks about looking at raw-file version information by using Windows PowerShell 5.0 in Windows 10.

Microsoft Scripting Guy, Ed Wilson, is here, and it is finally here. It seems like waiting for a major holiday to appear. Yes! It is nearly time for the Atlanta TechStravaganza. I just got an email yesterday from another Windows PowerShell MVP who will be attending. Cool.

Tonight is the “speakers dinner.” By that, I guess they mean, speakers and others—that is, whoever happens to be around and whoever signed up for the dinner will be permitted to hang out for a few hours tonight. The Scripting Wife, of course, signed us up as soon as it was announced.

I will admit, that the speaker’s dinner is always one of the highlights of the Atlanta TechStravaganza. This is because it is rather low key, and it provides a great opportunity to catch up with old friends, and to make new friends. The actual event can get rather hectic between presentations and talking to literally hundreds of people during the breaks between sessions.

Yes, the event is intense, but in a good way—sort of like riding Space Mountain at Disney World. On the other hand, the speaker’s dinner is more like the People Mover. It is more relaxed, and it gives you a chance to hang out and to see what is going on around you.

Which file version?

One of the things that is rather frustrating for me deals with file versions. For example, what is the file version? Many times I need to check the actual file version (especially after it is patched), and it gets rather confusing. I mean, version 15.0 might stay version 15.0 for over a year (even after it has had a dozen service patches applied). So how can I really tell if a particular patch was applied to a file? How can I tell if the file I see on two different machines is the same?

To make matters worse, many product groups are reluctant to actually revise the file version because some developers do things like the following pseudo code:

If (file version –ne 15) {throw error “this requires version 15 to run”}

Developers like to do this to ensure that their application or add-in will run properly. They know it runs on say, version 15, but they have not tested it on other versions. So, we see things like, “I can’t upgrade to the new version because my app doesn’t run on the newer version.”

In reality, it is only the version check that is failing. Then we come up with ways to lie to the version check—and on it goes.

New in PowerShell 5: FileVersionRaw

To solve the problem of strange file versions (or at least to help to mitigate the problem), Windows PowerShell 5.0 in Windows 10 introduces two new properties to the System.Diagnostics.FileVersionInfo object. As shown here, the two properties, FileVersionRaw and ProductVersionRaw, are actually script properties:

PS C:\> gps winword -FileVersionInfo | gm -MemberType ScriptProperty

   TypeName: System.Diagnostics.FileVersionInfo

Name           MemberType       Definition

—-                 ———-             ———-

FileVersionRaw    ScriptProperty System.Object FileVersionRaw {get=New-Object Sys…

ProductVersionRaw ScriptProperty System.Object ProductVersionRaw {get=New-Object …

To gain access to these two script properties, I use the –FileVersionInfo switch from the Get-Process cmdlet. But the default output does not display the raw file versions and product versions. This is shown here:

To see the *Raw script properties, I need to pipe the output to something like Format-List, and I need to reveal the additional information, as shown here:

The good thing is that now I can see the complete version numbers. This information (although for Winword, it does not really change anything) can really help provide insight into what actual file versions I have on my system.

WooHoo! Windows PowerShell for the win.

That is all there is to checking your file version information. Join me tomorrow when I will talk about more cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy