Monthly Archives: May 2015

AIF–duplicate types with name Dynamics.Ax.Application…

In a recent task I had to redeploy an AIF http document service several times due to changes. Ocassionally the below error would occur when opening the inbound ports form. The error indicated that the classes related to my document service somehow would conflict because they were already registered. In the current state it would not be possible to activate a new inbound port.


Fortunateley a colleague of mine had experienced something similar and here is our guide that in the end solved my issue:

  • Create a job that deletes everything  from the SysXppAssembly

static void Job1(Args _args)
SysXppAssembly sysxppassembly;
delete_from SysXppAssembly;

  • Stop the AOS.
  • Delete all files (and folders) from the “C:\Program Files\Microsoft Dynamics AX\60\Server\[instancename]\bin\XppIL” folder
  • Start the AOS and go to Systemadministration/setup/services and application integration framework/inbound ports to check if the error has gone.

In most cases that would solve the problem. In one situation I experienced that the above gude was not enough. I also had to do the following:

  • compile the entire application
  • Perform full CIL
  • Restart the AOS

Hope this helps…

Thanks to Henning Ejner Andersen for assisting me on this issue.

AIf – Some or all identity references could not be translated.

In a recent task i struggled with that error when calling an AIF http service. It would work from visual studios internal casini browser but when the client was deployed to IIS the error “ Some or all identity references could not be translated.” would display in the AIF exception log.

It was not possible to set up proper debugging in a timely manner so a little fix was created in order to being able to see why the error was being thrown.

Analyzing the labelid’s it turned out that the error with that labelid would only be thrown from one single location data dictionary/tables/AifPortUser. From there a call to to AifUtil::getWindowsUserSid(windowsUser) would occur causing the exception to be thrown. So the interesting thing would be to analyze what windows user actually was submitted by the client. In order to do that the AifUtil::getWindowsUserSid was modified in order to write the domain, alias and usersid to a text file:

        TextIo textIo;
        FileIOPermission fileio;   





        fileio = new FileIOPermission(@"C:\test\", #io_append);
        textIo = new TextIo(@"C:\test\textIOtest.txt", #IO_WRITE);
        textIo.write("domain: " + domain + "\n");
        textIo.write("alias: " + alias + "\n");
        textIo.write("userSid: " + userSid + "\n");

That little snipped showed that the identity of the default apppool was submitted and not the actual windows user. Changing the apppool identity fixed the problem.