"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 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
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 分钟
30 天内合并 PR
1

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

microsoft/AL 的其他 Issue

查看 microsoft/AL 的全部 Issue

相似的 Issue

更多 DevTools Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。