Skip to content

Test-ModuleManifest fails on manifest from New-ModuleManifest #6676

Closed
Closed
Test-ModuleManifest fails on manifest from New-ModuleManifest#6676
Labels
Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifResolution-AnsweredThe question is answered.

Description

@jwittner
Josh Wittner (jwittner)
opened on Apr 18, 2018

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      test

Actual 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.TestModuleManifestCommand

Environment 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

  1. jwittner commented on Apr 18, 2018

    @jwittner
    Josh Wittner (jwittner)
    on Apr 18, 2018
    Author

    Reviewing the code here:

    PowerShell/src/System.Management.Automation/engine/Modules/TestModuleManifestCommand.cs

    Line 136 in c1c5344

    string rootModuleExt = System.IO.Path.GetExtension(module.RootModule);

    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. =(

  2. mklement0 commented on Apr 19, 2018

    @mklement0
    Michael Klement (mklement0)
    on Apr 19, 2018
    Contributor

    The existing catch-all error message is unfortunately really unhelpful.

    In addition to the requirements you mention, the two files (*.psd1 and *.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.

  3. jwittner commented on Apr 19, 2018

    @jwittner
    Josh Wittner (jwittner)
    on Apr 19, 2018
    Author

    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.

  4. Josh Wittner (jwittner)
    closed this as completedon Apr 19, 2018
  5. Ilya (iSazonov)
    added
    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif
    Resolution-AnsweredThe question is answered.
    on May 26, 2018

  6. ronbok commented on Dec 3, 2018

    @ronbok
    Ron Bokleman (ronbok)
    on 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.

  7. mklement0 commented on Dec 3, 2018

    @mklement0
    Michael Klement (mklement0)
    on Dec 3, 2018
    Contributor

    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-ModuleManifest seems 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.

  8. ronbok commented on Dec 3, 2018

    @ronbok
    Ron Bokleman (ronbok)
    on 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.

  9. mklement0 commented on Dec 4, 2018

    @mklement0
    Michael Klement (mklement0)
    on Dec 4, 2018
    Contributor

    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.

    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-Module too 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 *.psd1 files' base name match the name of the enclosing directory: there should be checks for that too - see #8391

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifResolution-AnsweredThe question is answered.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions