Geek School: Extend PowerShell - Learn Advanced Scripting
Extending PowerShell Functionality
PowerShell provides two distinct methods for expanding its capabilities. These methods involve the utilization of either snap-ins, which are exclusively binary and constructed using languages such as C#, or modules.
Modules, unlike snap-ins, possess the flexibility of being both binary and script-based.
Related Articles in this Series
For a more comprehensive understanding, it is recommended to review the preceding articles within this series.
- Learn How to Automate Windows with PowerShell: An introduction to automating tasks.
- Learning to Use Cmdlets in PowerShell: A guide to utilizing PowerShell cmdlets.
- Learning How to Use Objects in PowerShell: Exploring the use of objects within PowerShell.
- Learning Formatting, Filtering and Comparing in PowerShell: Mastering data manipulation techniques.
- Learn to Use Remoting in PowerShell: Utilizing PowerShell's remote management features.
- Using PowerShell to Get Computer Information: Retrieving system details with PowerShell.
- Working with Collections in PowerShell: Managing and manipulating collections of data.
Further installments of this series will be published throughout the week, so please check back for more information.
Snapins in PowerShell
While often considered outdated, snapins represent a method for extending PowerShell functionality. Despite not gaining widespread adoption within the PowerShell scripting community – largely due to the requirement of development languages like C# for their creation – some products still utilize them. A prime example is Web Deploy.
Discovering Registered Snapins
To identify the snapins currently registered and available for use within your PowerShell environment, the following command is employed:
Get-PSSnapin –Registered
This command will display a list of all snapins that are recognized by your system.
Importing Snapins into a Session
Before you can utilize the commands provided by a snapin, it must first be imported into your current PowerShell session. This is achieved using the following syntax:
Add-PSSnapin -Name WDeploySnapin3.0
Attempting to import a snapin that isn't installed will result in an error. However, if the snapin, such as Web Deploy in this instance, is present on your system, it will be successfully loaded.
Listing Commands within a Snapin
Once a snapin is imported, you can view the commands it contributes to PowerShell using the Get-Command cmdlet. Specifically:
Get-Command –Module WDeploy*
It's important to note that, despite not being technically a module, the –Module parameter is still required for this command to function correctly.
Modules
Modules represent a more recent and preferred method for extending PowerShell's functionality. They support both scripting via PowerShell and coding in languages such as C#. Many of the core, built-in commands are now structured as modules.
To display a list of the modules currently available on your system, utilize this command:
Get-Module –ListAvailable
As products receive updates, their corresponding PowerShell interfaces are increasingly transitioned to a modular format. For instance, SQL previously relied on a snap-in, but now utilizes modules.
Before a module can be used, it must first be imported into the current session.
Import-Module -Name SQLASCMDLETS
A similar technique to that used with snap-ins can be employed to view all the commands that a module introduces to the shell environment.
This raises the question of how PowerShell identifies the snap-ins and modules present on a system. Snap-ins require installation, a process that involves creating specific registry entries that PowerShell consults.
Modules, however, can be registered with the shell simply by being placed in one of the directories specified within the PSModulePath environment variable. Alternatively, the module's path can be directly added to this variable.
($env:PSModulePath).Split(";")
Executing this command will output the contents of the environment variable. Observe how the variable is modified to include the location of modules like SQL, if they are installed.
The PSModulePath variable defines the locations where PowerShell searches for modules.
Understanding how modules are located and imported is crucial for effectively extending PowerShell's capabilities.
PowerShell Module Auto-Loading
With PowerShell 3, a significant enhancement was implemented, often referred to as “Module Auto Loading.” While lacking an official designation, this term accurately describes its functionality. This feature enables the utilization of cmdlets from external modules without the need for explicitly importing them via the Import-Module cmdlet.
To demonstrate this, begin by removing any currently loaded modules from your PowerShell session using this command:
Get-Module | Remove-Module
Subsequently, verify that no modules are currently loaded by executing:
Get-Module
Now, attempt to execute a cmdlet not included within the core PowerShell library. Test-Connection serves as a suitable example:
Test-Connection localhost
Upon completion, re-examine the loaded modules. You will observe that the necessary module was automatically loaded to facilitate the cmdlet’s execution.
This automatic loading process streamlines PowerShell usage by eliminating the need for manual module imports. It enhances efficiency and simplifies scripting workflows.
The system dynamically loads modules as their cmdlets are called, providing a seamless experience for the user. This feature is a core component of PowerShell’s extensibility.