Please include the following with each issue:
- Describe the bug
In a large multi-root AL workspace, dependency version increments (for example Retail) can lead to intermittent dependency resolution instability in dependent projects.
Primary failure mode:
- Build fails with: The project with path ... has not yet been loaded.
- The same project builds successfully right after window reload, with no source code changes.
Second failure mode on Build (separate but related):
- Ambiguous reference between two versions of the same dependency app, for example:
- Trans. Sales Entry ambiguous between Retail 26.0.39.5 and 26.0.38.30
- Detailed Receipt Sales ambiguous between Retail 26.0.39.5 and 26.0.38.30
Important distinction:
- This is not the usual duplicate object definitions across two independent dependency apps.
- This appears to be stale/mixed dependency-version symbol resolution (old and new versions of the same dependency being considered at once) after version increment and publish cycles.
-
To Reproduce
Steps to reproduce the behavior:
-
Open a multi-root workspace with many interdependent AL projects (example: Custom, Retail, Reports, Example_Test).
-
Keep historical .app files in project folders (normal team practice for release history).
-
Increment Retail version and build/publish the new package.
-
Build a dependent project (for example Example_Test or Reports).
-
Continue editing/building in the same VS Code session.
-
Intermittently observe one of the following:
- The project with path ... has not yet been loaded (without trying to load it again as long as you wait)
- Ambiguous reference between old/new versions of the same dependency
-
Reload window and rebuild the exact same project without code changes.
-
Build succeeds after reload.
AL code snippet that demonstrates the issue:
// Dependent project app.json (pinned dependency)
{
"dependencies": [
{
"id": "TestID",
"name": "Retail",
"publisher": "Test Publisher",
"version": "26.0.39.5"
}
]
}
// Example dependent code that becomes ambiguous intermittently
var
TSE: Record "LSC Trans. Sales Entry";
begin
Page.Run(Page::"Trans. Sales Entry", TSE);
end;
- Expected behavior
- Dependent project should resolve only the pinned dependency version.
- Old versions of the same dependency should not participate in symbol resolution when the dependency is pinned.
- Build should not switch between not loaded and successful states without source changes.
- If tooling does detect multiple candidates, diagnostics should be deterministic and actionable.
- Actual behavior
- Build intermittently fails with project has not yet been loaded.
- Ambiguous references can appear between two versions of the same dependency after version increments/publish cycles.
- Reloading VS Code window clears the state temporarily.
Evidence currently available:
- Intermittent errors captured in workspace build output.
- Immediate success after reload for unchanged source.
- Multi-root workspace with many related AL extensions.
- Versions:
- AL Language: 17.0.2273547
- Visual Studio Code: 39.8.5
- Business Central: 26.x (from project metadata application 26.0.0.0; environment used for publish: _dev1)
- List of Visual Studio Code extensions that you have installed:
- Full installed list available from local extensions metadata at c:/Users/micha/.vscode/extensions/extensions.json
- AL-related examples currently installed:
- ms-dynamics-smb.al 17.0.2273547
- nabsolutions.nab-al-tools 1.46.0
- waldo.crs-al-language-extension 1.5.36
- andrzejzwierzchowski.al-code-outline 16.78.0
- davidfeldhoff.al-codeactions 1.0.37
- Operating System:
Additional request to product team:
- If a dependency is not pinned and multiple compatible versions exist, prefer highest compatible version or raise one actionable diagnostic listing candidate paths.
- Add command to rebuild AL dependency graph without full window reload.
Final Checklist
Please remember to do the following:
Please include the following with each issue:
In a large multi-root AL workspace, dependency version increments (for example Retail) can lead to intermittent dependency resolution instability in dependent projects.
Primary failure mode:
Second failure mode on Build (separate but related):
Important distinction:
To Reproduce
Steps to reproduce the behavior:
Open a multi-root workspace with many interdependent AL projects (example: Custom, Retail, Reports, Example_Test).
Keep historical .app files in project folders (normal team practice for release history).
Increment Retail version and build/publish the new package.
Build a dependent project (for example Example_Test or Reports).
Continue editing/building in the same VS Code session.
Intermittently observe one of the following:
Reload window and rebuild the exact same project without code changes.
Build succeeds after reload.
AL code snippet that demonstrates the issue:
Evidence currently available:
Additional request to product team:
Final Checklist
Please remember to do the following: