More on CIL debugging

In the case you don't like debugging X++ code in Visual Studio there is a way to prevent code execution in CIL and to use the standard AX debugger instead.

This can be done in the Tools->Options form.

Debugging managed code in AX 2012

Since a lot of X++ code is now executed in CLR there should be a possibility to debug it. The standard AX debugger cannot help here since it is capable of debugging interpreted code only. However, Visual Studio 2010 can do the job.
There are few steps needed to be able to debug managed X++ execution using VS:

1. Breakpoints should be enabled on server (in AOS configuration).
2. Visual Studio should be started with elevated permissions (run as administrator).
3. Visual Studio should be attached to Ax32Serv.exe process (AOS process).

After that you can locate the source code and place the breakpoint. This can be done either using Application Explorer, or by opening .xpp source file directly from the [AX server path]\bin\XppIL\Source folder. Each method of each class or table has a separate .xpp file that is named [ClassName].[MethodName].xpp.

And that’s it. Now the debugging will happen is visual studio. Call stack, watches, etc. are also available.

Performance measurement

My favorite approach to measure performance of my code in AX is WinAPI::getTickCount() method. I find it as the most precise and simple way to do a quick measurement. Code profiler measures performance quite well, however it takes much more time to get the results.
How do you measure performance of your code in AX?

Example:
int timeInterval;
;

timeInterval = WinAPI::getTickCount();
doSomething();
timeInterval = WinAPI::getTickCount() - timeInterval;

Debug::assert

This method allows to check if some Boolean condition evaluates to true and if it doesn't - stop further execution and show stack trace. Debug::assert() should be used to validate some assumptions made in the code which should never happen if nothing is broken in the application. It means that wrong user input should not be asserted but rather validated by normal if statement and exception should be thrown if the input is wrong. However, if the code relies, for example, on query data source name, which can be broken only in development time - that is a good place to add assert to.

Example:
    Query query = new Query(querystr(Alertsetup));
    QueryBuildDataSource qbds;
    ;

    qbds = query.dataSourceName(identifierstr(EventRule));
    Debug::assert(qbds != null);

xSession::xppCallStack method

This method allows to get the current call stack - all caller method names and line numbers. For example, calling xSession::xppCallStack() from the line 13 at the Tutorial_RunbaseBatch.dialog() method will give the following call stack:

Actually I even found one nice practical application for it - SysTestAssert class can be modified so that it will display the line number where assertion has failed. It becomes much easier to debug unit tests with such modification.

Global::conView

It is nice sometimes for debugging purpose to see what is inside a container without starting debugger. There is a method conView on the Global class which allows to do that easily.