Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell classes to augment the native functionality of Windows PowerShell.
Microsoft Scripting Guy, Ed Wilson, is here. It seems like the conference season is gearing up. Keep an eye on my upcoming appearances page so hopefully you can catch the Scripting Wife and me at a venue near you. My good friend Aaron Nelson (aka SQLVariant) succeeded in getting us to come speak at the SQL Server Saturday event in Atlanta. He tried last year, but we were already booked to go somewhere else. Therefore, he immediately issued an invitation for this year, and that got it on our schedule. If you are anywhere in the area of Atlanta, you should make your reservation now so not miss this star-studded event. Even if you are a pure Windows PowerShell person who does not care for SQL Server, you should still attend because there will be some great Windows PowerShell sessions there.
I received several emails after yesterday’s blog, Why Use .NET Framework Classes from Within PowerShell? People were asking why I do not like using .NET Framework classes in scripts.
I did not mean to imply that there is no reason to use .NET Framework classes from within Windows PowerShell. What I meant to say was that given a choice between two equivalent commands, you should always use the native Windows PowerShell cmdlet, unless there is a sufficient reason for not using the Windows PowerShell command (such as performance or need for a specific capability).
For example, the following command returns an instance of a System.Diagnostics.Process class.
[diagnostics.process]::GetProcesses()
The output from the GetProcesses static method is exactly the same as the output from the Get-Process cmdlet. This is shown in the image that follows.
So, why use the GetProcesses static method from the System.Diagnostics.Process class? Well, in Windows PowerShell 1.0, the Get-Process cmdlet did not have a ComputerName parameter. Therefore, if one wanted to obtain process information from a remote computer, the options were to use the Win32_Process WMI class, or to use the GetProcesses static method. In this case, the need to retrieve process information from a remote computer clearly called for something other than use of the native Get-Process cmdlet.
In Windows PowerShell 2.0, however, this is no longer the case. Of course, if you have an old Windows PowerShell 1.0 script lying around that is working perfectly fine, there is no need to change it just because a new version of Windows PowerShell came out. We invest a lot of time and energy in backward compatibility to avoid the need to rewrite perfectly good Windows PowerShell scripts.
Another reason for using a .NET Framework class, is because it might be easier than using a Windows PowerShell cmdlet. For example, it is possible to create an arbitrary date by using the Month, Day, and Year parameters from the Get-Date cmdlet. This technique is shown here.
Get-Date -Day 23 -Month 1 -Year 2011
On the other hand, it is also possible to use the System.Datetime .NET Framework class to cast a string into a datetime object. This technique is shown here.
[datetime]"1/23/11"
The difference between the commands is that the Get-Date command creates a datetime object with the current time, and the [datetime] cast creates a datetime object with a time at midnight. These two techniques are shown in the following image.
It is, of course, possible to use a [datetime] cast. To do this, place a space after the date, and then type a time value. This technique is shown here.
PS C:\> [datetime]"1/23/11 3:17:42 pm"
Sunday, January 23, 2011 3:17:42 PM
If no timestamp is required, the [datetime] cast works great and is more efficient than using the Get-Date cmdlet. On the other hand, if the current time is also required, I prefer to use the Get-Date cmdlet because it seems easier to do.
On the other hand, it is possible to use the Get-Date cmdlet, and directly feed it a date to create. This technique is shown here.
PS C:\> get-date 1/1/11
Saturday, January 01, 2011 12:00:00 AM
So the question is, “What is easier?” When working with Windows PowerShell, it is great to have choices. Most of the time, especially when working interactively from the Windows PowerShell console, I try to use the technique that is easiest to use. If a .NET Framework class is easiest to use, or if it does exactly what you want, use it. In the end, it is all about getting the job done with a minimum of effort. Do not get stuck in a rut—use Windows PowerShell to its fullest. That is what it is there for.
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