In PowerShell there are 2 main ways to extend the shell this are:
· Modules – A package that contains Windows PowerShell commands int he form of functions, cmdlerts and worksflows, in addition it may contain variables, aliases and providers. Modules can be written in PowerShell and/or compiled as DLLs.
· Snap-Ins – Are compiled cmdlets in to a DLL written in a .Net language are bening deprecated and no longer recomended as the way to create and package new cmdlets.
There is a big miss conception with people starting with PowerShell when they install some server products like Exchange or SharePoint and the programs place a shotcut to what they call a "Management Shell" it is nothing more than PowerShell with a loaded Module or PSSnapin. As you will see extending the shell is quite simple and flexible.
Working with Modules
Modules have primarily 2 locations on your system:
· %windir%\system32\WindowsPowerShell\v1.0\Modules this is the location for system wide modules available to any user in the system.
Each module is stored in a folder where there is a psm1 file that is known as a Module Manifest, this manifest has the settings for the module and sets the restrictions for it in terms of .Net Framework version, version of PowerShell, files to load, version, copyright, author and many other settings. This file can load what is called a main module and sub-modules each can either be a psm1 or dll file, in addition they can also be scripts that gets procresses. As it can be seen using modules provide great flexibility in terms of formats and structure.
We can also have modules in other locations that can be accessed by the PowerShell session we run in, the locations are defined in the environemt variable $env:PSModulePath
If we want to add another path for PowerShell to look at we just add that path to the current environment variable:
$env:psmodulepath = $env:psmodulepath + ";"
To list the modules that are available we use the Get-Module cmdlet withe the -listavailable parameter:
This will list all modules that the session can see in the paths that are specified in the environmet variable. On PowerShell v2 we would have to load each module we wanted by hand and only then would be be able to use the commands available, in the case of PowerShell v3 Microsoft now allows us access to the modules in those paths and the modules are loaded dynamically when a cmdlet, workflow, alias or function that form part of the module is invoked.
If you only want to see the modules that are currently loaded in to the session the -All parameter is used with Get-Module:
C:\> Get-Module -All
ModuleType Name ExportedCommands