Windows PowerShell

I downloaded the (CRT) version of Windows PowerShell (formerly known as Monad). I wanted to see how easy it would be to create a command off of an assembly. The idea of writing a library that can be used in a WinForm application, web page (on the server side), and now from the command-line is very exciting. I find batch files and script files very useful. There are times you need to perform a simple task and it is just easier to write a simple script file and run it from the command-line. It would be nice if you could develop applications and expose the same functionality in your application via command-line commands. Although PowerShell does have the ability to “new” any .Net object and perform operations on it just as easily as you would a COM object in VBScript, it also has the ability to load custom Cmdlets. A Cmdlet is a command-line command that for the most part is very similar to an old DOS command. Microsoft has added this concept of verb dash noun (example get-command or get-process) as a naming convention, but other then that it still accepts arguments in pretty much the same way as a regular DOS command (example "get-command *PSSnapin*" or "get-command –verb “get”"). A Cmdlet lives as a first class citizen in the PowerShell world and Microsoft has made it fairly easy to create new ones. When you install Windows PowerShell you will get the System.Management.Automation.dll that will hold the classes that you will need to inherit from when you create your own Cmdlet. It should be noted that your Cmdlet lives in an object called a PSSnapin that descends from Installer. The Installer is used by InstallUtil.EXE to install your assembly and PSSnapin into Windows PowerShell. However, even though it is installed you must call Add-PSSnapin followed by the name of your PSSnapin (the name that is defined in the Name property not the name of the DLL) before you will be able to use your new Cmdlets in Windows PowerShell. One thing to remember when you are creating a core DLL, a command-line object is a little different then objects that you would use in a WinForm application. The command-line is a different environment. It is transaction based while WinForm applications are primarily event driven. You should expect that if you want to have a DLL that will be used by both a WinForm application and a Windows PowerShell Cmdlet that you will have to design it in a way that would make it useful for the two environments. There is a pretty good article on creating Cmdlets on CodeProject. This is a good place to start if you want to write your own Cmdlet. I do like the way that command-line flags and parameters are easily defined by just adding attributes to properties. This really simplifies development (no more reading the args parameter in the traditional static main method). Microsoft has done a really good job of handling this. After working with this for awhile you will wonder how we ever programmed command-line applications before Windows PowerShell. I also like the way that Cmdlets are executed. You override the BeginProcessing, ProcessRecord, EndProcessing and then you can use the WriteObject, WriteError, WriteWarning, WriteVerbose and WriteDebug to send different levels of information to the console that is controlled by standard flags that all Cmdlet have. It is exciting to see a more powerful command-line shell and I look forward to the official release.

By the way, if you want to create and launch a WinForm from Windows PowerShell, enter the following at the command-line:

[reflection.assembly]::LoadWithPartialName("System.Windows.Forms")
$form = new-object system.windows.forms.form
$form.text="HELLO WORLD"
$form.showDialog();