PowerShell Station

Dude, Where's my Command?

Posted on 2 September 2020 by mike The Dilemma This post was inspired by a recent occurrence at work. I have built a framework which constructs documents based on a lists of functions in a module specific to that kind of document.

What about new modules?

Good question! For new stuff (written after 2.0 was introduced), I started with the same module structure: single .psm1 file with a bunch of functions in it. Probably put an Export-ModuleMember *-* in there to make sure that any helper functions don't "leak", but that was about it. To be fair, I didn't do a lot of module writing for quite a while, so this wasn't a real hindrance.

Is there a problem with that?

No...there's no problem with having a simple .psm1 script module containing functions. At least from a technical standpoint. Adding a module manifest is nice because you can document dependencies and speed up intellisense by listing public functions, but that's extra. The problem came when I wrote a module with a bunch of functions. VisioBot3000 isn't huge, but it has 38 functions so far.

What's the recommended solution?

I've seen several posts recommending that each function should be broken out into a single .ps1 file and the .psm1 file should dot-source them all. That definitely gets past the problem of having a big file. But in my mind it creates a different problem. The module directory (or sub-folder where the .ps1 files live) gets really big and it takes some work to find things. Lots of opening and closing of files.

Why mess with Visio from PowerShell?

I've got a couple of posts with some really basic code to access things in PowerShell and it occurred to me...I probably haven't made it clear why you might want to do this (other than that you can). So, instead of moving on to connections (which will be next, followed by containers), I thought I'd take a break and show you a really quick and practical script.