Dec 13, 2011
Filed under: #daxmusings #bizapps

All too often I visit clients or move in a code release to a production environment, only to find there are compile errors in the environment. This is totally unacceptable, and not just in a production environment. The existence of a compile error in a production environment is bad in itself, but it clearly shows there is an underlying problem going on in the development process.

Why is there a compile error in production, how did it get there? There are only 2 possibilities: 1) someone was WRITING/CHANGING code in production 2) there is a problem in the procedure of moving code into production

If someone was writing code in production, they should get a warning and a note in their employee file. Writing code in a production environment is one of the worst offenses a developer can make. I’ve known plenty of projects where developers did not have access to production at all. I absolutely love that idea because it forces proper procedures all around. I’ve seen consultants and developers complain about not having access to production to troubleshoot issues. If issues are severe enough they need a developer’s eye and possibly debugging, it’s time to take a backup of production and restore in an environment where investigation can be done (you should never have debugging on AOS enabled in production!). Contrary to some people’s beliefs, making an environment copy is an easy (and relatively quick) thing to do, and it is the right thing to do. Debugging in production or manipulating data in production using the table browser or SQL without having tested this (and its impact) in a copy of production first is just as bad of an offense…

The second possible scenario is a problem with code release procedures. I’ve talked about this topic before in the AX 2012 code deployment article, and this is a good illustration. Deployments to production should be done in a binary, compiled form. That implies that 1) the code was compiled and checked somewhere else and moved into prod in a compiled form, so no compile errors should exist in prod after the move 2) the code that was moved into prod is the exact same as where it came from and was tested

Compile errors in prod can result from missing objects in XPOs or having to do an XPO merge while importing and making a mistake. All the more reasons to not move XPOs. To quote my deployment article: “Moving XPOs is barbaric” (it’s becoming my slogan).

In either case, after moving in XPOs you should do a full compile anyway. At Streamline Systems we move layers or models, not XPOs. But even then we do a full compile after the binary code is moved in. It is an extra check that your code is ok, but more importantly it verifies that your layer works with the existing layers in the environment. What if a code change you made works by itself, but there is a customization in another layer that is now broken because of your change? You will not know until you do a full compile. And hopefully you already noticed that in a user acceptance testing environment (that has the same other layers as production) before you moved it into production. I guess layers being out-of-sync between production and a user acceptance testing environment could be considered a third reason for a production environment to have compile errors, but it comes down to a code release procedure issue as well.

Compiling brings me to my next topic. The way the X++ language works as a scripting language has gotten us spoiled over the years. The fact that X++ is a scripting language is exactly the reason why we are even talking about these issues. You can modify one object, compile it, and you’re good to go. If you just broke another object by doing this code change, you won’t know until run-time, or until you do a full compile of everything and find out. Think about traditional compiled development. For your code change to be incorporated, you have to recompile your whole library. If you make one code error or break something in another code file, your whole library will fail to compile and you can’t run anything anymore at all until that is fixed. Besides this being good practice, it totally makes sense. So now in AX 2012, we have the CIL generation. This generates .NET assemblies for all the X++ code. And guess what? If you have 1 compile error anywhere, the CIL generation will fail to complete. However, the .NET assemblies are used in batch jobs, services, and potentially other code being run explicitly in the CLR. (Check my previous article on X++ and CLR for details.) As soon as the CIL generator encounters ANY compile error, it will stop going any further (just like a regular compile in C# for example). So you may have two pieces of code that are totally independent of each other. But one of the two has a compile error and CIL generation will abort for BOTH.

So here are two major conclusions I leave you with: 1) If you have ANY X++ compile errors in your system, you may end up with NO CIL code at all, even if the compile error is in a different area of code 2) Without a full CIL generation you have a CRIPPLED AX environment. Your CIL code will either be the previously compiled binaries (without your latest code change), or it won’t be there at all. Batch jobs and services may not work at all, or have unexpected behavior based on the last good compile that happened.

So, resolving compile errors and having a completed full CIL generation in AX 2012 is NOT OPTIONAL. If you have compile errors in any of your environments, you should go back to your desk and start resolving them until they’re fixed, right now. Failing to do so will break AX 2012, for real.

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!