- Importing XPOs
- Compiling the code
- Compiling the IL
- Synchronizing the database
- Importing label files
When you are doing these tasks interactively, you can immediately see if something is wrong. However, if you execute these tasks automated (with AXBuild.exe and through the -autorun switch), you will want to verify whether any of these steps failed miserably.
Surprisingly enough, most of the time AX does log the results, but it's incredibly inconsistent in doing so. Let's see where the separate logs can be found!
XPO import log
I import XPO files with the following commandAx32.exe -aotimportfile=<PATH> -nocompileonImport -Model=<MODEL> -lazyclassloading -lazytableloading -Minimize
The is no way whatsoever to import an .xpo file that has a space in the path, so take care where you place your input files.
The result ends up under the user profile directory (typically c:\Users\<Username>) in the Microsoft\Dynamics Ax\Log subdirectory, in <ImportedXpoFileName>Import.log.
XPO compile log
With the shiny new compilation tool, it became much easier to execute a full compile that would finish before the expected heatdeath of the universe.Axbuild.exe xppcompileall /s=01 /altbin="<AXClientExePath>" /c="<AXServerExePath>" /l="<LogFolder>"
The AxBuild.exe can be found in the server bin directory. If you change the working directory to that location, then the /altbin and /c parameters become unnecessary. If you run AxBuild.exe from elsewhere, it will need a couple of hints on where to find the Ax32.exe and the Ax32serv.exe
You can see this is a newer tool, because it recognizes quotation marks, so you can have spaces in your paths.
The log it emits is a html file, and will be placed in whatever directory you specify in the /l switch. By default it logs in the C:\Program Files\Microsoft Dynamics AX\60\Server\<AOSNAME>\Log\ folder.
Parsing this html file with powershell will be the topic of another article.
CIL Compile log
Even if the XPO compiles, different errors can come to light during the CIL compilation. The following command executes a full CIL compilation. If you want to execute an incremental CIL compilation you would have to either modify the SysStartupCmd class in the AX, or use an Autorun.xml to import a class that calls SysCompileIL::generateIncrementalIL(true, true, true); method. Here, I demonstrate the full CIL method.Ax32.exe -startupcmd=CompileIl -nocompileonImport -lazyclassloading -lazytableloading -Minimize
Prepare to meet the third different logging method, this time into a Dynamics.Ax.Application.dll.log text file placed under the bin/XppIL directory of the server, so the full path will be something like this C:\Program Files\Microsoft Dynamics AX\60\Server\<AOSNAME>\bin\XppIL\Dynamics.Ax.Application.dll.log
If this file ends with the following, then all is fine and dandy (otherwise the exact error messages can be found earlier in this file)
Errors: 0
Warnings: 0
Synchronize log
If the xpp code compiles without errors, then the synchronize should succeed pretty much by default, right? Wrong.In some arcane cases, synchronizing tables can and will fail, even if no one messed around with the SQL server in the background, so it's necessary to check whether AX will be able to synch your model on the target environment or not.
Once again, this is done by using AX32.exe with another StartupCmd parameter.
Ax32.exe -startupcmd=synchronize -nocompileonImport -lazyclassloading -lazytableloading -Minimize
And once again, the errors are logged into someplace new. This time the result can be found in SQL, and the following query returns all errors that ever occurred during synchronization:
SELECT DESCRIPTION FROM dbo.SYSEXCEPTIONTABLE WHERE module='SysStartupCmdSynchronize' AND exception>1
You could filter the table more for recent messages, or if it's a build environment where the database is reset anyway, just issue a DELETE FROM dbo.SYSEXCEPTIONTABLE WHERE module='SysStartupCmdSynchronize' command before running the synchronize.
Label file import - no log found
The only reliable way I found for importing label files, and forcing the AOS to actually write the labels into the .ald files in the bin directory, is to delete the current ald, ali, alc files, import the new ald, then restart the AOS after the import. The Label::flush command should do the trick, except it only works for languages that are not the language of the client executing the command. So if you use a technical user that has a language other than your normal languages, it could work, but I just stuck with restarting the AOS afterwards. This is the command used:Ax32.exe -startupcmd=AldImport_<PATH> -nocompileonImport -lazyclassloading -lazytableloading -Minimize
Once again, there can be no spaces in the path.
As far as I have been able to tell, there is no indication whatsoever if anything went wrong with the process, but if anyone has any info, I would be really interested.
