You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Install-PSResource and NuGet v3: Bad folder name created if version string has no build number #1908
Register a v3 feed, then install a module with a version string containing only major and minor versions (e.g. "2.1"):
Register-PSResourceRepository-Name test -Uri https://pwsh.gallery/index.json -Trusted
Install-PSResource SemVerPS -Repository test
Import-Module SemVerPS
This will give an error, because the folder is created as "2.1.0" instead of "2.1":
VERBOSE: Skipping the Version folder 2.1.0 under Module C:\Users\wellis\Documents\PowerShell\Modules\SemVerPS as it does not have a valid module manifest file.
Import-Module: The specified module 'SemVerPS' was not loaded because no valid module file was found in any module directory.
Expected behavior
Module is imported
Actual behavior
Importing module fails.
Error details
Exception : Type : System.IO.FileNotFoundException Message : The specified module 'SemVerPS' was not loaded because no valid module file was found in any module directory. HResult : -2147024894TargetObject : SemVerPSCategoryInfo : ResourceUnavailable: (SemVerPS:String) [Import-Module], FileNotFoundExceptionFullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommandInvocationInfo : MyCommand : Import-Module ScriptLineNumber : 1 OffsetInLine : 1 HistoryId : 28 Line : Import-Module SemVerPS Statement : Import-Module SemVerPS PositionMessage : At line:1 char:1 + Import-Module SemVerPS + ~~~~~~~~~~~~~~~~~~~~~~ InvocationName : Import-Module CommandOrigin : InternalScriptStackTrace : at <ScriptBlock>, <No file>: line 1PipelineIterationInfo : 0 1
Environment data
ModuleType Version PreRelease Name ExportedCommands
-----------------------------------------------
Binary 1.2.0 preview4 Microsoft.PowerShell.PSResourceGet {Compress-PSResource,Find-PSResource,Get-Instal…
Name Value
---------
PSVersion 7.4.13
PSEdition Core
GitCommitId 7.4.13
OS Microsoft Windows 10.0.26100
Platform Win32NT
PSCompatibleVersions {1.0,2.0,3.0,4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
At first glance it looks like a problem with pwsh.gallery. I think PSResourceGet uses the version info from the API for naming the folder.
PSResourceGet could get around it by checking the version in the manifest file *.psd1, and us it if it's different then what the API says. But should it? 🤔 Should it not trust the API?
Yeah, good point. It seems to me that the real problem lies with the Test-ModuleManifest cmdlet. It appears to be comparing the versions as strings. If it would parse them into e.g. System.Version first, this problem would go away.
SemVerPS.psd1 lists version as 2.1 and SemVerPS.nuspec lists it as 2.1.0. The server response from a V2 API repository (i.e PSGallery) will contain the version from the .psd1, whereas the server response from a V3 API repository (i.e PWSHGallery) will contain the version from the .nuspec. Then that version is used to create the version folder at Install-PSResource time, but Import-Module will have an issue.
I think we need to carefully reconsider the design of this aspect, thus will not make this in PSResourceGet 1.2 release.
wellis83 in the meantime, a workaround I'd suggest is to do Save-PSResource from the V3 API repository (i.e PWSHGallery, or NuGetGallery) to a local file share repository, and then Install-PSResource from the local repo and import it. In the example below, I use test-semver-module from NuGetGallery (V3 API) repository but it mimics the versioning scenario from SemVerPS from PWSHGallery, so that should work as well.
Activity
o-l-a-v commentedon Nov 19, 2025
That module has conflicting version info though.
When looking at files inside the
semverps.2.1.0.nupkg:pwsh.gallery API returns different info than PSGallery
At first glance it looks like a problem with
pwsh.gallery. I think PSResourceGet uses the version info from the API for naming the folder.PSResourceGet could get around it by checking the version in the manifest file
*.psd1, and us it if it's different then what the API says. But should it? 🤔 Should it not trust the API?wellis83 commentedon Nov 19, 2025
Yeah, good point. It seems to me that the real problem lies with the
Test-ModuleManifestcmdlet. It appears to be comparing the versions as strings. If it would parse them into e.g.System.Versionfirst, this problem would go away.o-l-a-v commentedon Nov 19, 2025
Kind of related: JustinGrote/ModuleFast#3
I don't think
pwsh.galleryhas a repo where we can create issues anymore, the old one is archived:anamnavi commentedon Dec 1, 2025
SemVerPS.psd1lists version as2.1andSemVerPS.nuspeclists it as2.1.0. The server response from a V2 API repository (i.e PSGallery) will contain the version from the .psd1, whereas the server response from a V3 API repository (i.e PWSHGallery) will contain the version from the .nuspec. Then that version is used to create the version folder atInstall-PSResourcetime, but Import-Module will have an issue.I think we need to carefully reconsider the design of this aspect, thus will not make this in PSResourceGet 1.2 release.
wellis83 in the meantime, a workaround I'd suggest is to do
Save-PSResourcefrom the V3 API repository (i.e PWSHGallery, or NuGetGallery) to a local file share repository, and thenInstall-PSResourcefrom the local repo and import it. In the example below, I usetest-semver-modulefrom NuGetGallery (V3 API) repository but it mimics the versioning scenario from SemVerPS from PWSHGallery, so that should work as well.