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

オープン
#8,372 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
43/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
azure

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

"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
主要言語
PowerShell
スター
891
フォーク
287
平均マージ
4時間 7分
マージ済み PR(30日)
1

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/AL のほかの issue

microsoft/AL の issue をすべて見る

似ている issue

DevTools の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。