Tag Archives: Modules

Resolving Ambiguous Class Names Across PowerShell Modules

Right after my last post, I got to wondering what would happen if I had two modules with the same class named defined?

The dictionary defines ambiguous as “unclear or inexact because a choice between alternatives has not been made”. In context of this discussion, it means we have two different PowerShell modules that both have definitions for a class that is named the same (but may not necessarily look the same).

To quote one of the most often used phrases in technical blogging, “Let’s look at an example!”.

Here is our first module, which defines a class MyAmbiguousClass. As you can see it has one property and one method.

# MyAmbiguousModule1.psm1
class MyAmbiguousClass
{
  [string] $MyString = 'Ambigouous String 1'

  [string] GetSomeValue()
  {
    return 'Ambigouous Value 1'
  } 
}

Pretty simple. Now let’s look at a second module. This also has a class defined of MyAmbiguousClass, but it has two properties and one method, all with different names from the previous modules definition.

# MyAmbiguousModule2.psm1
class MyAmbiguousClass
{
  [int] $MyInteger = 2

  [string] $MyName = 'ArcaneCode'

  [string] DidILeaveTheStoveOn()
  {
    return 'Probably not'
  } 
}

You would then declare these at the top of your script thusly:

using module 'C:\PS\Classes and Modules\MyAmbiguousModule1.psm1'
using module 'C:\PS\Classes and Modules\MyAmbiguousModule2.psm1'

As described in my previous post, you would instantiate a new instace with this command:

$myClass = [MyAmbiguousClass]::new()

Now of course you can see the issue, it is not clear which version of the MyAmbiguousClass is being instantiated. What’s even scarier is PowerShell will execute this command without producing an error!

When PowerShell creates the new variable it looks through its memory to find the first time this class is defined, then it uses that definition. In this example, since the MyAmbiguousModule1.psm1 was loaded first, it is that definition that gets used.

If, however, the ‘using module’ statements had been reversed, and MyAmbiguousModule2.psm1 was first, then it is the definition for MyAmbiguousClass found in MyAmbiguousModule2.psm1 that would have been used.

Yikes!

So how to resolve? Well it turns out to be quite simple. All you have to do is prefix the class name with the module name, like so:

$myClass1 = [MyAmbiguousModule1.MyAmbiguousClass]::new()

Now intellisense will list the correct methods and properties, and we can access them in code.

$myClass1.MyString
$myClass1.GetSomeValue()

Will produce

Ambigouous String 1
Ambigouous Value 1

Likewise, we’ll prefix the second version with its module name, MyAmbiguousModule2:

$myClass2 = [MyAmbiguousModule2.MyAmbiguousClass]::new()
$myClass2.MyInteger
$myClass2.MyName
$myClass2.DidILeaveTheStoveOn()

Produces this output

2
ArcaneCode
Probably not

And there you go, resolving ambiguous class names across PowerShell modules is just that easy.

Advertisements

Accessing a PowerShell Class Defined In A Module From Outside A Module

PowerShell 5 introduced the concept of classes. This is an exciting new feature that will really help promote code reusability. It seems natural then, that you would want to organize your classes into PowerShell Modules.

It’s not obvious though, how to use a class defined inside a module from outside that module. There are, in fact, three methods available to you.

Let’s say you have a module, MyModule.psm1. In it you’ve defined a class:

class MyClass
{
  [string] $MyString = 'My String Value'

  [string] GetSomeValue()
  {
    return 'Some Value'
  } 

}

Simple enough. So how do we get to this masterpiece of class coding? The first technique has us creating a function inside the module. Within that function we return a new instance of the class.

function Get-NewMyClass()
{
  return [MyClass]::new()
}

# Export the function, which can generate a new instance of the class
Export-ModuleMember -Function Get-NewMyClass

Using it simply requires we import the module, then call the function. From there we can access the properties and methods of our function.

# Import our test module
Import-Module -Force 'C:\PS\Classes and Modules\mymodule.psm1'

# Use the function to generate a new instance of the 'MyClass' class
$myClassFunction = Get-NewMyClass

# Call a method from it
$myClassFunction.GetSomeValue()

# Get a property of the class
"MyString=$($myClassFunction.MyString)"

Pretty simple and straightforward. This can be a useful method if there are extra checks you wish to do inside the module prior to returning the new instance of the class.

The next method simply has us create a variable within the module, and export that as a module member.

$newClass = [MyClass]::new()
Export-ModuleMember -Variable newClass

You’d then use it in your script, just like any other variable:

# The module also has a variable exported from the function
# of type MyClass. 
"NewClass=$($newClass.MyString)"
$newClass.GetSomeValue()

With that shown I have to say I really don’t like this method. Primarily it is due to the issue of name collisions. If you have a variable also named $newClass in your script, it will block out the one from the class causing the collison.

The final option is the new using clause. I want to give a shout out to PowerShell MVP Dave Wyatt (blog | twitter) for pointing this one out to me.

As the first line of your script (except for comments, which are allowed before it) you use the syntax “using module” followed the module name, or path to the module.

using module 'C:\PS\Classes and Modules\mymodule.psm1'

Here I hard coded the path to the module since this is a simple demo. If the module had been installed in one of the default locations for modules, such as the WindowsPowerShell\Modules folder in the current users Documents area, you could have omitted the path and just put the name of the module.

After this, you would simply create a new variable from the class and use it normally.

$myClassUsing = [MyClass]::new()

# Setting / Getting property
$myClassUsing.MyString                  # Show default property
$myClassUsing.MyString = 'ArcaneCode'   # Change the value
$myClassUsing.MyString                  # Show the change

# Calling a method
$myClassUsing.GetSomeValue()

Note that if you had multiple modules you wanted to access the class definitions in, you would simply have multiple lines of “using module”, each line referencing the module you wanted.

using module 'C:\PS\Classes and Modules\mymodule.psm1'
using module 'C:\PS\Classes and Modules\anothermodule.psm1'

 

There you go. Three ways you can access a class definition stored inside a module, externally. Now not only can you create useful, reusable classes, you can also organize them into modules and use them outside the modules.