"Download symbols from global sources": custom feeds only work with Azure Artifacts URL layout, and package ID resolution picks the wrong package

Abierto
  • ¿Algo no está bien?
#8,372 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

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

Línea de trabajo

Start with the NuGet downloader methods named in the report: ResolvePackageIdByAppIdAsync, ResolvePackageVersion, and SearchPackagesAsync. Trace how it fetches the service index, searches feeds, and downloads packages, then compare that behavior with the NuGet v3 endpoints described in the issue. Done means standard public feeds work and package selection considers matching IDs and versions across feeds.

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

Descripción

"AL: Download symbols from global sources" has two problems in its NuGet downloader (Microsoft.Dynamics.Nav.Deployment, NuGetPackageDownloader):

A) Custom feeds only work if they follow the Azure Artifacts URL layout. The release plan says custom feeds (al.nugetFeeds) should be "public NuGet v3 feeds without authentication", but nuget.org, a standard public NuGet v3 feed, fails before any search is made. The downloader requests feedUrl + "/nuget/v3/index.json" for the service index and {feedUrl}/nuget/v3/flat2/{id}/{version}/{id}.{version}.nupkg for downloads, both of which are Azure Artifacts-specific.

B) Package ID resolution takes the first search hit whose ID contains the app GUID (ResolvePackageIdByAppIdAsync: list.FirstOrDefault(p => p.Id.Contains(appId))), and ResolvePackageVersion then only considers that ID's versions. When an older package for the same app exists under a former publisher name, that package always wins and the current one is never considered.

Also, SearchPackagesAsync returns the results of the first feed that has any hit. Because AppSourceSymbols is always searched first, a custom feed is never consulted for an app that also exists on AppSourceSymbols, even if only the custom feed has the requested version.

This becomes more pressing with the Azure DevOps public projects retirement in 2027 (see #8365). Once anonymous Azure Artifacts feeds go away, standard public NuGet v3 feeds such as nuget.org are the natural place for ISVs to publish symbol packages.

  1. To Reproduce

Dependency in app.json:

"dependencies": [
{ "id": "f15bbe6d-c2a3-4828-aa98-5a77cff4cd41", "name": "Dime.Scheduler", "publisher": "Dime Software", "version": "3.1.0.0" }
]

This app is published to nuget.org as DimeSoftware.DimeScheduler.BC27/BC28/BC29.f15bbe6d-c2a3-4828-aa98-5a77cff4cd41.

Bug A:DimeSoftware.DimeScheduler.BC27/BC28/BC29.f15bbe6d-c2a3-4828-aa98-5a77cff4cd41.

Bug A:DimeSoftware.DimeScheduler.BC27/BC28/BC29.f15bbe6d-c2a3-4828-aa98-5a77cff4cd41.

Bug A:

  1. Add to .vscode/settings.json:
    "al.nugetFeeds": ["https://api.nuget.org/v3/index.json"],
    "al.useOnlyCustomFeeds": true
  2. Run "AL: Download symbols from global sources".

Bug B:

  1. Use default settings (no custom feeds).

  2. Run "AL: Download symbols from global sources".

  3. Expected behavior

A) Treat the configured feed URL as the service index URL, as every NuGet client does. Use SearchQueryService for search and PackageBaseAddress/3.0.0 for downloads. The current behavior could be kept as a fallback when the URL does not end in index.json. The search itself works fine: https://azuresearch-usnc.nuget.org/query?q=f15bbe6d-c2a3-4828-aa98-5a77cff4cd41 returns all three packages.

B) Consider all package IDs matching the app GUID. Then either prefer the ID whose publisher segment matches the dependency's publisher, or pick the best version match across all of them. Ideally, merge results across feeds before selecting a version.

  1. Actual behavior

Bug A log:

Using 1 custom NuGet feed(s)
- https://api.nuget.org/v3/index.json
Only searching custom feeds (built-in Microsoft feeds will not be used)
Resolving package ID for AppId: f15bbe6d-c2a3-4828-aa98-5a77cff4cd41, Publisher: Dime Software
Failed to fetch service index from https://api.nuget.org/v3/index.json: BadRequest - One of the request inputs is out of range.
No packages found for search term 'f15bbe6d-c2a3-4828-aa98-5a77cff4cd41'
Package ID not resolved for Dime.Scheduler 3.1.0.0 - package may already exist locally
Error: Failed to download 1 package(s):
Error: - Dime.Scheduler 3.1.0.0

The requested URL is https://api.nuget.org/v3/index.json/nuget/v3/index.json, which returns HTTP 400 OutOfRangeInput. Using https://api.nuget.org as the feed results in a request to https://api.nuget.org/nuget/v3/index.json, which returns 404. nuget.org serves packages at https://api.nuget.org/v3-flatcontainer/{id}/{version}/{id}.{version}.nupkg, not under /nuget/v3/flat2/.

Bug B log:

Found 8 packages in feed https://pkgs.dev.azure.com/dynamicssmb2/DynamicsBCPublicFeeds/_packaging/AppSourceSymbols
W1 (worldwide) symbols selected (no localization suffix): 8 packages
Selected package: Dime.DimeScheduler.symbols.f15bbe6d-c2a3-4828-aa98-5a77cff4cd41
Exact version 3.1.0.0 not found for Dime.DimeScheduler.symbols.f15bbe6d-c2a3-4828-aa98-5a77cff4cd41, looking for latest compatible version with same major version
Version 3.1.0.0 not resolved for package Dime.DimeScheduler.symbols.f15bbe6d-c2a3-4828-aa98-5a77cff4cd41 - package may already exist locally

AppSourceSymbols contains two packages for this app:
Dime.DimeScheduler.symbols.f15bbe6d-c2a3-4828-aa98-5a77cff4cd41 (former publisher name): 2.3.0
DimeSoftware.DimeScheduler.symbols.f15bbe6d-c2a3-4828-aa98-5a77cff4cd41 (current): 2.4.0 up to 3.0.0

The legacy ID is always first in the search results, so any 3.x dependency fails, even though 3.0.0 exists under the current ID.

Related: #8108 (wrong symbols package ID picked for a dependency, via Paket).

  1. Versions:
  • AL Language: 18.1.2842859 (the same logic is present in preview v30.0.2863738)
  • Visual Studio Code: 1.145.0
  • Business Central:
  • List of Visual Studio Code extensions that you have installed: AL Language only (reproduced with others disabled)
  • Operating System: Windows
Lenguaje dominante
PowerShell
Estrellas
891
Forks
287
Merge medio
4 h 7 min
PR fusionados (30 d)
1

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 microsoft/AL

Todos los issues de microsoft/AL

Issues similares

Más issues de DevTools

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.