PSGetModuleInfo.xml invalidates the module .cat file

[f0rt]

Team,

After publishing and installing a module from PS Gallery we get one additional file called PSGetModuleInfo.xml. After calling Test-FileCatalog I get "ValidationFailed" result. This way our customers cannot verify the module content.

Thanks,
f012rt

[iSazonov]

@f0rt Thanks for your report. Please add a version information.

[anmenaga]

Easy workaround is to use -FilesToSkip PSGetModuleInfo.xml parameter; for example:

PS C:\> Test-FileCatalog "C:\Program Files\WindowsPowerShell\Modules\Microsoft.PowerShell.Archive\1.1.0.0\Microsoft.PowerShell.Archive.cat"
ValidationFailed
PS C:\> Test-FileCatalog "C:\Program Files\WindowsPowerShell\Modules\Microsoft.PowerShell.Archive\1.1.0.0\Microsoft.PowerShell.Archive.cat" -FilesToSkip PSGetModuleInfo.xml
Valid

[f0rt]

Here is the version information:

Name Value

---

PSVersion 5.1.15063.674
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.15063.674
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Is this going to be fixed? Because if not we should notify our customers.

[iSazonov]

@f0rt Can you use workaround with -FilesToSkip? I suppose this parameter just addresses your scenario.

[f0rt]

We can. The problem is that we're getting reports from customer about this issue. If this is not going to be fixed I guess our PMs will address with a blog post.

[joeyaiello]

@anmenaga can we talk about this at some point? Got some more context, not sure how we should fix it.

Install-module is creating this file. It's where we store certain metadata, notably what repository (think PowerShellGallery) the item came from. We're investigating what we can do. For now, I am planning a blog topic explaining the issue & workaround.

[ThomasNieto]

@SydneyhSmith / @alerickson any way we could get this fixed with PSGet 3.0?

[SydneyhSmith]

@ThomasNieto thanks for bringing this up, we are happy to explore if this fits into PowerShellGet 3.0....do you have any suggestions as to what you would like to see in PowerShellGet to fix this....one option would be to use the Save-PSResource cmdlet without the parameter -IncludeXML (which is currently available in 3.0), another way for users to check would be a -PublisherCheck parameter on Install (which has not yet been implemented)

[ThomasNieto]

@SydneyhSmith My recommendation would be to move all non-module shipped files out of the module directory so Test-FileCatalog will succeeded by default without any workarounds.

To accomplish that the PSGetModuleInfo.xml would be moved into a separate directory like how installed script information is stored in a InstalledScriptInfos directory. The same could be done for modules storing the XML files in ~\Documents\PowerShell\Modules\InstalledModuleInfos or $env:ProgramFiles\PowerShell\Modules\InstalledModuleInfos.

This would be a breaking change since v2 wouldn't be able to find the file anymore but currently Get-InstalledModule doesn't return modules installed with v3.

The only additional check I can see is when reading the xml files is to check to see if the module directory still exists as there is a possibility that the user could have manually deleted the module. Right now this is handled automatically since the xml file resides in the same directory as the module.

[alerickson]

@ThomasNieto that's a pretty simple solution! We can definitely do that. As you mentioned, it's not necessary that v3 modules work with v2 cmdlets, so I don't see any issue with creating a directory to store the file in.

Can we move this issue to PowerShellGet?

[ThomasNieto]

@alerickson I found that Get-Module returns a PSModuleInfo with a ResourceRepositoryLocation property. You'll want to update this logic to flex the old or new file path.

https://github.com/PowerShell/PowerShell/blob/8f37cced709168f313a00b2e3ee7088495bbcd7a/src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs#L2596-L2619

[4c74356b41]

I just came across this behaviour. I'm not sure is it me being thick, or its not possible to install signed modules from PSGallery? Here's how I publish the module:

New-Item `
    -Force `
    -Type Directory `
    -Path "C:\Program Files\WindowsPowerShell\Modules\nimbus\$moduleVersion"

Get-ChildItem `
    -Exclude "*json","runbook*" `
    -Recurse `
    -Path "module\path\*" `
    -File | Foreach-Object {
        Set-AuthenticodeSignature `
            -TimestampServer "http://timestamp.digicert.com" `
            -Certificate $cert `
            -FilePath $_.FullName | Out-Null
    }

New-FileCatalog `
    -CatalogFilePath "module\path\nimbus.cat" `
    -CatalogVersion 1.0 `
    -Path "module\path\"

Set-AuthenticodeSignature `
    -TimestampServer "http://timestamp.digicert.com" `
    -Certificate $cert `
    -FilePath "module\path\nimbus.cat" | Out-Null

Copy-Item `
    -Destination "C:\Program Files\WindowsPowerShell\Modules\nimbus\$moduleVersion" `
    -Exclude artifacts `
    -Recurse `
    -Force `
    -Path "module\path\*"

Publish-Module `
    -RequiredVersion $moduleVersion `
    -NuGetApiKey $NuGetApiKey `
    -Name nimbus

When I publish, there is no PSGetModuleInfo.xml file in the module. This is confirmed by the post on this thread. So when I do Install-Module nimbus it fails, because of the cat file check that is automated and the check fails due to the PSGetModuleInfo.xml, which gets injected into a module?

[4c74356b41]

@ThomasNieto hey mate, can you shed some light on this? is it currently not possible to sign modules and upload to psgallery?