Beware of the PowerShell Update-ModuleManifest Function

I recently presented a session for the Mississippi PowerShell User Group on PowerShell Non-Monolithic Script Module Design. While preparing for that session, I discovered that a problem I had previously experienced with Update-ModuleManifest when trying to update the FunctionsToExport section when FormatsToProcess is specified appeared to be resolved in PowerShell version 5.1 (I’m running build 14393). The details of this bug can be found here. I also noticed that Nicholas Getchell had written about this problem being resolved on his blog.

What I discovered is that Update-ModuleManifest does a little too much updating which can cause problems. To demonstrate this problem, I’ll create a script module named MyModule containing the following code:

The previous code is saved as MyModule.psm1 in the following folder: $env:ProgramFiles\WindowsPowerShell\Modules\MyModule

A function named Get-MrSystemInfo is created:

That function is saved as Get-MrSystemInfo.ps1 in the same folder as the PSM1 file.

And finally a module manifest is created:

When designing modules with a non-monolithic approach and specifying a requires statement for a module in one of the functions, as shown in the Get-MrSystemInfo example, causes all of the functions that are part of the specified module to show up as being part of your module.

In this scenario, the CimCmdlets are showing up as being part of MyModule:

I’ve written about this problem in a previous blog article and it’s easy enough to resolve by removing the ‘*’ from the CmdletsToExport section and replace the ‘*’ in the FunctionsToExport section of the module manifest with your actual function names.

The default settings in the module manifest that was previous created in this blog article:

The problem is that when you run Update-ModuleManifest to add the function name to FunctionsToExport:

It not only changes the ‘*’ in the FunctionsToExport section of the manifest to the function name that was specified, but it also updates CmdletsToExport to contain all of the cmdlets contained in the CimCmdlets module and it removes the ‘*’ from the AliasesToExport section of the manifest.

Update-ModuleManifest had one action to perform and only one action which was to update the FunctionsToExport section in the module manifest as previous specified.

To workaround this problem in this scenario, you can change CmdletsToExport to @() prior to running Update-ModuleManifest and it won’t be changed. You could also specify the -CmdletsToExport parameter with the @() value when creating the module manifest to prevent this problem from occurring.

My recommendation is not to use ‘*’ anywhere in your module manifest <period>.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: