Name is Anant Dubey and the intent to create this blog is to discuss the problems and issues that developer face in the dynamics AX development and to share the new things that come up with the new version of AX.
CIL stands for Common Intermediate Language and it works
together with the CLI or Common Language Infrastructure, which is basically a set of rules on
programming languages that will compile with the CIL.
Intermediate Language), formerly known as MSIL
(Microsoft Intermediate Language) or sometimes simply IL is a low-level language used by
The runtime (CLR) doesn’t work directly with high-level
languages like C#, it works with CIL and compilers of high-level languages
simply generate CIL. The runtime handles CIL in the same way regardless it was
generated from C#, Visual Basic, IronPython… or from X++.
We have two types of CIL compilations, the incremental CIL and the full CIL compilation. The major
difference between the two of them is that the incremental CIL would
compile only the objects that were modified since the last incremental
Compile: -The compile is to convert x++ source code into p-code.
each and every table defining the value of your EDT
Full CIL :- generate CIL is about to convert the p-code into CIL,
referred to as the byte code which, at run time, is used by the CLR to convert
into native code for execution on the computer. It is easier to understand that
a full CIL generation involves converting all p-code into CIL, finally it
converts to the binary Language.
Incremental CIL :- incremental CIL generation involves only the “changed” p-code
artifacts that need to be converted into target CIL. Incremental CIL
would compile only the objects that were modified since the last incremental
Some X++ batch jobs can now complete in much less time. All
X++ code that runs on the AX32.exe client still runs as interpreted p-code.
However, all batch jobs now run as Microsoft .NET Framework CIL, which is often
much faster than p-code.
Classes, tables, and enums are types in the X++ language. X++ types
can be compiled to CIL. The queries and forms in the AOT are not X++ types, and
they cannot be compiled to CIL. This means there are a few minor cases where
calls from CIL to X++ p-code can cause an exception.
Suppose a method that is running as CIL calls a method on a query. The
query method calls the ClassFactory system class of Microsoft
Dynamics AX. This case causes an exception to be thrown. The problem is that
the CIL session does not have access to all the system classes, yet the query
method makes a call to a system class.
On the XppIL folder, there is a bunch
of files. These files are NetModule type files and they only contain type
metadata and compiled code.
There is a folder named “source”, and
within this folder we find a bunch of files with the .xpp extension, which have
x++ source code and are used to debug CIL code when working with services and
The “existence” of the source folder is
directly related to our server configuration when choosing to enable debugging
on the server.
Sometimes while Generating we Got an
error like this:-
For resolving this error firstly compile the full application &
then Generate full CIL again. If error still exists do this step
Step 1: Stop the AOS
Step 2: Delete all of the source in theC:\Program
Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\bin\XppIL directory
Step 3: Start the AOS
Step 4:Perform a
Step 5: Perform a full CIL generation
After a FULL CIL compilation I got the
I just went to the object in question and
compiled them separately.
All batch jobs and service operations now run in managed code (IL) and require different debugging steps. Rather than setting breakpoints within X++, you need to set them within the IL code that corresponds to the X++ code and debug in Visual Studio.
Open AX 2012 or R2.
Open Visual Studio as 'administrator' and attach the debugger to the Ax32Serv.exe process. in VS: Debug->Attach to Process.
Note that it may also be necessary to change the ‘Attach to’ selection to ‘Managed (v4.0) code’ and make sure “just my code” is unchecked in VS: tools->options->debugging->General
Once done, open up the file you want to debug in Visual Studio. All of the X++ code is compiled into IL and can be found in the following directory after deployment: ..\Program Files\Microsoft Dynamics Ax\6.0\Server\AxaptaDev\Bin\XppIL\source\ (NOTE:- make sure that your ax server configuration and local configuration in breakpoint enabled and in the source folder it contains all of AX classes with methods this is created when you generate CIL. If you done any modifications then you have to generate CIL).
Set a breakpoint in the file you opened in Visual Studio.
Go to Ax and run the process in batch mode, or execute the service operation. This will end up hitting your breakpoint, provided you set it in the right place.