Environment:
- macOS
- VS Code
- Microsoft AL extension: ms-dynamics-smb.al 18.0.2293710
- AZ AL Dev Tools / AL Code Outline: 16.78.0
- CRS AL Language Extension: 1.5.36
- Workspace contains a valid AL project with app.json
- Opening .app files from .alpackages, for example:
/Users/tonvanboven/Documents/Vako AL/Vako App/.alpackages/Microsoft_Base Application_27.5.46862.46929.app
Expected behavior:
Opening a .app file should show its contents, so I can inspect objects and drill into definitions, for example tables/pages/code in Base Application.
Actual behavior:
The custom editor opens but stays on:
“Loading objects, please wait...”
and never shows object contents.
What I found:
- The .app file itself is fine and contains source files under src/.
- The custom editor being used is AZ AL Dev Tools
azALDevTools.appPackageEditor.
- During activation/open, VS Code logs repeatedly show:
“No AL workspace folder is active. An AL workspace is active, if a contained AL project is active. For example, if the keyboard focus is at a contained AL file or the app.json file.”
- This happens specifically when opening a .app via the AZ AL Dev Tools custom editor.
- The helper viewer never reaches the point where it returns data to the webview, so the webview remains stuck waiting for
setData.
Likely root cause:
There appears to be an incompatibility between AZ AL Dev Tools 16.78.0 and the current Microsoft AL extension API / active workspace handling.
The .app viewer pipeline seems to depend on AL workspace activation semantics that no longer behave as expected with the current AL extension version.
The symptom is not that the .app is unreadable, but that the custom editor never finishes loading symbols because the active workspace is considered invalid during the load.
Additional note:
On macOS, CRS AL Language Extension also appears to assume process.env.USERPROFILE in places, which can cause activation issues because macOS normally uses HOME. That may be a separate bug, but the persistent .app hang remained centered around the active AL workspace error from the Microsoft AL extension.
Relevant logs:
Repeated extension host / renderer errors:
- “No AL workspace folder is active. An AL workspace is active, if a contained AL project is active. For example, if the keyboard focus is at a contained AL file or the app.json file.”
Impact:
This makes the .app object viewer unusable for inspecting Base Application and other dependency apps.
Request:
Could you please check compatibility of the .app custom editor / package symbol loading flow with the current Microsoft AL extension, especially around active workspace detection and custom-editor activation on macOS?
Environment:
/Users/tonvanboven/Documents/Vako AL/Vako App/.alpackages/Microsoft_Base Application_27.5.46862.46929.app
Expected behavior:
Opening a .app file should show its contents, so I can inspect objects and drill into definitions, for example tables/pages/code in Base Application.
Actual behavior:
The custom editor opens but stays on:
“Loading objects, please wait...”
and never shows object contents.
What I found:
azALDevTools.appPackageEditor.“No AL workspace folder is active. An AL workspace is active, if a contained AL project is active. For example, if the keyboard focus is at a contained AL file or the app.json file.”
setData.Likely root cause:
There appears to be an incompatibility between AZ AL Dev Tools 16.78.0 and the current Microsoft AL extension API / active workspace handling.
The .app viewer pipeline seems to depend on AL workspace activation semantics that no longer behave as expected with the current AL extension version.
The symptom is not that the .app is unreadable, but that the custom editor never finishes loading symbols because the active workspace is considered invalid during the load.
Additional note:
On macOS, CRS AL Language Extension also appears to assume
process.env.USERPROFILEin places, which can cause activation issues because macOS normally usesHOME. That may be a separate bug, but the persistent .app hang remained centered around the active AL workspace error from the Microsoft AL extension.Relevant logs:
Repeated extension host / renderer errors:
Impact:
This makes the .app object viewer unusable for inspecting Base Application and other dependency apps.
Request:
Could you please check compatibility of the .app custom editor / package symbol loading flow with the current Microsoft AL extension, especially around active workspace detection and custom-editor activation on macOS?