More Actions ... in Workspace is missing

[finnpedersenkazes]

It is possible to correct (fix) all issues in an app, but not in a workspace.

How to reproduce

When opening VS Code on an App folder, an issue like PC0037 is detected. The light bulb offers a Quick Fix and More Actions.

Fix all issues in the Workspace has no meaning in that context, but will work as the Fix all issues in the project.

When opening the Workspace, the issues are detected, but the More Actions options disappear.

[Arthurvdv]

Investigation notes

This issue actually describes two distinct behaviors. I looked into both, using a headless LSP test harness plus a throwaway VS Code probe extension driving the real, unmodified production binaries (AL Language extension 18.0.2668733, ALCops 1.4.0 analyzer DLLs). No repo changes were made; this is a findings report to help scope the fix (or close the issue).

(b) "Fix all in Workspace" shown (and meaningless) in single-folder mode

Confirmed as an upstream limitation of the AL SDK, not something ALCops can control.

All ALCops CodeFixProviders register Microsoft's WellKnownFixAllProviders.BatchFixer. Its GetSupportedFixAllScopes() implementation (in the AL language server's Microsoft.Dynamics.Nav.CodeAnalysis.Workspaces assembly) returns Document/Project/Workspace unconditionally, with no parameter that exposes how many workspace folders are open. ALCops's code-fix providers have no hook to conditionally suppress the Workspace scope when only one project is loaded. The same applies to Microsoft's own CodeCop fixes — this is a generic behavior of the fix-all infrastructure, not specific to ALCops.

Short of ALCops abandoning BatchFixer and hand-rolling every fix-all scope itself (losing the "Fix all in Document/Project" behavior that does work correctly), there's no available fix on the ALCops side. Recommend documenting this as expected/by-design.

(a) "More Actions" (fix-all) disappearing when a workspace is opened

I could not reproduce this despite significant effort across two independent test setups, both against real production binaries (not simulated):

1. Headless LSP harness — drives Microsoft.Dynamics.Nav.EditorServices.Host.exe directly over stdio/LSP, replaying the AL extension's actual client handshake (initialize, al/setActiveWorkspace per folder, al/synchronizeProjectDependencies). Tested: single folder, an idealized multi-root sequence, and a faithful "second app active with the first as an unsynced dependency" sequence.
2. Real VS Code UI probe — a minimal extension (--extensionDevelopmentPath) that opens the real editor against a two-app workspace (App B depends on App A), waits for live diagnostics, then calls vscode.executeCodeActionProvider — the same API VS Code's own lightbulb widget uses — at the diagnostic range.

Repro assets: two minimal AL apps, one triggering PC0037 (ALCops) and AA0008 (Microsoft AA rule) via a direct field assignment + missing Insert() parens, the second depending on the first.

In every scenario (single folder; multi-root workspace, file in the first folder; multi-root workspace, file in the second/dependent folder) the code actions returned were identical: 10 actions for PC0037 and 11 for AA0008, both including "fix all in document/project/workspace". I also confirmed the AL extension instantiates a single LanguageClient for the whole VS Code session — not one client per workspace folder — which rules out a "wrong client queried for a non-primary folder's document" routing bug as the cause.

Since this doesn't reproduce at the language-server or code-action-provider level in the versions/configuration I tested, the cause (if it's still present) is more likely tied to something not captured in my repro — a specific VS Code/AL/ALCops version combination, particular al.* settings, or a narrow timing window during project-reference resolution that a manual test happens not to hit.

To help pin this down, could you share:

• VS Code version, AL extension version, ALCops extension version at the time you saw this.
• Whether "opening the Workspace" means a saved .code-workspace file, or code folderA folderB / File > Add Folder to Workspace.
• Your al.codeAnalyzers / al.enableCodeAnalysis settings (workspace, folder, and user scope) — in particular whether they're set once at the workspace level or duplicated per folder.
• Roughly how long after the workspace loads (and after the diagnostic first appears) you check "More Actions" — immediately, or after some idle time.
• Whether you see the same "More Actions" disappearing for a diagnostic from one of Microsoft's own analyzers (CodeCop, UICop, PerTenantExtensionCop and/or AppSourceCop), not just ALCops rules. If a Microsoft-analyzer diagnostic also loses its fix-all actions in the same workspace, that would point to the AL Language extension/server itself rather than anything ALCops can fix.

Happy to extend the test harness/probe to try a scenario that better matches your setup once I have these details.

---

Generated by Claude Fable 5

[Arthurvdv]

@finnpedersenkazes Did you by any chance had time to look into this? I'm not sure what I can do to resolve this.

[finnpedersenkazes]

@Arthurvdv Do you want me to show you the issue? Maybe I can reproduce it.