The basic concept behind debugging is the breakpoint, which is a mark that you can set on a statement. When the program flow hits the statement, the debugger is kicked in and suspends execution (technically, it breaks) until instructed to continue. Without any breakpoints, the code would run just fine as long as the debugger is active.

The debugger will automatically stop the execution of the code only when it encounters an error, or if it has been instructed in the launch.json file to break on record changes.

A developer could also use the debugger to find potential logic errors since the debugger enables them to execute AL code syntax, one statement at a time, while inspecting the contents of variables at each runtime step. In this way, the developer can check and match what is expected when they have designed the application extension.

You can run the debugger from Visual Studio Code in three ways:

• Click Debug | Start Debugging.
• Press the F5 shortcut key.
• Go to DEBUG view (Ctrl + Shift + D) and press the green right arrow in the top bar. The top bar also shows the debugger session name specified in the launch.json file. It will open that file if you press the gear icon. The last icon on the right enables and shows the debug console, which typically shows contextual debugging information. The following screenshot depicts the debugger top bar:

These actions will result in building your extension (equivalent to Ctrl + Shift + B), if this has not already been done, and then publishing the extension in the target online sandbox tenant.

Since the release of Dynamics 365 Business Central Spring 2019, it is now possible to run a debugger session without the need to build and publish the extension over and over again. This helps reduce the debug cycle and increases development productivity. To try this, in Visual Studio Code just hit Ctrl + Shift + F5, or run the Command Palette (Ctrl + P) and search for AL: Debug without publishing.

The launch.json file contains some elements that influence the debugging behavior and its target. The following is a list of them and what they do:

• BreakOnError: Specifies whether the debugger should stop when it hits an error.
• BreakOnRecordWrite: Specifies whether the debugger should stop on record changes (typically record create or update).
• Tenant: Specifies the Azure Active Directory (AAD) tenant in which to create the debugger session.
• SandboxName: With the April 2019 update, it is possible to have multiple sandbox tenants. This parameter will let the developer specify the name of the sandbox to which to connect the debugger session.

Also, the app.json file contains a parameter that is vital for the debugger to work against specific extension code: ShowMyCode.

If you publish and debug the extension as-is, it does not need to have this value set: it would work as implicitly set to true.

Nevertheless, if the code needs to be debugged from other extensions (and different Visual Studio Code sessions), since the default value for ShowMyCode is false, this parameter must be explicitly declared and set to true.