Recently, with the Developer Preview – February 2019, a new feature was added to the AL extension for Visual Studio Code: Debug without publishing. This new feature brings more than you would expect. It is not just another option in the list of Publish and Publish without debugging.
What’s the difference? With the option Publish and Publish without debugging you are going to publish the extension that you currently have open in the VS Code workspace. With the option Debug without publishing, you don’t publish anything. In fact, you don’t even have to have any code open. This option allows you to debug the actual code on the server instead of debugging the code inside the VS Code workspace you have open. A quote from the blog post about Developer preview – February 2019:
Please be aware that if you start debugging without publishing you will be debugging the last published code of your app.
What you basically need is a workspace in VS Code with a server configuration in the launch.json. This server will be the server that you are going to debug. You don’t even need to download the symbols files. And the app.json can also be ignored. Just follow these steps:
- Create a new workspace with AL:Go!
- Configure launch.json for the server you want to debug
- Press Ctrl+Shift+F5
and a debugging session will be started. If the code runs into an error, the corresponding .dal file will be downloaded. From there you can view variables, set breakpoints (in the .dal file) and step through the code.
The launch.json has a breakOnError setting. By default this setting is true. Since there is no way to set breakpoints manually, you wil need this setting. Optionally you can use the setting breakOnRecordWrite.
Again, basically the only thing you need to debug the actual code is a workspace with a launch.json file.
I believe this feature helps to support scenario’s like ‘an error occurred but I don’t know where the error comes from’. The debugger will allow you to debug any code, including all installed extensions.
One final comment: according to this documentation, you can’t debug an extension that has set ShowMyCode = false in the app.json.
That’s great. Except you can’t fix the bug. You’ll have to create a support ticket with MS wait days if not weeks for a fix. And if it’s a critical error, your business suffers.
Do you have experience with that? My experience is that blocking issues are solved right away. And this new feature helps to locate the issue, resulting in a shorter time to fix.
Please provide full docu to do this .. it very helpfull
Full docu to do what? Debug? Or loggin issues with Microsoft?
Also, note the added “tenant” setting in the launch file for when you need to Debug a customer installation. Without this it goes to the default tenent for the Windows login.
This would be a great thing if:
You could select a specific session!
But it is still not possible to debug webservice calls, job scheduler or different user sessions. They often act divergent to your developer role or cannot be tested in a similar way.
You are right on that, as far as I know, it’s on the backlog. No ETA though.
I agree this is a fantastic feature.
How do we avoid useless and “empty” project folders everywhere? If we have to do AL:Go! every time we want to debug something?
Just set the server you want to debug in the launch.json and off you go. No need to create an empty workspace for every single debug session or server.
Starting the debug process works properly. A new session gets started and connects to the customer’s tenant with my credentials.
It just does not stop at the error (even though “breakOnError”: true, is set in the launch.json).
Downloading the symbols worked as well.
I just cannot stop at an error in base app code.
Anything that could be wrong?
{
“version”: “0.2.0”,
“configurations”: [
{
“type”: “al”,
“request”: “launch”,
“name”: “Microsoft Cloud Sandbox”,
“tenant”: “XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX”,
“breakOnError”: true,
“launchBrowser”: true,
“enableLongRunningSqlStatements”: true,
“sandboxName”: “Sandbox”, //SANDBOX NAME
“enableSqlInformationDebugger”: true
}
]
}
I’ve experienced the same behavior. Which version is the sandbox?
14.5
This sandbox is brand new and derived from production.