Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,030 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp
Área
cli, tooling

Línea de trabajo

Comienza en V3ServerAPICalls y sigue cómo la versión estable solicitada se asigna a la URL de descarga de packageContent. Reprodúcelo con un feed que contenga tanto 0.0.4 como 0.0.4-beta y, después, verifica que Save-PSResource e Install-PSResource obtengan el paquete estable sin -Prerelease, conservando los metadatos de versión correctos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
C#
Estrellas
577
Forks
114
Merge medio
23 h 17 min
PR fusionados (30 d)
8

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PowerShell/PSResourceGet

Todos los issues de PowerShell/PSResourceGet

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.