Have you found yourself writing PowerShell objects that you’d love to share with others? What’s the best way to get these things distributable? Well… with PowerShell 2.0, you have two different types of packaging – snap-ins and modules.
Snap-ins
Snap-ins were available in PowerShell 1.0 and are still supported in PowerShell 2.0. In order for these to be used on a machine, they typically need to be installed first. Once the snap-in is installed on the machine, then it should be in a spot where PowerShell can see it. The best way to tell if it’s there is using the following command:
Get-PSSnapIn -Registered
This will show all snap-ins that PowerShell can see, with the exception of those snap-ins that came with PowerShell. If the snap-in that you’ve installed doesn’t appear, then you may need to use the Installer Tool that comes with the .NET Framework to register the DLL.
Once the snap-in appears in the list, then you can bring it into the PowerShell session with the Add-PSSnapIn cmdlet. So let’s say you were installing the IIS 7.0 PowerShell snap-in,downloadable from IIS.net. Once the MSI file was run, the IIS snap-in should be installed on the computer. At this point, you should be able to run the following command:
Add-PSSnapIn WebAdministration
While good things are already packaged in snap-ins, what if you have your own things to package in a snap-in? How do you create your own snap-in? MSDN covers this in depth.
You can also use the Import-Module cmdlet to bring in a snap-in into the PowerShell session. Tome Tanasovski covered this – including why you would choose Import-Module versus Add-PSSnapIn – in a Hey, Scripting Guy! blog post.
Modules
Modules are the newer, improved way of packaging PowerShell goodies for redistribution. Some of the goodies may include are providers, cmdlets, functions, scripts, dependent assemblies, and help files.
To see what modules are available on your machine, use the following command:
Get-Module -ListAvailable
Unlike snap-ins, modules do not necessarily need to be installed. They need to have a certain folder structure and live within one of the directories listed in the PSModulePath environment varible.
To bring a module into your PowerShell session, use the Import-Module command. For example, if you downloaded the Windows Installer PowerShell module to use PowerShell to investigate MSI files, then you would import this module with the following command:
Import-Module MSI
If you’re writing custom cmdlets in C#, then you’ll create a binary module – this is the DLL you create when you build your class library. If you’re writing scripts, simple functions, and advanced functions in PowerShell then you’ll create a script module, in the form of a .psm1 file. See my 4/26 presentation recap for my custom script module that is bundled with a module manifest, making it a manifest module.
The custom module that I had created shows the structure of a module, especially when help files are included. If you download the custom module, you’ll notice that the help files are simply text files. If I am redistributing a module, I typically go to the module’s folder and zip it at that level, so that the module just needs to be unzipped to one of the modules folders listed in the PSModulePath environment variable.
Matt and I have mentioned a variety of snap-ins and modules in our series so far, but there are plenty of others out there that may be useful for you. If you do a search in your favorite search engine for “PowerShell snap-in” or “PowerShell module”, you’ll be able to see what else is out there.
Seeing What’s In These Packages
While I explained how to import these snap-ins and modules into your PowerShell session, I didn’t tell you how to see what you get with them. Once your snap-in or module is in your PowerShell session, then you can use the following command to learn more about that module or snap-in:
Get-Command -Module ModuleOrSnapInName
As always, Matt and I enjoy getting feedback on the series. If there’s something you want to see us cover, please get in touch with us. You can email me at sarah at codinggeekette dot com.
