Writing a Windows PowerShell Module
This document is written for administrators, script developers, and cmdlet developers who need to package and distribute their Windows PowerShell solutions. In previous versions of Windows PowerShell, only developers could create packages using snap-ins that contained .NET Framework classes for cmdlets and providers. Now, by using Windows PowerShell modules, you do not have to use a compiled language to create a package for your Windows PowerShell solutions. Modules allow cmdlet developers, script developers, and administrators to package and distribute their solutions.
Windows PowerShell modules allow you to partition, organize, and abstract your Windows PowerShell code into self-contained, reusable units. With these reusable units, administrators, script developers, and cmdlet developers can easily share their modules directly with others. Script developers can also repackage third-party modules to create custom script-based applications. Modules, similar to modules in other scripting languages such as Perl and Python, enable production-ready scripting solutions that use reusable, redistributable components, with the added benefit of enabling you to repackage and abstract multiple components to create custom solutions.
The following scenarios describe typical uses for Windows PowerShell modules.
Libraries
Modules can be used to package and distribute a cohesive library of functions for doing common tasks. Typically, the names of these functions share one or more nouns that reflect the common task that they are used for. These functions can also be similar to .NET Framework classes in that they can have public and private members. For example, a library can contain a set of functions for file transfers.
Configuration
Modules can be used to customize a caller’s environment with specific cmdlets, providers, functions, and variables. This is similar to the use of profiles, dot-sourced commands, and customized environments. Unlike the previous scenario, the components of this module are not designed for a specific common task.
Applications
Modules can be used to repackage or improve existing functionality. A repackaged set of components can provide a customized interface that is designed for a specific task. This scenario can also be used to abstract other modules and to re-export a subset of their members.
Compiled Code Development and Distribution
Modules can be used by cmdlet and provider developers to test and distribute their compiled code without the need for creating snap-ins. The assembly that contains your compiled code can be imported as a module (a binary module) without the need to create and register snap-ins.
