Skip to main content

Classy Powershell

Using classes in PowerShell

So I've recently come to fall in love with PowerShell, despite all its strange quirks and odd behaviors. For those not in the know, some time ago, Microsoft decided that they needed a more fully functional scripting language then the command line syntax that existed. So they spent a bit, and before you know it they had spun up PowerShell. So, being one of those programmers who aren't just satisfied with if/then loops in my languages, I wondered if given its object-oriented nature, PowerShell supported classes. It turns out, that with the introduction of PowerShell 5.0, they had actually introduced the concept of classes; however, as I was searching around for how to use them, the documentation was a bit more... sparse.

More than one file? 

If you're like me, your programming is usually organized with handy dandy folders, I usually have something like this

main.ps1 - The actual "Executable" code that the user runs
- \lib\ - A series of functions that the program needs to run that I'll use a lot
- \bin\ - The actual "Code" that makes the program unique
- \str\ - Storage for whatever the program might need
- \cfg\ - Configuration settings
- \tmp\ - Temporary files
So with all this in mind, I wondered if I could call all the .ps1 scripts I had so politely nested in my /lib/ folder with one single call, to simply iterate through each of them and then for each one I imported run import module, something like 

foreach $item in $libfolder{
 import-module $item
}
And as it turns out that would have worked fantastically, if it wasn't for one small little detail. If I put a class in those library files? Well, Powershell can't use them, at least not calling them from main.ps1.

 Classes vs Module 

Before Powershell introduced a class based design, it was quite happy living off another implementation. You see, there is this wonderful little concept in PowerShell called modules. A module was intended to be basically like a .dll file, a series of functions that one could run, and then the ability to set which functions from it could and couldn't be extracted, and honestly in the use case I was looking at a module probably would have been just fine. Ever the one to want to try and be fancy in my code, however, I opted for a different route.

To label something a "Module" you literally only need to change the file type from a .ps1 to a psm1, and then run the import-module command. This makes things fairly simple in theory, and for getting things off the ground fairly quickly it can be handy

Now you can further specify the things you do and don't want to be shared from the module, as by default PowerShell will simply treat it as little more than a glorified .ps1 file and import everything. To do this you simply add these somewhere near the bottom 
Export-ModuleMember -function 'RegeX goes here'
Export-ModuleMember -variable 'AnotherRegexHere' 
If you have administrator rights on the machine, you can even skip the whole import-module bit entirely  by simply storing the modules wherever $ENV:PSModulePath happens to be looking, as PowerShell will simply load up all the .psm1 files in there that it feels the need to load up 

This is great and all, but this still fails to answer the question of what to do about classes. Now if you're like me you probably stumbled across "Using" 

Using 

So a few things about the "using" command. First and let's get this out of the way now, if you're going to go about loading up your classes in this way, you can't do what I had originally hoped and dynamically iterate through a folder. The using command must be at the absolute top of the script. The only thing that can be above it is comments. You call it like this
Using module '/myPath/myModule.psm1'
Again awesome, though we lose our ability to summon up these psm1 files dynamically, it seems like a small price to pay when it comes to being able to use those classes we've been meaning to get at. Now when you run
[myClass]::new() 
Powershell won't look at you like you've just vomited up a baby.  But there is one TINY little hitch in this plan.

So if you're like me, you are probably calling on some namespaces, like the presentationframework which by the way you can find with all of it's namespace cousins nested in C:\Windows\Microsoft.NET\assembly\GAC_64 if you were ever curious just what the namespaces actually were referring to.

The thing is that if I call my .psm1 file and it relies upon a namespace, even if I call that namespace with something akin to
using namespace PresentationFramework
using module './lib/MyModulethatNeedsPresentationFramework' 
It's still going to fail. This is where we have to introduce something called the Powershell Manifest file. Now what this means is where you had myModule.psm1 before you're now going to need
myModule.psm1
myModule.psd1 
And then to invoke the module you're going to run the following
using './myPath/myModule.psd1' 

The PSD1

The PSD1 filetype is actually fairly useful. This is the file that we use to define plenty of little features for our developed module without cluttering it. Instead of putting those functions to export at the bottom of yoru PSM1 you can just put it here. They basically look like giant configuration files so you end up with something like this
@{
RootModule = 'myModule.psm1'
ModuleVersion = '1.0'
Author = 'Alnarra'
CompanyName = 'Alnarra Media LLC'
Copyright = '(c) 2018 Alnarra Media LLC. All rights reserved'
}
Which is simple enough, but the awesome thing here is that we can also tell it a few other things, including any required modules (like say you've developed an error handling module or a file browsing module, and you want to use those everywhere). You can simply specify them with
RequiredModules = 'error.psd1' 
But what we're looking for is actually the assemblies, and again it's pretty simple, simply call them like this 
RequiredAssemblies = 'presentationFramework' 
So, in the end, your .psd1 file looks something like

@{
RootModule = 'myModule.psm1'
ModuleVersion = '1.0'
Author = 'Alnarra'
CompanyName = 'Alnarra Media LLC'
Copyright = '(c) 2018 Alnarra Media LLC. All rights reserved'
RequiredAssemblies = 'presentationFramework'
RequiredModules = 'error.psd1'
}
Now for the whole kit and kaboodle, we have

main.ps1

using module './lib/myModule.psd1'
function someFunction{
[myClass]::new()
}
Then we'd have our /lib/ folder inside of which would be two files
myModule.psm1
myModule.psd1 
Mymodule.psm1 would look something like
class MyClass {
   myClass() {
     #Do Something that requires the presentation framework
  }
And MyModule.psd1 would appear as something like
@{
RootModule = 'myModule.psm1'
RequiredAssemblies = 'presentationFramework'
}
Admittedly this is probably overcomplicating what would otherwise be a simple thing, and this will only work in Powershell 5.0, but for me, it makes things a lot easier to manage and keep track of. The code's always easier to maintain when it's not a jumbled mess and a single file. I feel like spreading it out across a few files while adding a bit of read overhead in terms of IO helps keep things consistent.

Here in a couple of weeks, I'll try to walk through an ACTUAL and useful powershell script I used to work with ipInfo.io in order to quickly gather information on a .csv file full of IP addresses and format them into an easily readable output 

Comments

Popular posts from this blog

World of Warcaft's Fundamental Flaws

Preamble  I've mentioned on my twitter a few times that there are some problems with World of Warcraft. That for all intents and purposes I just can't just look beyond at this point. I'm not going to say any MMO honestly does things in a better way, but I think it would be foolish to believe that the formula that blizzard has applied is working at the moment. That having been said, I feel it's also a bit of a stretch to pretend like there isn't any valid and active competition to WoW these days. No longer is it simply WoW, Everquest, and Ultima. We've had nearly 20 years to work on this formula and see what we can get out of it.

To start, lets acknowledge what World of Warcraft has done well, as well as what it got known for.  WoW came out during the height of the Everquest and Star Wars Galaxies days, and defined itself quickly thanks to a number of factors. First, WoW has and always will be "The Casual MMO", despite beliefs to the contrary. When co…

An Online Identity Crisis

As I start to put together what will at some point hopefully be a more cohesive online identity it becomes increasingly apparent that ultimately my problem becomes one of "What do I want that online identity to be". I began to consider and weigh if there were parts of my identity that I wished to whitewash or attempt to clean in an attempt to better market myself to the public at large. This is weighed against my fear that in doing so I will ultimately become disingenuous and thus a poor representation of self.

The fundamental question of if I sacrifice who I am in favor of making a more presentable self. It's a notion that weighs heavy on me as I prepare to try and make a more cohesive presentation of self here on the internet as a whole. Do I talk about my depression? Do I talk about my issues with sexuality? Do I talk about my political stances? Where do I draw the line of what is publically alright to disclose, what is kosher to discuss, and what should be held back?