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.

Working with CLR null references

In C# if a method has return value of type string it is possible to return null. If you'll try to use this method from AX you'll get exception because null value cannot be marshaled to X++ string (it is not nullable).
To avoid this failure there is a possibility to validate if returned value is null by using CLRInterop::isNull() method.
Example:
if (ClrInterop::isNull(myCLRObject.method1()))
{
    info("Null value was returned");
}

Switch statement and CLR enums

There is a really weird bug in AX 2009 with CLR enumerations. If the code has "if" statement that validates value of a variable of CLR enum type everything is fine. However, the same "switch" statement fails with kernel exception.
Example:

MyNamespace.MyEnum enum;

enum = MyNamespace.MyEnum::Value1;

if (enum == MyNamespace.MyEnum::Value1)
{
    info("Everything is fine");
}

switch (enum)
{
    case MyNamespace.MyEnum::Value1 :
        info("And not so good here");
        break;
}

Result:
Error executing code: Wrong argument types for comparison.

Getting CLR exception message

An exception that appears in AX if something went wrong in the managed code you are running doesn't contain much information about what have happened. For example, it can be something like: Object 'CLRObject' could not be created. But, there is a trick which helps to get more meaningful message, actually the one that was thrown in CLR - AifUtil::getClrErrorMessage().

Example:
ServiceNamespace.MyService service;

try
{
    service = new ServiceNamespace.MyService();
}
catch
{
    throw error(AifUtil::getClrErrorMessage());
}

Gives the following information: