AX32 Tip - Opening the AxCompileAll.html log file

Tip: AxCompileAll.html can be opened with MorphX.

This file contains the results of the full AOT compile if you run unattended compilations with AXBuild or MorphX client. It houses any compiler output in a format which can be reloaded in the MorphX client at a later time.

AxCompileAll.html is overwritten each time the compilation completes. Loading it back into MorphX is simple. Click Import and look in one of the paths below:

Default location for AXBuild logs:
C:\Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Log

Default location for MorphX Client logs:
%UserProfile%\Microsoft\Dynamics Ax\Log

Likewise, you can Export the compiler output for transferring to another workstation or reviewing later, should you need to move on with your work. Now the compile errors will be displayed in the output window, and you can jump right to them:

AOTComp Log

You can search in AOTComp.log for "* Err" and you will find any compilation issues. There should be no errors, or your Full CIL will fail, and you cannot deploy this build to a production system.

Default location for AOTComp.log:
%UserProfile%\Microsoft\Dynamics Ax\Log

Full CIL Log

Note that you should also be examining the Full CIL log regularly if you perform automated builds.

Default location for XPPIL Log:
C:\Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\bin\XppIL\Dynamics.Ax.Application.dll.log

I have found that performing the Full CIL routinely as part of deployment is helpful. Checking the number of warnings will give you an early indication if your deployment environment has been provisioned with the correct run-time DLLs. There should never be errors.

For example, when third party models have been updated, they often require accompanying DLL files. If one of these DLL files is missing on the AOS, it will sometimes generate an XPPIL warning.

Also, specific features must be selected during the install of AX. While there may be unavoidable XPPIL warnings depending on your choice of third party vendors, the same warnings should be applicable to all environments for which the Modelstore applies, or there is certainly a noteworthy difference between the environments.

AX2012 TFS Tip - Setting default startup model

If you use version control then it can be helpful to set the default startup model for development workstations. At first glance, this can be easily accomplished through the AX Configuration options.

Startup Model Gotcha

If the development environment is refreshed from production, the configuration options are overwritten. Therefore the default startup model may be set incorrectly.

AX32.exe -model argument

To ensure your developers have the correct startup model after an environment refresh, simply add the following to the MorphX shortcut: 

"-model=(YourModel, YourVendor)"

Important: Include the quotation marks.

 

Setting the Startup Layer

The default layer can be set in the AX Configuration Utility, and will survive an environment refresh. Alternatively, supply the following argument (CUS layer shown as example): 

Ax32.exe -aol=CUS -aolcode=YOURKEY

The development code can be omitted from the parameter set if specified in the client configuration utility.

A more complete list of client configuration commands is available here:
https://technet.microsoft.com/en-us/library/aa569653.aspx

AXBuild included with AX2012 R2 CU7 - but does it work for base R2?

AXBuild.exe for Dynamics is a high performance build engine released with AX2012 R2 CU7 Kernel. There are a few ways it speeds up the build, namely through parallelism and by cutting out the overhead of MorphX. This compile tool can make full use of all available CPU cores and it benefits from enterprise class storage systems.

By contrast, builds performed in the MorphX client would benefit most from systems optimized for single threaded operations, ie. no virtualization, solid state disks and high clock speed.

It is theoretically possible to use AXBuild.exe without first upgrading to CU7. I tried it. Even though it works, I can find no documentation stating that it is acceptable to use AXBuild on installations prior to CU7. Therefore, if you do not have CU7, your results may be unsupported if you use the following method.

There are a couple of mentions where AXBuild was used successfully without taking on CU7, after updating the Kernel only:

• http://yetanotherdynamicsaxblog.blogspot.com/2013/11/you-got-to-love-axbuild-compiler-tool.html?_sm_au_=iVVkT9PvjDrv59W5
• http://daxmusings.codecrib.com/2013/11/what-you-need-to-know-about-15-minute.html

AXBuild Gotchas:

• AXBuild takes the place of the AOS service. Therefore, the AOS service should be turned off for the duration of the compile, and MorphX should be closed.
• Using the altbin parameter will correctly locate the client\bin binaries and avoid runtime errors.
• If your server\bin folder has not been well maintained, you may uncover third party components which are out of date, previously unmentioned by MorphX. These should be corrected anyway.
• Hot-swapping must be turned off in the AOS configuration.
• The compile log files are not stored in the user profile by default. Instead, they are are stored in: C:\Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Log\
• AXBuild should be executed with administrative credentials.
• .NET Objects Cannot be Instantiated while the compile is running. This matters if you have customized a few key foundation classes to perform .NET calls, namely Application, Infolog, and ClassFactory. See section F: https://msdn.microsoft.com/en-us/library/dn528954.aspx
• AXBuild does not support chained COM calls. See below.
• The documentation for AXBuild alludes to differences in the Modelstore schema. In my experience, the compile completed successfully on AX2012 R2 without updating the schema, so I am not sure that this applies. For CU7 where the tool was introduced, it certainly applies. In that case, care must be taken to also update the schema on deployment environments, or the new Modelstore will fail to import.
• Full CIL generation remains as a separate step which is not covered by AXBuild.

 

Fix for AX2012 R2 base install - errors in foundation class SysInetHTMLEditor

For the AX2012 R2 base install, I encountered two errors:
Description    Path    Line    Method/Property name    Diagnostic ID   
1. The variable is not of the type CLASS.    \Forms\SysInetHTMLEditor\Methods\saveChanges    21    \Forms    Err:74   
2. The variable is not of the type CLASS.    \Forms\SysInetHTMLEditor\Methods\saveDocument    25    \Forms    Err:74   

For an explanation, see Section F, constraints:
https://msdn.microsoft.com/en-us/library/dn528954.aspx

Here are the errors after loading AxCompileAll.html into MorphX:

 

This was easily solvable by first declaring a variable of type COM to avoid the chaining call: