Update-ModuleManifest borking FunctionsToExport field

Tagged: 

This topic contains 8 replies, has 4 voices, and was last updated by Profile photo of Martin9700 Martin9700 4 months, 2 weeks ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #38778
    Profile photo of Martin9700
    Martin9700
    Participant

    Hi Everyone,

    Before I go spouting off on User Voice I wanted to find out if I'm just doing things wrong, or if there's a legitimate problem.

    I have a process that creates a Module Manifest file, and the FunctionsToExport field is a properly formed comma separated array. But then I go and do something crazy, like update the version number using Update-ModuleManifest:


    Update-ModuleManifest -Path .\My.Module.psd1 -ModuleVersion 2.0

    When I go back to the PSD1 file, I find FunctionsToExport is now a single array field with spaces separating the different functions instead.

    Anyone else run into something similar? Should I be "Get"ing the module first, then piping into Update?

    #38863
    Profile photo of Don Jones
    Don Jones
    Keymaster

    Reposted on Twitter to try and attract some attention for you.

    #38868
    Profile photo of Martin9700
    Martin9700
    Participant

    Thanks Don

    #38872
    Profile photo of Chris Hunt
    Chris Hunt
    Participant

    Yes. I have seen that and I think I understand why it happens and I think it is a bug. When you read a manifest file with Import-PowershellDataFile, you get back FunctionsToExport as an Object[] instead of a String[]. New-ModuleManifest and Update-ModuleManifest write that out as a space delimited String. I got around this by doing a foreach through the object[] array and writing $_ which gives you back a string[]. My guess is Update-ModuleManfiest goes through that process internally and the only work around is to overwrite the file using New-ModuleManifest with the FunctionsToExport parameter "scrubbed".

    #38874
    Profile photo of Martin9700
    Martin9700
    Participant

    Chris, I was afraid of this. Let's see if anyone else speaks up and if not I'll open a bug report on User Voice.

    #38903
    Profile photo of Martin9700
    Martin9700
    Participant
    #38958
    Profile photo of Mike F Robbins
    Mike F Robbins
    Participant

    I think you're running into the same issue I ran into a while back. There's an existing user voice item for it: https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/12479136–bug-update-modulemanifest-fails-if-typestoproces

    Also, check out this blog article of how I'm updating mine: http://mikefrobbins.com/2016/04/21/keeping-track-of-powershell-functions-in-script-modules-when-dot-sourcing-ps1-files/

    #38962
    Profile photo of Martin9700
    Martin9700
    Participant

    No, definitely not the same error. With the FunctionsToExport field getting flattened into a string, Update-ModuleManifest actually runs without error. The problem is Test-ModuleManifest (which Update-ModuleManifest uses) stores FunctionsToExport (actually ExportedFunctions) as a hashtable. In Update-ModuleManifest the .Keys property is used to expand them out, but it's not a [string[]] type so when using U-MM uses New-ModuleManifest it takes the KeyCollection type and flattens it into a single string.

    If you check out the User Voice I opened you'll see the explanation and fix. Please up vote too!

    #38963
    Profile photo of Martin9700
    Martin9700
    Participant

    My ultimate goal is to integrate version control with Appveyor, and since I have the build number from Appveyor it makes sense to Update-ModuleManifest during integration testing and commit back to the repo. Only I can't because of this problem. I'm sure I could hack a workaround–and likely will eventually–but I'd really rather see the problem fixed.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.