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

Aperta
#8,372 0 commenti 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
43/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
azure

Direzione di ricerca

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.

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

Descrizione

"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
Lingua principale
PowerShell
Stelle
891
Fork
287
Merge medio
4h 7m
PR unite (30g)
1

Preparare l'ambiente

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

Tutte le issue di microsoft/AL

Issue simili

Altre issue su DevTools

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.