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

Aperta
#2,030 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
cli, tooling

Direzione di ricerca

Inizia in V3ServerAPICalls e traccia il modo in cui la versione stabile richiesta viene associata all'URL di download di packageContent. Riproduci il problema con un feed che contenga sia 0.0.4 sia 0.0.4-beta, quindi verifica che Save-PSResource e Install-PSResource recuperino il pacchetto stabile senza -Prerelease, preservando i metadati di versione corretti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
C#
Stelle
576
Fork
114
Merge medio
1g 2h
PR unite (30g)
7

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di PowerShell/PSResourceGet

Tutte le issue di PowerShell/PSResourceGet

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.