Faster way to compile X++ code using “AXBuild” Utility.

General Architecture

Compiling on the Server Tier

AxBuild.exe can accomplish a full compile of all X++ code, into AX p-code, many times faster than the traditional compile that you start from the MorphX client menu. AxBuild.exe is run on the Application Object Server (AOS) tier at a cmd.exe command prompt.

The AxBuild.exe utility program involves compiles to p-code only, and it does not go further by compiling to .NET Framework CIL.

AxBuild.exe became available in cumulative update 7 for Microsoft Dynamics AX 2012 R2.

AxBuild.exe is installed in the same directory with ax32serv.exe, which is the program name for the AOS. Usually it will be located in the folder ” C:\Program Files\Microsoft Dynamics AX\60\Server\<AOS Server Name>\bin”.

The larger amount of active memory might be important for full X++ compiles that involve an extremely large amount of X++ source code.

AxBuild.exe starts several new but temporary instances of the AOS. From the Registry, each temporary AOS uses the same configuration information that is used by a permanent AOS that you identify with the /aos parameter. This is one reason why AxBuild.exe must be run by an account that has no less security authority than the account that runs the permanent AOS has. AxBuild.exe coordinates the work of every temporary AOS that it starts. It tells each AOS which pieces of the full X++ compile to accomplish. It gathers the results from each AOS and reports them to the console and a log file.

Contrast with Compiling on the Client.

In the past to accomplish a full X++ compile, you had to click a menu in the MorphX client, such as Build > Compile. This is a three tier operation which is burdened with transferring data between the client and the AOS. In contrast, the AxBuild.exe approach is only a two tier operation. One reason the AxBuild.exe approach is faster is that it eliminates the data transfers over the network, or over local RPCs, between the AOS and the client. Compiling on the client does not provide any way to share the workload among several applications.

In contrast, AxBuild.exe starts several AOS applications which all run concurrently, which all accomplish parts of the full compile. As a matter of common practice, the AOS host computer hardware is often more powerful than client computers are. The AOS host typically has more active memory, and has more cores for parallel processing.

AxBuild.exe cannot compile any mere subset of the X++ code on the system.

The MorphX client remains the only option for compiling AX p-code to .NET CIL.

How to Run AxBuild.exe:

The following preparations are necessary before you can run AxBuild.exe:

  1. You must have completed the installation of cumulative update 7 for Microsoft Dynamics AX 2012 R2. This must include a re-initialization of the model store database that you run manually, by using either axutil.exe schema or the newer PowerShell equivalent. For more information, see Apply updates to database, AOS, and clients or How to: Create, Drop, or Reinitialize a Model Store.
  2. You must ensure that the account which will run AxBuild.exe has no less authority than has the account that runs the permanent AOS. You must ensure that the option for the hot-swapping of .NET assemblies is turned off in the AOS configuration you choose to use. See the/aos parameter on AxBuild.exe.
  3. You must establish and populate the directory that will be referred to by the /altbin parameter.



Command Line Here is an example command line for AxBuild.exe that might match the command line you need in your particular environment.

The line is artificially wrapped here for better display.

axbuild.exe xppcompileall /s=01 /altbin=”C:\Program Files (x86)\Microsoft Dynamics AX\6.0\Client\Bin”

/s=01 –> 01 is the AOS instance of the server.

/altbin= will be the location where the AXBuild.exe is located.

Temporary Files

AxBuild.exe writes temporary files to the %TEMP% directory. These files include many details about the process. By default these files are deleted byAxBuild.exe shortly before it ends. However, you can keep the files by using the /nocleanup parameter.

Parameters for AxBuild.exe

The parameter names are not case-sensitive.

In all cases where the parameter name takes an accompanying value, an = sign is used to join them together, as for example /aos=01.

AxBuild.exe always returns 0.

The following table describes the parameters that you can or must pass into AxBuild.exe.

Name Alias


xppcompileall No short alias. Required. Tells the program do a full compile on all X++ code, which creates all new p-code to be stored in the model store database.This parameter name has no accompanying value, and no leading ‘/’.This parameter is a command to tell the program the type of action to perform. So far it is the only command parameter.
/altbin /a Optional. Path to the folder on the local AOS host computer that has the DLL files which are installed with an ax32.exe client. AxBuild.exe verifies that ax32.exe is in the directory before it proceeds with the compile action. A good path to use might be the path that the client install would typically create. You must confirm the exact correct path for your particular environment: C:\Program Files(x86)\Microsoft Dynamics AX\6.0\Client\Bin\ One way to create and populate such a directory path is to install the client onto the AOS host computer, even though maybe no person would use the client on that host. Thereafter, any developers who add a third party DLL to their own client directory must ensure that the DLL is manually copied to this corresponding directory on each AOS where this program might be run. If the ax32.exe client is not installed onto the AOS host computer, this manually created directory must be initially populated manually with all the DLL files from a client installation on another computer. If you omit this parameter, AxBuild.exe examines the Microsoft Dynamics AX client configuration information in the Windows Registry in an attempt to find the correct path.
/aos /s Often optional. Instance number of an AOS that is installed on the same computer where this program runs. If you omit this parameter, AxBuild.exe examines the Microsoft Dynamics AX server configuration information in the Windows Registry. If the Registry contains information about exactly one AOS instance, that information is used as the default value for this parameter. The temporary instances of the AOS all use the same configuration specifications that this AOS instance number uses. To see a list of all available instance numbers, run the Microsoft Dynamics AX Server Configuration Utility, AxSrvCfg.exe. At the top of its window is a drop-down list that is labeled Application Object Server Instance. Perhaps the most commonly used value is 01, as in /aos=01. The parameters /dbserver and /modelstore are available in case you need to override those parts of the AOS instance configuration information.
/compiler /c Sometimes required. This /c parameter might be absent from the report that is generated by the /help parameter, but /c is fully supported. You need this parameter only when the current directory is not the directory whereax32serv.exe resides. In this case the value of the parameter must be the nameax32serv.exe preceded by its directory path. A realistic example might be the following value: /compiler=”C:\Program Files\Microsoft Dynamics AX\6.0\Server\bin\ax32serv.exe” Full compiles that are started by automation might be relatively likely to need this parameter.
/dbserver /d Optional. The name of the Microsoft SQL Server instance that manages the AX model store database. Typically this parameter is not used. Instead the program is allowed to obtain this information from the configuration it obtains from the AOS instance that is referenced by the /aos parameter.
/help /h or /? Optional. Writes brief descriptions about all parameters to the stdout handle of the console. This parameter name has no accompanying value. This parameter is implied if no parameters are supplied. If there are any discrepancies between this topic and the /help output, this topic is correct.
/log /l Optional. Specifies the directory path to which the two log files are written. The default path is the Server\…\Log\ directory under the installation location of the AOS. More exactly, the default value is stored in the Registry at the following location: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\ Dynamics Server\6.0\01\Original (installed configuration) , in logdir. The /log parameter does not specify the name of a file. It specifies a path. The /verbose parameter affects how much information is written to this log file.
/modelstore /m Optional. Name of the model store database. Typically this parameter is not used. Instead the program is allowed to use the value it obtains from the configuration as directed by the /aos parameter.
/nocleanup /n Optional. Tells the program to keep the temporary files it writes under the %TEMP% directory. This parameter name has no accompanying value. Without this parameter, the default behavior is for the program to delete the temporary files immediately before it ends its run.
/verbose /v Optional. Tells the program to write all the tracing and diagnostic information that it has to stdout, and to the AOTComp.log file. Without this parameter, less information is written. This parameter name has no accompanying value. Usually the program writes only the subset of information that a person typically might want to watch scroll by on the screen in the cmd.exe window.
/workers /w Optional. Number of parallel or concurrent AOS workers for the compilation and build processes. The program calculates a sensible integer value based on the number of available processor cores. But you might want to fine tune this value. A rough approximation might be 1.4 workers per core.

Output of AXBuild

Outputs to the Console

AxBuild.exe reports its progress to the console through the stdout handle. The stderr handle is not used. Each AOT element is reported at the moment it is compiled. Some elements can be reported repeatedly at different times before they successfully compile. These repetitions are sometimes necessary because full metadata is not always available to satisfy all dependencies until later phases of the compilation.

Output Log Files

AxBuild.exe generates two log files. You can control where the log files are written by using the /log parameter. By default the files are written to the Server\…\Log\ subdirectory under the installation directory of the AOS. Here is a common example of what the specific default path might be: C:\Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Log\

Constraints of Compiling on the AOS.

.NET Objects Cannot be Instantiated

When the X++ compiler starts, it performs special compiles on a few special classes. These classes include Application, Infolog, andClassFactory. When these special classes are compiled during a compile on the AOS tier, they fail if any custom code has been added to them that makes interop calls to the .NET Framework. We generally recommend that you not customize the methods in these special classes.

Calls to COM Objects Cannot be Chained

In X++ you can sometimes chain together a series of method calls by using the following syntax: myThing.method8().method9(); This chaining syntax is valid only if the return type from method8 has a method named method9. When you compile by using AxBuild.exe, the syntax of method chaining cannot be used with COM objects. The compiler cannot ascertain whether the COM object that is returned by method8 has a method named method9.

Leave a Reply

Skip to toolbar