Dynamics.Ax.Application.dll differs on AOS which runs full CIL to AOS which didnt

(0) Share

Report

Posted on by Community Member

Hi there,

from my understanding the Dynamics.Ax.Application.dll should be the same on all AOS instances in one Environment, but what we experience is on the machine which had run the full CIL has another Dynamics.Ax.Application.dll than the AOS instances which did not run the full CIL

The AOS instances which did not run the full CIL has all the same Dynamics.Ax.Application.dll

The differences are not huge but file hashing shows it

Is this a Problem?

A well known behaviour? (didnt found something)

*This post is locked for comments

I have the same question (0)

All responses (8)

Answers (0)

nmaenpaa 101,160 Moderator on at

Like (0)

Report

The AOS will take the CIL (dll) from the model database when it starts. If you do new CIL generation on another AOS after that, the new DLL is saved in the model database but it's not updated automatically to other AOSes.

If you do generate CIL in your multi-AOS-environment, shut down all except one AOS before doing that. In general if you do any deployment activity (import code, compile code...) in multi-AOS-environment, shut down all except one AOS.

If you do modelstore delivery you don't need to generate CIL in the target environment at all, it's included in the modelstore.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

sorry i wasnt clear at this Point

what we have done

- shutdown all AOS instances

- started one AOS instance where we did the full CIL

- after CIL was complete, we started the other AOS instances, they updated the dll but the dll has another hash than the dll on the aos instance which had run the full cil

Was this reply helpful? Yes No
nmaenpaa 101,160 Moderator on at

Like (0)

Report

What if you restart also the AOS where you generated the CIL? Is there still a difference? Then all AOS servers should have fetched the dll from the model store.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Yes after restart aos there is still a difference.

More, the hash changes about each 2-4 restarts of the AOS Service

This is true for the AOS which had run the CIL and for the other AOS which didnt run the CIL

-> And it is still, AOS which didnt run the CIL have same hash (after all instances restarted), AOS which had run the CIL differs

Was this reply helpful? Yes No
Sohaib Cheema 49,438 User Group Leader on at

Like (0)

Report

This is a problem and many people on earth don't realize this. It seems an issue with few kernel versions of AX.

As per documentation, restart of other AOS servers should pick the Updated CIL, after the Model store was applied on Primary AOS. But it misses CIL update on other AOS servers.

Hence result becomes.. something working on AOS1 works differently on AOS2

I have seen this problem at few users.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

But looking at the timestamp, they are updated.

Even when i delete the files in XPPIL Folder, the behaviour still the same. Where should they get other informations than the "primary aos"?

-> we tried just to empty the XPPIL Folder on all AOS instances...

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

OK some new informations, the hash changes not all 2-4 restarts, it changes after the AOS was restarted which had done the CIL.

So the behaviour is as follows (with 3 AOS instances)

- Stop all AOS Instances

- Start Primary AOS (AOS01)

- Doing CIL on AOS01

- Start AOS02 and AOS03

- At this Point, AOS01 dll hash differs from AOS02 and 03

- restart AOS02/03 doesnt Change this

- Now starting AOS01 new, for a short time the hash is identical to AOS02 and 03...but after a few seconds/minutes file changes again and it has a new hash on the AOS01

- Restart AOS02 or AOS03 results in a new different hash to AOS01. restarting the other "secondary" aos results in the same hash as the first restarted secondary AOS

So for us, Primary AOS01 and secondaries have in production never the same hashes? We are on 2012 R2 CU13, can anyone confirm.

So i dont think we are a "unicorn" here but how do you guys Monitor this? For my understanding this is a very important part for AOS to run properly...but no one cares or what?

Was this reply helpful? Yes No
nmaenpaa 101,160 Moderator on at

Like (0)

Report

My suggestions:

- Apply most recent kernel version in your system

- Already before that you can try modelstore delivery into your system and see if the issue still persists or not. However please be aware that you can only do a modelstore delivery from a system that has the same element id values. So you must first prepare such system by copying your prod system databases into your staging system. Modelstore delivery is the recommended method for production deliveries in AX2012.

Was this reply helpful? Yes No