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.

X++ can be compiled to CIL in AX 2012

In AX 2012 X++ code can be compiled into CIL and executed in CLR environment hosted on the application object server. This means X++ became almost a .NET language. Almost, because there are still some X++ artifacts that can only be interpreted, for example forms. However the vast majority of server-side code can be compiled into CIL.

Because of that it is important to remember to regenerate CIL after changes have been done to the code. Since CIL compilation takes quite some time, it is not done automatically during regular X++ compilation. There are new compilation commands – Generate Incremental CIL (rebuilds assemblies that are affected by the change) and Generate Full CIL (rebuilds all assemblies). Those commands are applicable to the whole application and not to a specific X++ object (class, table, etc.). AX automatically determines what X++ objects should be compiled into CIL based on the registered entry points, e.g. if it is specified that some method should be executed in CLR, then the whole “using” reference tree of this method will be compiled into CIL.


There are several ways to specify that some code should be executed in CLR instead of X++ interpreter. Right now I want to show only one of them just to illustrate how easy it can be.


TestILExecution job will be executed using X++ interpreter (just in the same way as in previous AX versions), but postSalesOrderPackingSlip() method will be executed in CLR. As you can see, postSalesOrderPackingSlip() method is a standard method of a standard X++ class. Switching will happen because this method is registered as a service operation of FormLetterService service, and the service itself is a member of the AxClient service group which is deployed on the AOS.