"Download symbols from global sources": custom feeds only work with Azure Artifacts URL layout, and package ID resolution picks the wrong package
还没有人认领这个 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.
- 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:
- Add to .vscode/settings.json:
"al.nugetFeeds": ["https://api.nuget.org/v3/index.json"],
"al.useOnlyCustomFeeds": true - Run "AL: Download symbols from global sources".
Bug B:
-
Use default settings (no custom feeds).
-
Run "AL: Download symbols from global sources".
-
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.
- 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).
- 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 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microsoft/AL 的其他 Issue
-
accepted al-tools bug
难度 2/5 1-3 小时 新手友好度 72/100
-
难度 3/5 1-2 天 新手友好度 35/100
-
难度 4/5 3-5 天 新手友好度 15/100
-
难度 4/5 3-5 天 新手友好度 35/100
-
suggestion
难度 5/5 一周以上 新手友好度 45/100
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 74/100
igormcsouza/tether#278 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 83/100
microsoft/monaco-editor#5577 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
microsoft/vscode-containers#655 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
pylint-dev/pylint#11791 ·
维护者通常 1 天内回复
-
Document and enforce pull request review guidelines可能已有人在做 @dashorst 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复