In Microsoft Dynamics AX 2012, code can be compiled to CIL and run in the .NET CLR. But what does CIL mean and what is it used for?
Common Intermediate Language (CIL) is in essence an object-oriented assembly language. It complies with the Common Language Infrastructure (CLI), which is a specification that was developed by Microsoft to describe a set of rules that programming languages need to comply with when they are targeting the CLI. One of the most important aspects of the CIL is that it is a platform- and CPU-independent instruction set. This enables the code to be executed on different environments as long as they comply with the CLI specification.
The following diagram shows that the languages are first compiled in CIL, after which the Common Language Runtime (CLR) compiles the platform-independent CIL code into machine-readable code:
As you can see, Microsoft Dynamics AX 2012 does not compile the X++ code directly to CIL. It is compiled to p-code, which can be interpreted by the kernel first, and this p-code is then compiled to CIL. This is quite a step forward because CIL is much faster than X++. We also need to keep CIL in mind when developing services later on. Code that runs on the server, such as batch jobs and services, will run in CIL, and therefore the X++ code needs to be compiled to CIL.
As compilation into CIL takes a long time, it is not done automatically when the X++ code is compiled. We need to do this manually when code has been modified by using the new CIL compilation buttons in the developer workspace, as shown in the following screenshot:
You can either start a full CIL generation or an incremental one. The main difference between the two is that incremental generation only regenerates the objects that were modified since the previous generation, while full generation completely regenerates all objects. As you can imagine, the incremental process is much faster than the full process, but do keep in mind that incremental generation will not always be enough. Sometimes, you will have no option than to completely regenerate CIL, for example, when you have removed a method from a class. No matter how you look at it, compiling CIL is not optional; without CIL, your services cannot run!
So, now the CIL generation is done, but what has changed and where can we find the results of the process? The answers to these questions can be found in the server's bin directory. By default, the filesystem folder is %ProgramFiles%Microsoft Dynamics AX60Server<Server Name>inXppIL. In this folder, you can find the resulting Dynamics.Ax.Application.dll assembly file along with a list of NetModule files.
NetModule files differ from .NET assemblies as they do not contain an assembly manifest. They only contain type metadata and compiled code. Next to the files containing the CIL code, this folder may also contain a subfolder named source. In this folder, we can find files with the .xpp extension. These files contain the X++ source code, and they can be used while debugging the CIL code in Visual Studio so that the editor and debugger can show the actual source code.
Note that the existence of the source subfolder depends on the server configuration. When the options are set to enable debugging on the server, the source folder will be generated at the AOS startup. Without the options enabled, you cannot debug, and so the source folder will not be generated as it is not needed. The following screenshot illustrates this:
