• Dylan Jacob
• Thu 15 July 2021
• 0 Comments

Prologue:

Ok, whether we need another subjective "Writing PowerShell Modules" article or not, I'm writing this one for me mostly. This is mainly just to compile bits and pieces of the (vastly) different articles I have found into one cohesive, usable, and hopefully focused article that I can reference for future projects. Hopefully, this will be useful to someone else, maybe even YOU.

Some background:

I find myself needing to write PowerShell scripts from time to time, and infrequently those scripts can (read should) be contained in a single .ps1. And thusly, PowerShell Modules enter with the promise of reusable code, modularity, and somehow making your life as a PowerShell deity easier.

This has not been my experience. It could be my lack of a formal programming education and that I cut my teeth on scripting languages like PHP and JavaScript, not the compiled behemoths of yon like C++. It could be that I do it just infrequently enough that I just haven't committed any of this to memory yet. Well, we are fixing that TODAY with this article.

Let's Do This:

Ok, so first lets define a structure for our modules and how they will interact with all the other bits and pieces of our fantastic script we are about to write.

ModuleName
| - Public\
| - Private\
| - ModuleName.psm1
| - ModuleName.psd1

Alright, lets walk through that a bit.

Our module will live in a folder named whatever we want our module name to be. In our example, I'm going to use Munge-Widget, which I know doesn't use Microsoft's approved verbs, but I don't care.

Then we have two directories: Public and Private. These will contain .ps1 files containing the actual functionality of our module. The functions, classes, etc. contained within the files in our Public directory will be exported to be used outside the module, and the functions, classes, etc. contained within the files in our Private directory will be available only within our module.

The .psm1 file will also be named the same as our module, so Munge-Widget.ps1 for our example. This file will be executed when we import the module into a script, or PowerShell session, so whatever we want to happen as soon as this gets hooked will go in there. This should probably load all the public and private functions, and make sure they are visible to the appropriate things.

The .psd1 file will also be named the same as our Module, so Munge-Widget.psd1 for our example. This file contains some data about our module, like the author, the license, functions and cmdlets to export, etc. This is the module's manifest file. We can easily generate it with the New-ModuleManifest cmdlet as follows:

New-ModuleManifest `
    -Path "<Path\to\Munge-Widget\Module\Directory>\Munge-Widget.psd1" `
    -Author "Dylan Jacob" `
    -RootModule Munge-Widget.psm1 `
    -ModuleVersion "1.0" `
    -Description "PowerShell module to munge widgets."

There's lots of other options, and you don't need to include all of these; you could run the command and then edit the resulting file directly.