Large multi-root AL workspace : intermittent dependency resolution instability in dependent projects, Failing Builds

Please include the following with each issue:

1. 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.

2. To Reproduce
   Steps to reproduce the behavior:

3. Open a multi-root workspace with many interdependent AL projects (example: Custom, Retail, Reports, Example_Test).

4. Keep historical .app files in project folders (normal team practice for release history).

5. Increment Retail version and build/publish the new package.

6. Build a dependent project (for example Example_Test or Reports).

7. Continue editing/building in the same VS Code session.

8. 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

9. Reload window and rebuild the exact same project without code changes.

10. 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;

3. 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.

4. 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.

5. 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:
  • Windows
  • Linux
  • MacOS

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:

• Search the issue repository to ensure you are reporting a new issue
• Reproduce the issue after disabling all extensions except the AL Language extension
• Simplify your code around the issue to better isolate the problem

Internal work item: AB#647968

Start with the dependent project's app.json and reproduce the issue through the AL Language extension's Build and publish flow in the described multi-root workspace. Compare dependency resolution before and after a VS Code window reload, focusing on the pinned Retail version and historical .app files. Done means unchanged source builds consistently, only the pinned dependency participates, and any multiple candidates produce a deterministic diagnostic.