Crescendo ma non troppo

No, this is not a post about music.

This post will be about my first experiences with the PowerShell Crescendo module, which was just released in Preview 1.

Now, why would I care to write a post about a preview of a module?

The reason is quite simple. This module is, in my opinion, covering something that was missing in PowerShell. Namely the possibility to use native commands, and present the results as objects.

The blog post by Jason Helmick I linked to earlier explains this all in more detail.

What follows are my first, admittedly simple, trials using the Crescendo module. If you don’t want to copy code from this post, I created the VMW-Crescendo repository that contains all the files.

An Example

The first example I tackled is the DOS command tasklist, which displays a list of the running processes. 

Not to complicate things at the start, I decided to only implement the module for running tasklist on the local computer.

And needless to say, since this is a DOS command, it will not run on other platforms besides Windows.

The idea behind the Crescendo module is that you write in JSON, how the cmdlet(s) you will create use the native command. This not only includes specifying which parameters are used but also how the returned output will be converted to an object.

Since PowerShell contains cmdlets to convert to and from JSON, I decided to try and write those definitions in PowerShell. And then convert that code to JSON format, which I could then feed to the Crescendo cmdlet.

The Code

Annotations

Line 1: Although the blog post mentions that a module generated with Crescendo can be used on PowerShell 5.1 and 7, I noticed that since the generated code uses the ternary operator, this not really the case. Hence the requirement to run this on PowerShell v7.

Line 5-35: As I mentioned earlier, I created the definition of the cmdlets to be created in PowerShell.

Line 10: By default, the tasklist command is started with the /V (for verbose) parameter.

Line 11-33: The OutputHandler is where you define how the output of the native command will be converted to an object. I did have to use some ‘trickery’ to avoid having to use hard-coded offset. Luckily the one can use the underlining to determine the start and length of each column.

Line 37: The Powershell object is converted to JSON code, and saved to a file.

Line 39: The Export-CrescendoModule cmdlet takes the JSON file and generates the module.

Sample Run

The generated modules, at least in this Preview 1, only generate a .psm1 file. You can use the Import-Module pointing to that .psm1 file.

The module contains the Get-TaskList cmdlet, that requires no further parameters and returns a series of objects, containing the results.

Since the Get-TaskList cmdlet returns objects, we can now easily use other PowerShell cmdlets to further handle the returned data. For example:

The resulting CSV file contains all the data.

VMware Tools Debug Levels

The second example I concocted, uses one of the native commands that come with the installation of the VMware Tools. The VMwareToolboxCmd.exe has the option to get and set the debug levels on the VMware Tools services. 

Note that you need to run this command in Administrator mode.

The Code

Annotations

Line 1: Although the blog post mentions that a module generated with Crescendo can be used on PowerShell 5.1 and 7, I noticed that since the generated code uses the ternary operator, this not really the case. Hence the requirement to run this on PowerShell v7.

Line 5-66: This part is the definition for the Get-ToolsDebugSettings cmdlet.

Line 11: With the OriginalCommandElements property we define which parameters shall be always added to the native command.

Line 12-55: Each possible service is defined as a Switch parameter. Each entry also has the cmdlet parameter name (Name) and how it shall be translated to a native command parameter (OriginalName).

Line 59-63: The Output Handler takes the line that is returned and converts it into an object.

Line 68: The PowerShell object is converted into JSON and save to a file.

Line 70-128: This part is the definition for the Set-ToolsDebugSettings cmdlet.

Line 120-126: The Set cmdlet will have an additional parameter (Level) that indicates which new debug level shall be set for the selected service. Note that the debuglevel is added as-is, no parameter on the native command.

Sample Run

The cmdlets from the generated module need to be called from an elevated prompt (same as the native command).

And just as with the native command we can query and set the debug levels.

In Conclusion

Is this new Crescendo module something that you should be using immediately?

Definitely not, this is a module, based on an interesting concept, that only just entered Preview 1.

But it is surely a concept that is interesting.
I’ll be watching where this goes, and what can be done with it.

Enjoy!

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*

This site uses Akismet to reduce spam. Learn how your comment data is processed.