The MorphX Development Environment and Tools

Debugger

Like most development environments, MorphX features a debugger. The debugger is a stand-alone application, not part of the AX 2012 shell like the rest of the tools mentioned in this chapter. As a stand-alone application, the debugger allows you to debug X++ in any of the following AX 2012 components:

• AX 2012 client
• AOS
• Business Connector (BC.NET)

For other debugging scenarios, such as web services, Microsoft SQL Server Reporting Services (SSRS) reports, and Enterprise Portal web client, see Chapter 3, “AX 2012 and .NET.”

Enabling debugging

For the debugger to start, a breakpoint must be hit when X++ code is executed. You set breakpoints by using the X++ code editor in the Development Workspace. The debugger starts automatically when any component hits a breakpoint.

You must enable debugging for each component as follows:

• In the Development Workspace, on the Tools menu, click Options > Development > Debug, and then select When Breakpoint in the Debug Mode list.
• From the AOS, open the Microsoft Dynamics AX Server Configuration Utility under Start > Administrative Tools > Microsoft Dynamics AX 2012 Server Configuration. Create a new configuration, if necessary, and then select the check box Enable Breakpoints to debug X++ code running on this server.
• For Enterprise Portal code that uses the BCPROXY context to run interpreted X++ code, in the Microsoft Dynamics AX Server Configuration Utility, create a new configuration, if necessary, and select the check box Enable Global Breakpoints.

Ensure that you are a member of the local Windows security group named Microsoft Dynamics AX Debugging Users. This is normally ensured by using setup, but if you did not set up AX 2012 by using your current account, you need to do this manually through Edit Local Users And Groups in Windows Control Panel. This is necessary to prohibit unauthorized debugging, which could expose sensitive data, provide a security risk, or impose unplanned service disruptions.

CAUTION

It is recommended that you do not enable any of the debugging capabilities in a live environment. If you do, execution will stop when it hits a breakpoint, and the client will stop responding to users. Running the application with debug support enabled also noticeably affects performance.

To set or remove breakpoints, press F9. You can set a breakpoint on any line you want. If you set a breakpoint on a line without an X++ statement, however, the breakpoint will be triggered on the next X++ statement in the method. A breakpoint on the last brace will never be hit.

To enable or disable a breakpoint, press Ctrl+F9. For a list of all breakpoints, press Shift+F9.

Breakpoints are persisted in the SysBreakpoints and SysBreakpointLists database tables. Each developer has his or her own set of breakpoints. This means that your breakpoints are not cleared when you close AX 2012 and that other AX 2012 components can access them and break where you want them to.

Debugger user interface

The main window in the debugger initially shows the point in the code where a breakpoint was hit. You can control execution one step at a time while inspecting variables and other aspects of the code. Figure 2-17 shows the debugger opened to a breakpoint with all the windows enabled.

FIGURE 2-17 Debugger with all windows enabled.

Table 2-6 describes the debugger’s various windows and some of its other features.

TABLE 2-6 Debugger user interface elements.

TIP

As a developer, you can provide more information in the value field for your classes than what is provided by default. The defaults for classes are New and Null. You can change the defaults by overriding the toString method. If your class doesn’t explicitly extend the object (the base class of all classes), you must add a new method named toString, returning and taking no parameters, to implement this functionality.

Debugger shortcut keys

Table 2-7 lists the most important shortcut keys available in the debugger.

TABLE 2-7 Debugger shortcut keys.