If PowerShell Were School, I would Ditch Classes Regularly


When PowerShell v5 was in pre-release, I was still fairly new to PowerShell. I remember being very excited that PowerShell would be adding native classes as I had just discovered that the only way to classes in PowerShell was to write them in C#, which I had not yet begun to learn. Classes are something I have worked with in PHP, Python, PERL, C++, and C#. When I was learning C++ I fell in love with classes and object oriented programming. Most of my exposure to classes has been as a consumer and not an author, but I have written a few classes over the years for various things.

When PowerShell v5 was released, the first thing I did was go and learn how to make v5 classes. This was painful because there was not much documentation beyond basic class structures. As I had no urgent need for classes I let these sit on the back burner for quite some time. I was quite disappointed. A few months ago, I started seeing some of the more experienced PowerShell redditors advocating the use of classes for the purpose of controlling the “shape” of objects. I decided it was probably time to commit to learning PowerShell v5 classes. I’m still disappointed.

As I understand it, the initial use case for inclusion of native classes in v5 is their use within DSC. I spent about a month acclimating to DSC and from that exposure to the DSC syntax, I can certainly see how class based DSC resources would be somewhat easier to write. Consequently, this use case is also the only one that is decently documented. Before I go off on why v5 classes suck, I wanted to make it clear here that I do acknowledge there is a legitimate use case for them where they do shine brilliantly.


As the title of this blog suggest, I would recommend avoiding PowerShell v5 classes for now. The implementation of native classes is a mere shadow of .NET classes.  As the implementation is limited that makes complex objects less likely candidates as classes. The already uber-flexible PSCustomObject objects can already meet the needs of most objects while also offering a higher level of compatibility. 

This post will not have much code to it. It is mostly an opinion post with some facts sprinkled in. This post may also be a bit rough for novice coders or those new to PowerShell. If you came here looking for an intro to PowerShell v5 classes, this post will surely and sorely disappoint you.

Anyway, on to my specific gripes…

Version Locking

The first obvious problem with PowerShell v5 Classes is that they version lock you to PowerShell v5 or newer. Features do have to start somewhere and I can’t speak ill of the developers for not making v5 classes backwards compatible. However, this is a concern as v5 is still “new”. If you work at a smaller shop, or you happen to work at a large shop that has a very good Continuous Delivery pipeline, getting to v5 is not a huge hurtle. But, in a more traditional slow moving enterprise, getting to v5 is still a long way off just to get past all the red tape, let alone implement. Before you rush out and start writing v5 classes you need to be cognizant of your current PowerShell ecosystem. Again, this isn’t a real criticism of v5 Classes, but more of a caution against them for now.

No Private Properties and Methods

PowerShell v5 Classes do not support Private Properties or Private Methods. PowerShell v5 does offer a hidden keyword which can be applied to properties and methods. This hides the property or method from the default list of properties and methods from Get-Member and from autocompletion and intellisense. The properties and methods can still be directly accessed by the class consuming code and they can still be listed by Get-Member with the -Force parameter switch. Effectively, hidden is a cosmetic change to the class.

One of the benefits of classes in other languages is that they provide strict control over the class data by having real values in Private Properties acted on by Private Methods. This keeps the validation logic in class consuming functions to a minimum because they only need to validate the object type being passed to it. The rightful assumption is that the class is handing its own validation so the consumers can relax.

Absent private properties and methods, PowerShell v5 classes cannot be assumed to be tightly controlled. This means class consuming code must still include validation logic, error handling, or just let everything fail.

I realize that with some work it is possible to manipulate private data on .NET classes in both PowerShell and C#. The problem is that this is not as easy as simply assigning a value to a property or directly calling the method, as is possible with a hidden property on PowerShell v5 classes. If you begin with a standard property and later make it to hidden without renaming it, legacy class consuming code may still be manipulating the now hidden properties directly and causing undesired results in your class behaviors.

No Get or Set Accessors

PowerShell v5 Class Properties do not have getter and setter accessors. I could be wrong here, but I have dug around for days and have asked in several forums and if people even knew what I was talking about they certainly didn’t know how to do this with PowerShell v5 classes. Since it seems to be a foreign concept in the PowerShell ecosystem, I recommend that if you do not know what they are that you read up on C# Class accessors before continuing.
Not all languages with classes have this functionality. But, for those that do it allows for greater control over the property values. As an example, let’s say you had a class that defined a Honda Civic. Honda Civics come in 2 varieties: a 2-door coupe and a 4-door sedan. Honda Civics never have more than 4 doors and they certainly cannot have less than 0 doors. On our HondaCivic class, we would define the Doors property as an Int. Since a PowerShell v5 class cannot implement a set accessor for the Doors property, someone could set it to -80 (negative eighty). Now all the methods on the class or consumers of the class must implement sanity checks to ensure the Doors property is within the bounds of 0-4 inclusive.

Another use case is to have that class adjust other properties when another changed. Continuing with the HondaCivic class example, lets say that the class also has an Enum property CarType. This Enum has 2 possible settings: Sedan or Coupe. In a class that supports get and set accessors on properties, the class could be coded such that setting the Doors property to 4 would change the CarType property to Sedan and when the CarType is set to Coupe the Doors property would be set to 2.

One work around is to use ScriptProperty or CodeProperty properties. A ScriptProperty is a PowerShell property type that allows for setting a get ScriptBlock and a Set ScriptBlock. A CodeProperty allows for a CLR based property that supports both a setter and getter (I only learned about these in researching for this post and there are not many examples readily available). Both ScriptProperty and CodeProperty are available for PSCustomObject and any other object, so it is not unique to classes. 

The problem with a ScriptProperty is that it does not emit a type. What type emission provides is the ability to resolve the type specific methods and properties. For command line, this allows for tab completion and discovery of the properties and methods of an object (the object in this case being the property of a class). When programming, it can be used to call out typos of properties and methods as well as intellisense completion and selection. All in all, type emission is very handy, but not critical.

The problem with a CodeProperty is that you must pull it from compiled CLR code. In other words, you must write in something like C# and either import the compiled DLL or runtime compile it using Add-Type. With that much work, you might as well write the whole class in C#. But, it is handy if you want to borrow properties from existing .NET classes.

Again, the problem with both workarounds is that they are not native or unique to classes. They can be added to classes in exactly the same ways as they can be added to PSCustomObject or any other object.

It’s rather disappointing that the C# parent language supports this functionality but it is absent from PowerShell v5 classes. But, to a degree it makes sense. Since get and set accessors usually update and call private values from the class, and PowerShell v5 does not support private values, it probably made sense not to include the functionality. The problem I have is that it makes no difference to use a PSCustomObject. If Classes supported the property accessors, it would be a strong argument for using classes to more tightly control the class data.

Module Based Classes are a Pain

One of the problems I ran into with PowerShell v5 classes that ultimately led me to writing this blog entry was my experience trying to include classes in a module. The way I like to do modules is to separate out code into individual files. For example, each function in the module is in its own file. I then call these as nested modules in the psd1 of the module. Other module authors use a dot sourcing code block in their psm1.  One of the benefits of making a module out of your code to break it up into more digestible and easier to maintain pieces. 

While working on my Bencode module, I ran into a roadblock trying to get the classes defined in the module to be properly recognized in the calling scope. I had originally defined the classes as I normally do with calling them as nested modules from the psd1. When I would import the module and run a function with one of my classes defined as the output type I would get the error message about an unknown type.

No problem, right? You can just use the Using statement to use the modules types. WRONG! In this configuration, the Using command does not import the class from the module. I could call the Using statement directly against the ps1 where the class is stored, obviously, but that defeats the purpose.
I then tried to dot source the class files from my psm1 and I got the same results. The functions failed with an unknown output type and the Using statement failed as well.

Next, I tried directly defining the classes in the psm1 file. This time it worked. The functions recognized the output type without a Using statement and if I wanted to just use the classes from my module in a script, the Using statement worked as expected. But, now I had a ton of code in my psm1 file for the classes each which have their own complex set of methods and constructors and their many overloads (another minor gripe about classes is that you can’t include source form other files in the class, the entire class must be defined in a single file). This makes the maintainability of the psm1 a nightmare.

I tried several other things that would result in either breaking one or both of either the ability to import classes with the Using statement or the functions properly emitting the type. Ultimately I found that if I defined the ps1 files for each class in the ScriptsToProcess section of the psd1 file, both would work. This kind of cool, but also bad module practice. The files run in the ScriptsToProcess section are done so in the calling scope rather than the module scope. This means unloading your module leaves these bits behind. I haven’t tested it, but believe it will cause issues when you call your module from another module and then try to call the functions of your module from the global scope. In any case, it is a messy and terrible work around.

I read somewhere that loading multiple psm1 files when a module loaded will be supported in the future which will open up the ability to separate out classes into their own files. I think this will be a neat feature regardless of its impact on classes, but, it probably will only work with newer version likely leaving 5.0 and 5.1 systems in an odd spot where newer modules aren't loading classes from the extra psm1 files.

The internet is littered with questions about importing classes from modules and the response is usually about the Using statement. This boils my blood a bit. I import the module and I expect the module's classes to be available, just like when I import modules that include compiled DLL classes. It’s a valid assumption given the history of PowerShell and non-native classes. However, you must use the Using statement to work directly with PowerShell v5 classes defined in modules from the calling scope. 

Another fun fact about the Using statement: in a script, the Using statement(s) must be defined at the very beginning to work properly. I don’t know what all can be defined before the Using statement, but pretty much anything before the Using statement will break it. In the interactive shell, you can call Using at any time and it will work, but that is not the case with scripts.

This all makes PowerShell v5 classes very anti-pattern for what we are used to with PowerShell modules and non-native classes. It makes the v5 classes into special snowflakes. Special snowflakes have a way of not being used because they are a pain to maintain.

Lack of Arbitrary Namespaces

This is, admittedly, a cosmetic gripe and not a functional one. One nice aspect of the .NET framework is that everything is partitioned into namespaces. If you are not familiar with this concept, I’m referring to all those lovely dots in the .NET class names. For example, the System.Management.Automation namespace contains some classes you are probably familiar with, like the PSObject and PSCredential. The point of these namespaces is one of organization. A group of related classes are placed in an arbitrary namespace to make them easy to enumerate and to avoid clashes with objects of similar names in other namespaces.

A use case for this would be developing a module. You may not know what other modules and classes might be imported by consumers of your module. To avoid any name clashes between your classes and another module’s class, you might define your classes under an arbitrary name space that is the same as your module. Let’s say you were creating a CarBuilder module and you had several classes such as Door, Engine, Wheel, and Car. With .NET, you could define the CarBuilder namespace and then your classes under it as Carbuilder.Door, CarBuilder.Engine, CarBuilder.Wheel, and CarBuilder.Car.

This appears to be impossible with PowerShell v5 classes. You can still define your classes with a prefix in the name, but you cannot define them in a namespace. Continuing with the CarBuilder example, you would have to name your classes CarBuilderDoor, CarBuilderEngine, CarBuilderWheel, and CarBuilderCar. It’s somewhat cosmetic in nature, but, it also means that enumerating, autocompleting and intellisensing your classes can only be done by name matching instead of via namespace.

On Performance

One of the areas that initially turned me away from PowerShell v5 classes was that they were less performant than just creating a PSCustomObject with the type accelerator. I say “were” because I planned to repeat those tests for this blog post and I discovered something odd. This time around, a simple class with a String and Int as properties was out performing the PSCustomObject accelerator with the same properties. I’m not sure if my testing method is flawed or if they have made performance improvements in the 5.1.14393.479 version I’m testing with versus the 5.0 when I originally encountered the performance issues. The difference in my initial findings showed the PSCustomObject to be 5 times faster, but this time around the class is 2 times faster. In any case, it’s worth noting that a PowerShell v5 class may or be more or less performant than a PSCustomObject of a similar “shape”. You should test for yourself on your own systems if performance matters.

Why Not Just Use PSCustomObject?

I ask myself this often. There is very little difference between a PowerShell v5 class and a PSCustomObject at this point. Method functionality can be duplicated with ScriptMethod properties. You can set arbitrary type names on PSCustomObject with the use of PSTypeName. You can set custom object types as output types for functions. You can even filter for them in Param blocks. You can use ScriptProperty on either and you can even create hidden properties on PSCustomObject.

The one thing that classes offer over a PSCustomObject at this point is the strict type casting of properties. At least, I haven’t discovered how to duplicate this functionality with a PSCustomObject, but it may exist. Another plus for classes is the ability to explicitly document, via code, what the structure of the object looks like. Since a PSCustomObject is somewhat like an amorphous blob that is defined at creation, it can create problems if you are not strictly controlling how they are created or are creating them in more than one section of code. And finally, using PowerShell v5 classes for class based resources in DSC is an extremely good use case.

But, if you have any kind of version issues or are wanting to use classes in modules, be aware of the issue they cause.


I know that the PowerShell developers have many valid reasons for not implementing all the features I’m whining about here. I’m also not saying everyone should abandon classes. But, I am suggesting that it is not yet time for us to all jump on the class bandwagon. I have hopes that classes will improve in future versions and maybe some of the features lacking now will be added. There were other technical issues with classes I didn’t mention here because they are already slated to be fixed in upcoming versions. It is apparent that the devs care about the classes and won’t leave them feeble for long. But, for now, we should probably stop recommending classes all the time. I understand that they are sexy and new and everyone wants to play with the new toy. I just don’t think we are there yet.