This article provides an overview of a new feature introduced in PrimalScript 8.1.179 and PowerShell Studio 5.8.220 that allows you to add modules to the MSI file that installs your PowerShell application.
Modules are a substantial part of the PowerShell infrastructure; in many ways, they serve the same purpose as DLLs or assemblies do for developers using traditional compiled languages. They allow you to share code with defined interfaces amongst your projects, applications, organization, and peers. Within a larger project, they enable you to distribute defined tasks to individuals or groups of developers who can implement the already defined interfaces without impairing other tasks. Modules make your development tasks more manageable in many ways, so you should employ them whenever possible.
There is, however, the hurdle of module deployment.
Module Deployment
The prescribed way to deploy modules calls for using a module repository, from which you will retrieve and install any PowerShell module you need. SAPIEN PowerShell Module Manager is an excellent tool for this purpose because it makes the process more visual and streamlines module management. This is all well and good if you share your modules with the public on PowerShell Gallery or any other public repository. It is relatively simple to include a script that installs required modules from PSGallery and to call this script either from your application on the first run or from a custom action in your installer.
However, this is not really an option if you are creating PowerShell applications for closed networks that are air-gaped or behind proxy servers restricting internet access. Even if access to PSGallery is possible, you may not want—or even be allowed—to publish your corporate modules to a public space. You could set up and use your own corporate gallery, but that can be overkill for a handful of modules and will fail if you publish to multiple islands of isolated networks.
This is where the new feature in our MSI builder comes in. You can now add modules from your development machine to the MSI file that installs your PowerShell application.
Installer – PowerShell Modules
The new ‘PowerShell Modules’ section in the SAPIEN Script Packager enables you to pick and choose module folders to add to your installer:
Modules are generally specific to Windows PowerShell and PowerShell 7, but of course you can add the same module twice if it is PowerShell version agnostic.
Install for Current User or All Users
If you checked the option to ‘Install for all users’, the install folder for these modules are:
- C:\Program Files\WindowsPowerShell\Modules
- C:\Program Files\PowerShell\Modules
Note that this requires your installer to have admin rights.
If you want the modules to be installed for the current user only, the install folder will depend on the PowerShell version:
- C:\Users\<User>\Documents\WindowsPowerShell\Modules
- C:\Users\<User>\Documents\PowerShell\Modules
Options for Existing Files and Modules
There are options to not overwrite existing files and to leave modules in place on uninstall. We recommend leaving the “Do not overwrite existing files” flag on. Your own modules should be properly versioned (i.e., in a version-specific folder) to avoid confusion and errors.
Whether your modules are of any use if your application is uninstalled depends entirely on your situation. If multiple applications share your modules, it is likely a good idea to leave them in place.
Windows Installer does keep a tally of all files and folders installed. So if another installer already installed a module (Pester is a great example), adding it to your installer will do nothing. If Windows Installer detects that you are attempting to install a folder with files that are already installed, it will just skip them—no warning, no message, and in this case, no indication added to a log. Because this solely depends on the target environment, we are unable to display any warning or error during the build process. Just be aware that if a module you added does not get installed—no matter what you do—it is most likely under the control of another installer.
Module Organization
We highly recommend adding the modules your application needs from a staging folder and not from one of your local PowerShell module folders. The build process will issue a warning in such a case.
If you intend to test your installer locally, you would potentially install modules to their source location—overwriting and/or uninstalling them—which can lead to all sorts of undesirable effects. We suggest you place the modules you intend to include in MSI files in a separate folder, for example:
- C:\Installers\SourceModules\<module name>\<module version>
Feedback
Please leave feedback or feature requests in the comments below. If the comments are closed, you can post in our SAPIEN Support Forum.
