One trick: If you’re using Visual Studio 2005 (or an Express edition), you can get a jump-start by downloading some templates for PowerShell development from http://channel9.msdn.com/ShowPost.aspx?PostID=256835 (click the [Save] link near the bottom of the post; the ZIP file contains templates for VB.NET and C# – unzip the one you want and double-click it to actually install the templates). At the end of this series of posts I’ll give you a PrimalScript-compatible template, if you’re using that for cmdlet development.
Once I installed the template I wanted, I launched Visual Studio and created a new project, selecting the Windows PowerShell template. I gave my project the name I wanted for my Snap-In. A Snap-In (or, PSSnapIn) contains one or more cmdlets – think of it as a cmdlet package.
From the Project menu, I selected the option to Add Reference. I browsed to c:\Program Files\Reference Assemblies\Microsoft\Windows PowerShell and added all the DLLs I found – these were installed by the .NET Framework 3.0 SDK, so if you can’t find them, you may not have installed the SDK properly.
I then right-click the PSSnapIn.vb item in the Solution Explorer and select View Code. Note that if you just double-click the item you’ll see an error, because it’s trying to show you a visual representation (“the Designer” surface) for something that doesn’t have a visual aspect. Stick with “View Code.”
OK, the PSSnapIn itself isn’t really interesting – feel free to modify the strings being Returned for the various properties, but for the most part you don’t need to. So now, right-click your project in Solution Explorer, and select Add Item. From the window that appears, select the Windows PowerShell Cmdlet template – this will add a cmdlet to your project. When you do so, be sure to give the new cmdlet a name – such as “Where-Pingable.vb” – that reflects the actual name of the cmdlet. Your cmdlet name should follow the rules for PowerShell cmdlets, meaning you’ll use only acceptable verbs and singular nouns. You’ll find the official list at http://msdn2.microsoft.com/en-us/library/ms714428.aspx.
So, I’m building a cmdlet named Where-Pingable. I want it to accept a string (or a collection of strings), and only return those which it can ping. So it’ll basically take a list of names and return a list of names that it could ping – filtering out the un-pingable names. So my one input parameter is the names I want to try and ping. Here’s my property definition for that parameter:
Private _Address As String()
<Parameter(Position:=0, Mandatory:=False)> _
Public Property Address() As String()
Get
Return _Address
End Get
Set(ByVal value As String())
_Address = value
End Set
End Property
First, I declare a private variable named _Address. This variable will only live INSIDE my cmdlet, and it’s what will store the addresses. A public property is defined as a parameter. Note that all the Property code does is either return what’s in _Address, or set _Address to a new value – this is called an interface member. Really, all it does is give the cmdlet’s user a way to pass data into the cmdlet (via the Set routine), or get data out of the cmdlet (via the Get routine). Most property declarations will follow this pattern: Create an “internal” private variable, and then a Property routine. The special <Parameter> tag tells PowerShell more about this parameter, including its position and whether or not it’s mandatory.
All right, that’s it for this installment. We don’t have a functional cmdlet yet, but now’s the time to sit down and start PLANNING your cmdlet. What will it do? What will it be named? What parameters will it need to have? You can also get your development environment set up with the various downloads you’ll need. In the next installment, we’ll focus on the actual functionality of Where-Pingable.
Technorati Tags:
Cmdlets
PowerShell Development
