If you write a lot of PowerShell scripts, you will notice certain coding tasks come up again and again. I couldn’t count how many times I have borrowed code snippets from my other scripts instead of writing those lines from scratch.
While copying and pasting code between scripts is a functional method, it violates several PowerShell best practices. A more effective approach is to write modular code designed for reuse. The debate then arises: Is it better to use modules or dot sourcing?
Modules and dot sourcing share similarities. In both techniques, PowerShell functions are stored in external files so they are readily available to any script that requires them. However, the two methods have key differences.
PowerShell Modules
Module use is extremely common in PowerShell. For instance, an administrator tasked with an Active Directory-related management task would typically need to load the Active Directory module before proceeding. The Active Directory module contains all necessary cmdlets for managing Active Directory through PowerShell—or so it seems.
In reality, a module is nothing more than a collection of functions within a file. These functions are usually given cmdlet-like names, making it appear that a module is a set of cmdlets.
You can easily create a module with the functions you frequently use. Simply set up a file containing the functions and save it with a .PSM1 extension. Save the module file to $env:PSModulePath, usually located at:
C:\Users\\Documents\PowerShell\Modules\
It’s really important to store the module in this specific location and within a folder named identically to the module file. For example, if the module file is named MyStuff.psm1, it should be stored here:
C:\Users\\Documents\PowerShell\Modules\MyStuff
After creating your module, just use the Import-Module cmdlet to import it. Once imported, you can use the functions within the module as if they were native to your script.
Dot Sourcing
The concept of dot sourcing closely resembles that of using a module. Functions are stored in external files, but in this case, the files are saved with a .PS1 extension, just like a standard PowerShell script.
To invoke one of these externally stored functions in your script, all you have to do is call the external file at the start of the script. For example, if your external functions are stored in a file named C:\Scripts\Functions.ps1, the first line of your script should be:
. C:\scripts\functions.ps1
The execution of this command loads all external functions into memory, enabling their use as if they were native to your script.
Choosing Between Modules vs. Dot Sourcing
As you can see, modules and dot sourcing achieve the same thing. However, the consensus within the PowerShell community is that using modules is the better option. In fact, Microsoft describes dot sourcing as a non-scalable solution.
Despite this, there are situations where dot sourcing has its merits. If you have a handful of functions that you use sporadically, with little chance that you will ever need to share them, dot sourcing might be the way to go. After all, dot sourcing saves you from the work involved in creating a module. It’s a ‘quick and dirty’ approach when strict adherence to best practices is not a concern.
Another advantage of dot sourcing, though technically possible with modules, is not having to build a file containing all your functions unless you just want to. With dot sourcing, you can save each function in a separate file and selectively dot source only the functions you need, rather than an entire collection.
Conversely, modules can help you to stay organized and work well for grouping a set of related functions.
So which technique should you use – modules or dot sourcing? My advice would be to use modules in any situation where coding techniques and adherence to best practices are important.
However, if you are writing a script solely for personal use, with no intention of sharing it or having others use it, dot sourcing will usually get the job done just fine.
About the author
Brien Posey is a bestselling technology author, speaker, and 21x Microsoft MVP. In addition to his ongoing work in IT, Posey has trained as a commercial astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space.>
