PowerShell offers two ways for you to extend the shell. You can either use snapins, which are binary only and developed in a fully-fledged programming language like C#, or you can use modules, which can be binary as well as script based.

Be sure to read the previous articles in the series:

• Learn How to Automate Windows with PowerShell
• Learning to Use Cmdlets in PowerShell
• Learning How to Use Objects in PowerShell
• Learning Formatting, Filtering and Comparing in PowerShell
• Learn to Use Remoting in PowerShell
• Using PowerShell to Get Computer Information
• Working with Collections in PowerShell

And stay tuned for the rest of the series all week.

Snapins

Snapins are so last year. All jokes aside, snapins never really caught on among the PowerShell community because most scripters aren't developers and you can only write snapins in a language like C#. Nevertheless there are still some products that use snapins, like Web Deploy for example. In order to see what snapins are available for you to use in the shell you use the following command:

Get-PSSnapin –Registered

To use the commands added by a snapin, you first need to import it into your session, and you can do that like so:

Add-PSSnapin -Name WDeploySnapin3.0

At this point, you will get an error if you don’t have the Web Deploy snapin installed. If you do have it installed, like I do, then it will be imported into your session. To get a list of commands available in the snapin, you can simply use the Get-Command cmdlet:

Get-Command –Module WDeploy*

Note: Technically this isn't a module, but for some reason you still have to use the Module parameter.

Modules

Modules are newer and are the way forward. They can be both scripted using PowerShell as well as coded in a language like C#. Most of the built-in commands are organized into modules as well. To see a list of modules on your system, you can use the following command:

Get-Module –ListAvailable

As products are updated, their PowerShell counterparts are being migrated to modules. For example, SQL used to have a snapin, but it is now made up of modules.

In order to use a module, you need to import it first.

Import-Module -Name SQLASCMDLETS

You can use the same trick we used with snapins to view all the commands that the module added to the shell.

So that leaves the question: how does PowerShell know what snapins and modules you have on your system? Well, snapins are a bit of a pain and have to be installed. Part of the installation process includes creating a few registry entries that PowerShell looks at to find snapin information. Modules, on the other hand, can be registered with the shell by simply placing them in one of the locations in the PSModulePath environment variable. Alternatively, you could just add the path to the module to the environment variable.

($env:PSModulePath).Split(";")

That will spit out the contents of the variable. Notice that if you have a module like SQL installed, how it modified the variable to include the SQL module's location.

Module Auto Loading

PowerShell 3 introduced an awesome new feature which goes by a few names. None of them are official, but “Module Auto Loading” is the best description of it. Basically, it allows you to use cmdlets that belong to an external module without explicitly importing the module using the Import-Module cmdlet. To see this, first remove all the modules from your shell using the following command:

Get-Module | Remove-Module

You can then check that you have no modules loaded by using the following:

Get-Module

Now use a cmdlet that isn't in the core library. Test-Connection is a good one:

Test-Connection localhost

If you check your loaded modules again, you will see that it did indeed load the module.

That’s all for today guys, join us tomorrow for more.