Client-Side vs. AXBuild.exe

(0) Share

Report

Posted on by BP-22040756-0

Hi,

In a production environment where there is no room for mistakes and the system has to be fully operational, is it safe to use the AXBuild.exe command to compile the system after a code promotion instead of doing the client-side compile (AOT > Right Click > Compile)?

AxBuild takes 20 minutes and it's nice and all but why isn't Microsoft using this method by default and instead they decided to keep the client-side compile in place, even in AX 2012 R3?

Finally, Microsoft recommends doing a nightly AxBuild as a batch job in Production? Why would this be necessary? You would only need to compile if a change is introduced, right?

By the way, I understand that the proper way is to export the model store and import it into production instead of using XPOs and compiling but let's assume I have to import XPOs and I have to do compile.

Thanks for any feedback.

*This post is locked for comments

I have the same question (0)

All responses (8)

Answers (3)

Verified answer

Jonathan Halland 11,310 on at

Like (0)

Report

Hi Bobby.

I'm not sure if I can answer your question in totality but I'll add my comments from what I know.

Firstly I don't believe there is any fundemental difference in the actual compile output between AXBuild and compiling via the client. The major difference is in the compile process. The AX client / compiler is still a 32bit client and cannot effectively use multi threading parallel processing capabilities, whereas the AXBuild tool can, thus fully utilizing the resources (memory and CPU) available on the computer. This is why you get such great performance enhancements.

The AXBuild tool is also only practically useful for a full system compile, whereas you certainly still need the client compiler for development or partial compiles

As to why MS recommends AXBuild as a nightly batch, I haven't heard of this, but would certainly be interested in reading any documentation that you may have seen with this recommendation, as I also do not see the point in it.

I hope this helps a little bit and that somebody with a bit more knowledge comes along to comment too

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

Like (0)

Report

I really don't think you should do it. Compilation in production would slow down the system for all users, CIL compilation could prevent some parts from working etc.

What exactly is the benefit in comparison with building the application in a pre-production environment and moving the whole modelstore?

Could you show me where Microsoft recommend compilation in production? It doesn't make sense to me, if it isn't about some special scenario.

Was this reply helpful? Yes No
Guy Terry 28,924 Moderator on at

Like (0)

Report

Hi Bobby,

This statement

[quote]

In a production environment where there is no room for mistakes and the system has to be fully operational

[/quote]

and this statement

[quote]

I understand that the proper way is to export the model store and import it into production instead of using XPOs and compiling but let's assume I have to import XPOs and I have to do compile.

[/quote]

aren't really compatible. But you know this!

I believe we have seen differences between the axbuild compile and a compile via AX client. The axbuild compile complains about dlls which are stored in the Client\Bin folder. If you compile via the Client, these objects compile fine.

Was this reply helpful? Yes No
Srinath Sundaresan 510 on at

Like (0)

Report

The full compile should never be run in a production environment. The compile should be run in a staging or pre-production environment.

See the whitepaper for deploying code across environments.

www.microsoft.com/.../details.aspx

Mark this question as answered if it helps.

Was this reply helpful? Yes No
Verified answer

Brandon Wiese 17,788 on at

Like (0)

Report

You have some good questions.

While everyone would like to believe that axbuild and the client-side compile are identical in output, they are not. There are well documented cases where axbuild fails entirely or produces compile errors that the client-side does not. You can find some in this forum. If axbuild works, produces no errors, and the resulting system runs, use it. I've been using it in production, which I compile pretty much every week with axbuild, for 6 months with no problems that can be attributed to axbuild. By the way, the client-side compile can be mucked up by AUC files, so you should always clear those before starting a client-side compile.

I believe a nightly build in production is a waste of time. Compile after you make changes. Some changes can be safely made in production without a full compile and CIL, i.e. simple changes to forms and SSRS reports. Any change to an object which is consumed by other objects, such as classes and most especially tables (schema) should require a full compile after changes.

I have never and will never do an export/import of a model store from a development or test environment into a production environment. I move all changes by XPO, followed by a full compile and CIL. I want to be 100% sure I understand every change being made to production, and want to be 100% sure that no junk code makes its way there by accident, that I pay extremely close attention. Developers (of which I am one) are notorious for leaving bits of junk all over the place from things they tried that did not work. On top of that, if you have multiple development environments, it will be virtually impossible to keep element ID's straight between them, or to keep them sufficiently in sync that moving whole model stores around won't eventually regress out a change you wanted to keep. Moving code to production by XPO guarantees that no element ID issues will ever occur. Refresh your development and testing environments from production periodically, which you want to do anyway to keep the data somewhat fresh, and it's very easy to manage with almost no risk.

Developers do outright dumb things to development and test environments all the time, as well they should. Nothing touches my production environment without inspection and approval by my own eyes. If you care as much about your production as I do, you will be as outright uncomfortable with model stores as I am.

Was this reply helpful? Yes No
Verified answer

Martin Dráb 237,884 Most Valuable Professional on at

Like (1)

Report
I must disagree. XPO files definitely don't guarantee that the right code is installed. It's an equivalent of writing code manually, not of installing an exact version of application. It depends on many assumptions which often aren't met, because it involve many manual and error-prone steps:

The right objects in right versions are exported and nothing is missed.

Objects are imported correctly, e.g. in right order.

Changes are merged correctly with existing code.

In contrast, importing a modelstore guarantees that the version installed is exactly the same as what was tested and signed off.

Nevertheless notice that I never said anything about taking modestore from a Dev or Test environment. On the contrary, taking code from Dev would be a huge mistake (which is true for XPO files as well). I don't care if developers have junk on their dev boxes, because code is not taken from there. It 's taken from version control. The version of model(s) approved for delivery is then installed to a pre-production environment and when built, you can take the modelstore. IDs in Dev and Test boxes are irrelevant, only the pre-production environment needs to be in sync with the production one.

As you see, you can easily set up a process that doesn't have any of problems you described; you just started with wrong assumptions. And the process doesn't exhibit problems that I explained above.

Your eyes may be good for checking code, but manipulation of code it a part of the development process. Deployment, on the other hand, is about moving the exact version of application to the last bit and there is no room for playing with source code.

It seems that you're checking code during deployment because you're getting wrong code for deployment, i.e. the underlying cause it in earlier phases of your process.

Was this reply helpful? Yes No
Srinath Sundaresan 510 on at

Like (0)

Report

We can do compile,CIL and even debug in Prod. We should ask ourselves what is the right way to do it. Why we have separate environments for test,dev,production,staging etc. What is the deployment strategy.

The point being whether we should use proven practices or not.

Was this reply helpful? Yes No
BP-22040756-0 on at

Like (0)

Report

Thank you ALL for your feedback. Really appreciate it.

The process that I currently have in place is that code gets migrated in to a Staging environment before it gets fully compiled. Then from Staging I simply export the model store and import it into Production. I agree with you 100% that code should never be imported into Prod as XPOs. I have the process down for now.

What I've gathered from your responses is that it IS in fact safe to use AXBuild.exe when I compile my Staging environment and the reason the client still uses the "client-side" compile is because it's 32bit and it cannot utilize the multi-threading feature. It makes sense.

By the way, we were told about the nightly batch compile in Production at convergence so I don't have any references but I agree that it's unnecessary.

This was really helpful. Thank you again everyone.

Was this reply helpful? Yes No