Finance | Project Operations, Human Resources, ...

depoly object from DEV to UAT in AX 2012 R3

(2) Share

Report

Posted on by CU10121822-0

552

Hi team,

Suppose in the table method insert , developer added code in CUS, VAR and USR layer in AX2012 R3

Is end user can see all the code in UAT after deployment from DEV?

For example:

public void insert()
{
info("VAR code");
super();
}

public void insert()
{
info("USR code");
super();
}

public void insert()
{
info("CUS code");
super();
}

as USR layer is highest layer. So, user can see only USR layer code?

How will I get other layers code along with USR?

before deployment in UAT, what necessary action needs to taken.

Kindly elaborate please.

thnaks!

Categories:

Microsoft Dynamics AX

I have the same question (0)

All responses (9)

Answers (0)

Sort by

Suggested answer

Subra 1,732 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @CU10121822-0

I hope they can see the code but they will not see the code. since they will be not opening the AOT and development workspace.

Before the deployment, please take a backup of existing and move changes using Axpp or entire code from dev to UAT.

Thanks,
Subra

If this helped, please mark it as "Verified" for others facing the same issue

Was this reply helpful? Yes No
CU10121822-0 552 on at

Like
a
(0)

Report
Copy link

Link copied!

Thanks Subra, I not yet satisfied...

Here, I mean to say the infolog. What end user will get?

You mean to say import .axmodel file?

If yes, before importing, is I need layer comparision and manual merging. As the methods contained three layers CUS, VAR,USR.

Kindly elaborate based on my above example. thanks!

Was this reply helpful? Yes No
Suggested answer

Subra 1,732 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @CU10121822-0

When you are looking for infolog for the user?

Yes, importing .axmodel file will overdide all the existing .axmodel in the target environment and before doing this we need to take a backup for the safer side.

With this approach will not have any comparsion between models.

Thanks,
Subra

If this helped, please mark it as "Verified" for others facing the same issue

Was this reply helpful? Yes No
Suggested answer

Martin Dráb 240,055 Most Valuable Professional on at

Like
a
(0)

Report
Copy link

Link copied!

If you deploy all layers, you'll see only code from USR layer.

Your problem isn't in deployment, but already in development. You need to update the CUS layer to include code from VAR layer and the USR layer to include code from the updated CUS layer.

And you should review your overall processes. There should normally be just one active development layer for an environment. For example, you have an environment for VAR changes (with no CUS layer) and then a customer-specific environment where you utilize your VAR product and actively develop in CUS. When you install a new version of VAR to the CUS environment, you'll perform the code upgrade process. Most of code will be handled for you and you'll need manually resolve conflicts, if any.

Or maybe you don't need multiple layers at all and the decision to do so was taken by someone who didn't understand the implications.

Was this reply helpful? Yes No
Assisted by AI

Saif Ali Sabri 2,803 Moderator on at

Like
a
(0)

Report
Copy link

Link copied!
🔑 Key Points About Layers

USR layer is the highest layer. If you have code in the same method across multiple layers, only the USR layer implementation will execute.

VAR layer and CUS layer code will be overridden if the same method is redefined in USR.

The infolog output (your info("...") messages) will therefore only show what is in the USR layer, not VAR or CUS, unless you manually merge them.

🛠 What Happens in Your Example
You wrote three versions of insert():
x++
public void insert()
{
info("VAR code");
super();
}

public void insert()
{
info("USR code");
super();
}

public void insert()
{
info("CUS code");
super();
}

After deployment, only info("USR code") will appear in UAT because USR overrides CUS and VAR.

The end user will not see VAR or CUS messages unless you merge them into the USR layer.

📦 Deployment Best Practice
Before deploying to UAT:

Layer comparison – Compare methods across layers to identify conflicts.

Manual merging – Update the USR layer to include logic from CUS and VAR if needed:

x++
public void insert()
{
info("VAR code");
info("CUS code");
info("USR code");
super();
}

This way, all messages appear in sequence.

Model file import – Yes, you’ll import the .axmodel file into UAT. But importing alone won’t merge code; you must resolve conflicts beforehand.

Process review – Normally, you should have one active development layer per environment. Multiple active layers (VAR, CUS, USR) in the same environment cause confusion and override issues.

✅ Solution Summary

End users in UAT will only see USR layer code unless you merge other layers into it.

Deployment itself doesn’t merge layers — you must do that in development before exporting the model.

Best practice: consolidate logic into a single layer (usually CUS for customer-specific changes) and avoid parallel development across multiple layers.

Was this reply helpful? Yes No
Assisted by AI

Saif Ali Sabri 2,803 Moderator on at

Like
a
(0)

Report
Copy link

Link copied!
Here’s a step‑by‑step merging workflow for your AX 2012 R3 scenario, tailored to your example with insert() methods spread across VAR, CUS, and USR layers:
🧩 Step 1 – Identify Layer Conflicts

Use the Compare layers tool in AX to check differences between VAR, CUS, and USR.

Focus on methods that exist in multiple layers (like insert()).

Document what each layer contributes (e.g., info("VAR code"), info("CUS code"), info("USR code")).

🛠 Step 2 – Decide Target Layer

Choose the highest active development layer for your environment.

Typically CUS for customer‑specific changes.

Avoid spreading logic across multiple layers unless absolutely necessary.

In your case, merge all logic into USR (since it overrides others) or into CUS if that’s your designated dev layer.

🔄 Step 3 – Manual Merge

Open the method in the chosen layer.

Consolidate logic from all layers into one method:

x++

public void insert()
{
info("VAR code");
info("CUS code");
info("USR code");
super();
}

This ensures the infolog shows all messages in sequence.

📦 Step 4 – Build & Export Model

Once merged, synchronize and compile the model in DEV.

Export the consolidated layer as an .axmodel file.

🚀 Step 5 – Deploy to UAT

Import the .axmodel into UAT using AX’s model management tools.

Run full compile + CIL generation in UAT to ensure consistency.

Test the method execution in UAT — the infolog should now display all merged messages.

📋 Step 6 – Process Review

Re‑evaluate your layer strategy:

Ideally, only one active dev layer per environment.

Use VAR for ISV product code, CUS for customer customization, and avoid USR unless strictly necessary.

If multiple layers are unavoidable, always merge before deployment.

✅ Summary: End users in UAT will only see USR layer code unless you manually merge logic from VAR and CUS into the USR (or CUS) layer before exporting the model. Deployment itself doesn’t merge layers — it just applies the highest layer. The necessary action is layer comparison + manual merge in DEV, then export/import into UAT.

Was this reply helpful? Yes No
Martin Dráb 240,055 Most Valuable Professional on at

Like
a
(2)

Report
Copy link

Link copied!

I see no value in those AI-generated answers above. They repeat what I said and add a few things that are wrong.

The last one incorrectly claims that you should do a layer comparison to merge the code, which is a bad idea. The correct process, the code upgrade, is much more efficient. For example, code comparison would show you all differences, but most differences are to be ignored, because they just mean that you've added logic in a higher layer. What you need to find are places that changed in the lower layer and are overridden in a higher layer (therefore the new changes are hidden by old code in the higher layer). The code upgrade process does make this three-way comparison.

Another wrong idea is that you should do the merge before deploying. That's way too late. It would mean that your DEV environments contain wrong code and you can't meaningfully be used for development and testing.

Was this reply helpful? Yes No
Assisted by AI

Saif Ali Sabri 2,803 Moderator on at

Like
a
(0)

Report
Copy link

Link copied!
Martin is correct — he raises an important point about the code upgrade process, which goes beyond a simplistic layer comparison.
Thanks for the clarifications above. Let me try to summarize and refine the solution based on the example with insert() methods spread across VAR, CUS, and USR layers in AX 2012 R3.
🔑 Layer Behavior

AX always executes the highest layer implementation.

If the same method exists in VAR, CUS, and USR, only the USR layer code runs.

Therefore, in your example, the infolog will show only info("USR code") unless you consolidate logic.

⚠️ Where the Real Issue Lies

The problem is not deployment, but development strategy.

Having active code in multiple layers leads to overrides and hidden changes.

As Martin rightly pointed out, a simple layer comparison is misleading — it shows all differences, even those that are expected.

✅ Correct Approach – Code Upgrade Process

Run Code Upgrade Tool

Use AX’s Code upgrade → Compare layers (three‑way comparison).

This identifies where lower‑layer changes are hidden by higher‑layer overrides.

Resolve Conflicts

Accept system‑generated merges where safe.

Manually merge logic where business functionality from lower layers must be preserved.

Example consolidated method:

x++

public void insert()
{
info("VAR code");
info("CUS code");
info("USR code");
super();
}

Validate in DEV

Compile and run Incremental CIL.

Test thoroughly in DEV so UAT receives clean, merged code.

This avoids the “wrong code in DEV” problem.

Deploy to UAT

Export the merged .axmodel from DEV.

Import into UAT, compile, and generate CIL.

End users will now see all infolog messages as intended.

📋 Best Practice

Maintain one active development layer per environment.

Use VAR for ISV product code, CUS for customer customization, and avoid USR for long‑term development.

Always merge in DEV before deployment — deployment itself does not merge layers.

Was this reply helpful? Yes No
Martin Dráb 240,055 Most Valuable Professional on at

Like
a
(1)

Report
Copy link

Link copied!

Saif, do you find necessary to always let AI generate a large amount of text instead of writing an actual answer on your own? People either have to read lots of irrelevant information, or ignore your answers completely as obvious AI gibberish that can't be trusted anyway. In my opinion, it makes this forum less useful.

Not mentioning that AI often make false statements that just confuse people that make a mistake by taking them seriously.

Was this reply helpful? Yes No