We have encountered a CIL compilation issue for a custom class which referenced a custom VS project in the AOT.
The errors gave no indication as to the cause and looked as follows:
Cannot create a record in Compiler information (TmpCompilerOutput). Path: \Classes\<class>\<method>, Warning: No proxy found. Type FileIOPermission found on the stack. This code in Class: <class>, Method: <method>.
The record already exists.
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
The interesting thing is, that the class in question compiled fine. However, when we looked at it in the AOT, right after the CIL generation failed, and hovered over the method’s signature line, we saw a context error message stating: CIL generation: Error: .NET Cast Type Name not found. Type System.String found on the stack. This code in Class/Table: <Class>, Method: <method> may not work in CIL run time.
In order to resolve we copied the Microsoft.Dynamics.AX.Xpp.Support.dll assembly from the Server/Bin to Client/Bin, which produced a clean CIL compilation.
Received the following error when deploying a model store to a destination environment:
“…Binary stream ‘178’ does not contain a valid BinaryHeader….”
As part of the deployment, we exported the modelstore from the source environment, then copied the exported *.axmodelstore file over to the destination server, and imported the modelstore to the target environment. Turned out that the file was getting corrupted during the copy operation between the servers. The solution was to export and import the modelstore to/from the same network location.
We have encountered the following error while generating a full CIL as part of a CU1 upgrade of AX2012 R2:
Could not load file or assembly ‘Dynamics.Ax.Application, Version=220.127.116.11, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified. —> System.IO.FileNotFoundException: Could not load file or assembly ‘Dynamics.Ax.Application, Version=18.104.22.168, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified.
Turned out, the AOS account permissions were modified, and the account no longer had full access to the CIL assembly folder – “..\Server\BIN\XPPL”. The solution is to restore the full control rights to the folder for the AOS account.