Chapter 13. Script and manifest modules
We’ve been building Get-SystemInfo for several chapters now, and we’ve been testing it by inserting a line, at the end of our script, that runs the function. It’s time to move away from that and into something that’s a bit more formal, packaged distributable for our command. We also need to find a way to get our custom view XML file to load into memory automatically when someone wants to use our tool. In this chapter, we’ll accomplish both.
Introduced in PowerShell v2, modules are the shell’s preferred means of extension (over the original PSSnapin extension technology). Modules can, in many cases, be file copied rather than requiring packagers or installers, which makes modules easy to distribute. Best of all—from our perspective—modules can be written in script, meaning you don’t need to be a C# developer to create one.
When it comes to modules, much of PowerShell’s capability relies on relatively low-tech techniques. Modules must follow a specific naming and location convention in order for PowerShell to “see” them. This can really throw people for a loop in the beginning—it’s tough to comprehend that PowerShell can get sensitive over things like folder names and filenames. But that’s how it is.