15

#PSTip Validating version numbers without RegEx

If you have read my earlier post on the Hyper-V Copy-VMFile cmdlet, I was checking for the version of integration components (IC) installed in the virtual machines. I wanted to verify if the IC version is at a minimum supported level or not. If you look at any version number, it usually has four different parts – major, minor, build, and release numbers.

The traditional way of checking for version numbers is to verify if all four version numbers match or not. This can sometimes be complex and error prone. A more easy and efficient way to do that is using System.Version .NET class. This is available as [Version] type accelerator in PowerShell.

PS C:\> [Version]"6.3.9421.0"

Major    Minor    Build    Revision
-----    -----    -----    --------
6        3        9421     0

The [Version] type accelerator automatically converts the string into a System.Version object. It is then easy to perform the required comparisons using the PowerShell comparison operators. This class also has several overloaded methods to check version numbers that do not necessarily have all four components in the a.b.c.d version format.

PS C:\>$PSVersionTable.BuildVersion -eq [Version]"6.3.9423.0"
False

PS C:\>$PSVersionTable.BuildVersion -eq [Version]"6.3.9421.0"
True

PS C:\>$PSVersionTable.BuildVersion -ge [Version]"6.3.9421.0"
True

PS C:\>$PSVersionTable.BuildVersion -le [Version]"6.3.942.0"
False

PS C:\>$PSVersionTable.BuildVersion -le [Version]"6.3.9942.0"
True

PS C:\>$PSVersionTable.BuildVersion -ne [Version]"6.3.9942.0"
True
Filed in: Columns, Tips and Tricks Tags: ,

5 Pingbacks/Trackbacks

15 Responses to "#PSTip Validating version numbers without RegEx"

  1. nohandle says:

    One thing to keep in mind when comparing Version objects: 1.0 is evaluated as less than 1.0.0 Similarly 1.0.0 is evaluated as less than 1.0.0.0 If you do not define all the values in the version the undefined values are set to -1 and the comparison takes that into account. Easiest way out of this is probably writing custom function and compare the versions using it.

    • Ravikanth says:

      You are right. Although, this example only showed using the constructor, there are other methods in the class to achieve what you described.

      • nohandle says:

        Can you show me how do I do that, please?

        • Ravikanth says:

          It is actually simple. We can use the same constructor. For example, $psversionTable.PSVersion on my system is 4.0. So, using $PSVersionTable.PSVersion -eq [version]”4.0″ results in a match. $PSVersionTable.PSVersion -eq [version]”4.0.0.0″ will result in false.

          • nohandle says:

            I don’t think we understand each other. What I am trying to say that in real world if I’d see 1.0, 1.0.0, 1.0.0.0 I would consider all three the same version and hence equal. But in the .net the 1.0 is considered less than 1.0.0 and 1.0.0 is considered less than 1.0.0.0. That surprised me and thought I will bring it to attention.

          • Ravikanth says:

            I see your point. Sorry, didn’t probably read your question completely. Yes, this is an issue. I am looking at how we can work around that. I will post whatever I conclude.

          • nohandle says:

            I wrote a function to compare two Version objects you may find it here: http://jakubjares.com/?p=80

          • Bartek Bielawski says:

            Actually, PS result is the one that is expected. From System.Version documentation: For two versions to be equal, the major, minor, build, and revision numbers of the first Version object must be identical to those of the second Version object. If the build or revision number of a Version object is undefined, that Version object is considered to be earlier than a Version object whose build or revision number is equal to zero. The following example illustrates this by comparing three Version objects that have undefined version components.

            http://msdn.microsoft.com/en-us/library/system.version(v=vs.110).aspx

          • nohandle says:

            Thanks for the reply. I was not saying the .NET implementation is wrong. I was just saying it works differently from what I would expect and what I need. This message probably got lost from the last reply, so I amended it.

          • Bartek Bielawski says:

            :) Well, I guess it all depends on how you read 1.1 and 1.1.0 – for me latter suggest some changes were made. But if you need/ expect both to mean the same, than yes, custom function is the only way to walk around it… ;)

Leave a Reply

Submit Comment

© 2014 PowerShell Magazine. All rights reserved. XHTML / CSS Valid.
Proudly designed by Theme Junkie.
%d bloggers like this: