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.
