Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

`Install-PSResource`/`Save-PSResource` silently installs the `-beta` prerelease package instead of the requested stable version when both exist in the feed

Ouverte
  • Quelque chose ne va pas ?
#2,030 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
csharp
Domaine
cli, tooling

Piste de recherche

Commencez dans V3ServerAPICalls et suivez la manière dont la version stable demandée est associée à l’URL de téléchargement de packageContent. Reproduisez le problème avec un feed contenant à la fois 0.0.4 et 0.0.4-beta, puis vérifiez que Save-PSResource et Install-PSResource récupèrent le package stable sans -Prerelease, tout en conservant les métadonnées de version correctes.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Needs-Triage
Prerequisites
  • Write a descriptive title.
  • Make sure you are able to repro it on the latest released version
  • Search the existing issues.
Steps to reproduce
Register-PSResourceRepository -Name TestRepo -Uri 'https://<nuget-v3-feed>/index.json' -Trusted

# No -Prerelease switch, exact stable version requested
Save-PSResource -Name My.Module -Version '0.0.4' -Repository TestRepo -Path C:\temp\save -Verbose
# Same result with a range instead of an exact version:
Save-PSResource -Name My.Module -Version '[0.0.4]' -Repository TestRepo -Path C:\temp\save -Verbose

Verbose/debug output during resolution correctly parses the target as 0.0.4, but the actual download call fetches the -beta package:

DEBUG: Package version parsed as '0.0.4' satisfies the version range
VERBOSE: Performing the operation "Install-PSResource" on target "Package to install: 'My.Module', version: '0.0.4'".
DEBUG: In V3ServerAPICalls::HttpRequestCallForContent()
DEBUG: Request url is '.../packages/nuget/download/My.Module/0.0.4-beta/my.module.0.0.4-beta.nupkg'
Expected behavior
`Save-PSResource`/`Install-PSResource -Version '0.0.4'` (no `-Prerelease`) should download and install the **stable** `0.0.4` package — the one whose own metadata/nuspec version is `0.0.4` with no prerelease label — since a stable version satisfying the request exists in the feed.
Actual behavior
The cmdlet reports/logs version `0.0.4`, but downloads and installs the **`0.0.4-beta`** package instead. This was confirmed by comparing the two packages directly:

| | Stable (`0.0.4`) | Prerelease (`0.0.4-beta`) |
|---|---|---|
| Direct download URL | `.../download/My.Module/0.0.4/my.module.0.0.4.nupkg` | `.../download/My.Module/0.0.4-beta/my.module.0.0.4-beta.nupkg` |
| `.nuspec` `<version>` | `0.0.4` | `0.0.4-beta` |
| Manifest `ModuleVersion` | `0.0.4` | `0.0.4` |
| Manifest `PrivateData.PSData.Prerelease` | *(unset)* | `beta` |
| Size | 78,558 bytes | 78,537 bytes |
| SHA256 | `FFC470442D806FB8EFCBE5B08A6A97384CF69C50EC8AE09C90814FE25C26FD38` | `9BB45237A2D8AD41FB1DB36F8DE236AD6729726C6B75C19A3B3548B0BCBB196D` |

After running `Save-PSResource -Name My.Module -Version '0.0.4'` (no `-Prerelease`), the saved manifest is:


ModuleVersion=0.0.4
PrivateData.PSData.Prerelease=beta


i.e. content identical to the `0.0.4-beta` package, not the stable one, even though no `-Prerelease` switch was used and an exact stable version was requested.

`Find-PSResource -Name My.Module -Version '0.0.4'` (or `'[0.0.4]'`) still reports the resolved version as plain `0.0.4` — the mismatch only becomes visible by inspecting the installed/saved package's own content, not from the cmdlet's own version output.
Error details
## Prerequisites

- [x] Reproduced on the latest released version (`Microsoft.PowerShell.PSResourceGet` 1.2.0)
- [x] Searched existing issues — related but distinct from [#1247](https://github.com/PowerShell/PSResourceGet/issues/1247) (that issue is about a package with *no* stable version at all being blocked without `-Prerelease`; here a stable version *does* exist and is silently swapped for a prerelease one instead of being installed or blocked)

## Environment

- `PSResourceGet`: 1.2.0
- PowerShell: 7.6.5 (Core)
- Repository type: NuGet v3 protocol feed hosted on a private package registry (`My.Repo`)
- Package: `My.Module`, feed contains:
  - `0.0.4` (stable)
  - `0.0.4-beta`
  - `0.0.3-beta`
  - `0.0.2-beta`

## Root cause hypothesis

The registration/service-index metadata for the package is correct and unambiguous — the registration entries for `0.0.4` and `0.0.4-beta` point at two different, correctly-versioned `.nupkg` files. The bug appears to be in `V3ServerAPICalls` version selection during install: it appears to satisfy the requested version range against `0.0.4` for logging/verification purposes, but then constructs/selects the actual download URL using the highest catalog entry it iterates over (which lands on `0.0.4-beta`, likely because prerelease/stable identifiers with the same core version (`0.0.4` vs `0.0.4-beta`) aren't being disambiguated correctly when picking which entry's `packageContent` to fetch).

## Impact

This is more severe than #1247: instead of failing loudly or requiring `-Prerelease`, the cmdlet silently installs prerelease content while reporting a stable version, with no warning or error. Consumers pinning to an exact stable version (e.g. in CI/CD publishing pipelines) can end up running prerelease code without any indication.

## Workarounds

- Remove/unlist the prerelease version once its corresponding stable version is published (only one version per major.minor.patch core in the feed at a time).
- Bypass the resolver: download the stable `.nupkg` directly from its known `packageContent` URL and install manually.
Environment data
Get-Module Microsoft.PowerShell.PSResourceGet; $PSVersionTable

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Binary     1.2.0                 Microsoft.PowerShell.PSResourceGet  {Compress-PSResource, Find-PSResource, Get-InstalledPSResource, Get-PSResourceRepository…}

Key   : PSVersion
Value : 7.6.4
Name  : PSVersion


Key   : PSEdition
Value : Core
Name  : PSEdition


Key   : GitCommitId
Value : 7.6.4
Name  : GitCommitId


Key   : OS
Value : Ubuntu 24.04.4 LTS
Name  : OS


Key   : Platform
Value : Unix
Name  : Platform


Key   : PSCompatibleVersions
Value : {1.0, 2.0, 3.0, 4.0…}
Name  : PSCompatibleVersions


Key   : PSRemotingProtocolVersion
Value : 2.4
Name  : PSRemotingProtocolVersion


Key   : SerializationVersion
Value : 1.1.0.1
Name  : SerializationVersion


Key   : WSManStackVersion
Value : 3.0
Name  : WSManStackVersion
Visuals

No response

Langage dominant
C#
Étoiles
576
Forks
114
Merge moyen
23 h 17 min
PR mergées (30 j)
8

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de PowerShell/PSResourceGet

Toutes les issues de PowerShell/PSResourceGet

Issues similaires

Plus d'issues C#

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.