PowerShell Modules vs. Dot Sourcing: Which Approach Is Better?

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: Should you use modules or dot sourcing?

Modules and dot sourcing share similarities. In both techniques, PowerShell functions are stored in external files, making them 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 usually receive 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:

Related:Getting Started With REST APIs in PowerShell

C:\Users\<user name>\Documents\PowerShell\Modules\<module name>

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 go here:

C:\Users\<user name>\Documents\PowerShell\Modules\MyStuff

After creating your module, 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. As with modules, functions get stored in external files. However, with dot sourcing, you save the files 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 you store your external functions 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

Related:How To Optimize PowerShell ZIP Handling With the 7-Zip Module

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. 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 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 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. They work well for grouping a set of related functions.

So which technique should you use – modules or dot sourcing? I recommend using modules when 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.

Related:Enhancing PowerShell With .NET Classes and Methods