Repository navigation
Test-ModuleManifest fails on manifest from New-ModuleManifest #6676
Description
I ran into this when attempting to test one of my existing module manifests and was able to reproduce it with the simpler steps below.
Steps to reproduce
> New-ModuleManifest 'test.psd1' -RootModule 'test'
> Test-ModuleManifest '.\test.psd1'Expected behavior
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Binary 0.0.1 testActual behavior
Test-ModuleManifest : The module manifest 'test' could not be processed because it is not a valid PowerShell module manifest file. Remove the elements that are not permitted: C:\Users\me\test.psd1
At line:1 char:1
+ Test-ModuleManifest '.\test.psd1'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (.\test.psd1:String) [Test-ModuleManifest], ArgumentException
+ FullyQualifiedErrorId : Modules_InvalidRootModuleInModuleManifest,Microsoft.PowerShell.Commands.TestModuleManifestCommandEnvironment data
> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.2
PSEdition Core
GitCommitId v6.0.2
OS Microsoft Windows 10.0.16299
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Note: This succeeds on Windows PSVersion 5.1.16299.251
Activity
jwittner commentedon Apr 18, 2018
Reviewing the code here:
PowerShell/src/System.Management.Automation/engine/Modules/TestModuleManifestCommand.cs
Line 136 in c1c5344
It looks like an extension is required and the file must exist, which would be new requirements for the key. And even if I do specify an extension and ensure the file exists I get the same results. =(
mklement0 commentedon Apr 19, 2018
The existing catch-all error message is unfortunately really unhelpful.
In addition to the requirements you mention, the two files (*.psd1and*.psm1) must be located inside a folder named for their base name; i.e., in your case,test.Backward compatibility aside: the need for the extension is debatable, but the other requirements make sense, but only, of course, if accompanied by specific error messages.Update: while a check for that would be helpful, it does not currently exist.
jwittner commentedon Apr 19, 2018
Ok, I'm thinking it was some kind of encoding or new line issue as it was being rather spurious. I've got it working now so I'm moving on and closing this.
ronbok commentedon Dec 3, 2018
Test-ModuleManifest PowerShell Core 6.1.0 fails on macOS, but succeeds on Windows PowerShell 5.1. Same issue as above, but worse since the build agents for Azure DevOps throw this error and kill the build.
mklement0 commentedon Dec 3, 2018
Yes, I now see not just a change, but a problem in PS Core, though I don't think it's platform-specific - see #8388
Test-ModuleManifestseems to have other problems that are tracked in #6818, but I don't think they're platform-specific either.If you do think you've found a macOS-specific problem, please open a new issue with a reproducible case.
ronbok commentedon Dec 3, 2018
Well after following the workarounds above, I seem to have it working now and the build agent is not complaining anymore.
I agree that adding the .psm1 file extension to the root module name is a regression from PowerShell 5.0/.1, but doesn't mean its wrong. I see the Az replacements for AzureRm doing this and its likely a best practice.
The main thing that resolved this was creating a folder with the root module name and dumping the .psd1 and .psm1 into that folder or simply placing them there as part of the projects structure (like a Plaster template might do). Then Test-Manifest seems to be ok with it on PowerShell Core 6.1.0 on Windows. Still need to test macOS.
mklement0 commentedon Dec 4, 2018
It is wrong in that it is an inconsistency, given that omitting the extension works just fine when importing the module, so the validation is unnecessarily strict.
You could argue that the extension should be required to avoid ambiguity, but changing that for
Import-Moduletoo would be a breaking change.You could then argue that it's fine to only make the validation stricter while leaving the more lenient actual import behavior in place for backward compatibility - for that, we'd definitely need a specific error message.
As for the requirement to have the
*.psd1files' base name match the name of the enclosing directory: there should be checks for that too - see #8391