Cmdlets are high level, task-oriented abstractions. The implementation of cmdlets can talk to anything: Web services, COM objects, WMI objects, .NET objects – anything. Depending upon how developers design their API, they can make it easier or harder to write cmdlets.
Today, on our internal discussion list, someone asked if there were any advantages to testing with PowerShell versus testing with C#.
I was able to come up with 10 quick reasons to test with PowerShell:
Being able to run command line programs easier within PowerShell
Dynamically generating code or test data for a test case (fuzzing or data-driven testing get a lot easier with this)
Being able to access COM easier within PowerShell
Being able to embed PowerShell in C# (so you can avoid writing a framework and just embed PowerShell in your infrastructure)
Being able to use weakly typed variables within PowerShell
Being able to test APIs on the command line,
There are 2 worlds:
The world as we think about it.
The world as we can manipulate it.
The difference between these two is what is called the semantic gap.
Our industry has been struggling with the semantic gap for decades.
Some people have asked the question, “Why Cmdlets?”. If you already have a reasonable API, what is the value in writing Cmdlets? I’ll provide a quick answer here but we should probably include a good write up of this in our documentation.
A while back, Jeffrey posted an article on how to use string expansion and XML casts to build XML documents in-line in a PowerShell script:
The overall feel of the approach that Jeffrey described is very much like that of ASP,
$hay has a new scripting blog at http://scriptolog.blogspot.com/ . His first blog entry Restart your engine – The PowerShell Way, talks about how he frequently edits his PowerShell profile file and then restarts his session. In his directions he says:
2: type: Notepad $profile to open your profile file
I looked at this and thought about my Philosophy of Automation post and thought,
One of the primary goals of Windows PowerShell is to encode operations knowledge. Consider the example of finding out what domain role a computer plays. If you look at the WMI class WIN32_COMPUTERSYSTEM, you’ll see that it tells you this information:
<Edited to add categories>In our active, responsive, and useful newsgroup Microsoft.Public.Windows.PowerShell (SELL SELL SELL 🙂 ), MVP Alex Angelopoulos recented posted the following:
Although file extension changing is a common technique in administrative tasks, the System.IO.FileInfo class does not provide a direct Basename property and neither does PowerShell.
MOW is now posting the details of his Managing Active Directory with Windows PowerShell demo that he performed at my TechEd talk. This is worthwhile for everyone to review. For the people at the talk, we covered a huge amount of data in a very short time so it would be worth while to walk through the details.
PSMDTAG:FAQ: How can I pipeline data to a parameter which does not accept pipeline input?PSMDTAG:FAQ: What are ScriptBlock Parameters?
One of the foundation concepts of Windows PowerShell is pipelining objects instead of text. What happens is that when an upstream command generates an object,