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:
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”.
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!
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.