PowerShellExtenderDemo

This solution shows how to extend PowerShell using C# Cmdlet classes in .NET System.Management.Automation namespace.

This is a DevOps solution which includes an MSI Installer project. ("Understood" is the name of a software development project.) The MSI Installer was designed to install/create all dependencies that happen to be pre-requisites for a software developer to commence work on the (Understood) development project.

The Installer project runs all commands, defined in PowershellExtender project, as part of the installation process. A log file is produced at the termination of MSI install - the file notes commands that passed or failed. The user will then have the ability to re-run the failed commands individually, after remediating the issues mentioned in log file.

To re-run the (failed) commands individually, the user can open a PowerShell (PS) console, import PowershellExtender (C#) class library as a PowerShell module using the following PS command, and then execute the individual command as a PS command, using the name attribute string defined on the Command class.

• -Command "Import-Module .\PowershellExtender.dll"

To facilitate the above-mentioned use cases, the command classes are derived from the following two base constructs

• a custom interface (IDevSetupCommand) that allows the MSI project to execute commands in bulk as C# command objects that follow the simple 'Command' design pattern, and
• 'Cmdlet' class defined in System.Management.Automation namespace; this allows the same command to be executed individually as a PowerShell command.

Following is a brief description for each of the projects in the solution.

1. PSExt.PowershellExtender

This project contains all commands (following the 'Command' design pattern); each command class inherits from the abstract DevSetupCommandBase class. The DevSetupCommandBase class inherits from Cmdlet class as well as implements IDevSetupCommand interface.

1. The IDevSetupCommand interface defines Execute() method that allows the MSI installer to execute these commands as C# command objects.
2. The implementation of Execute() method (in the abstract DevSetupCommandBase class) follows 'Template Method' design pattern; this is to avoid duplication of code across derived command classes.
3. Inheriting from Cmdlet class allows the same command to be executed as a PowerShell command. ProcessRecord() method (overridden from Cmdlet class) gets called, each time the command is executed as a PowerShell command.
4. ProcessRecord() method calls into Execute() method (see #1 above), thus ensuring that same logic is executed when the command is executed as a PowerShell command.

2. PSExt.PowershellExtenderTests

This project contains Unit Tests to test the individual commands in Project #1 (above). The unit tests are fairly rudimentary, in the sense that the actual command dependencies were never abstracted away, so no Mocks in this MS Test project.

3. PSExt.Shared

This project contains interfaces that are common to all different DevOps projects (Only the "Understood" project is fully fleshed out as of yet). It also contains the data class DevSetupCommandResult which encapsulates the execution results for each command.

4. PSExt.UnderstoodSetup

This project is specific to the "Understood" DevOps project. It houses:

1. A factory class to create commands that are specific to "Understood" project,
2. A Command Executor class to execute all commands created through factory,
3. UnderstoodConfigManager contains data properties that are populated with parameter values provided by user during the MSI Install process, and
4. UnderstoodSetupAction class that defines logic to be executed during the MSI Install process.

Note: Each DevOps project will have its own copy of "Setup" project.

5. PSExt.UnderstoodSetup.Installer

Finally the MSI Installer project that uses SetupAction in project #4 (above), to run commands (also created in project #4 above) as part of the MSI Install process.