Monday, December 12, 2011

Resolving Compile Errors and Generating CIL is not Optional

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.

Wednesday, December 7, 2011

10-minute App Series Conclusion

The 10-minute app series has been concluded. If you've missed one, here are the links:

• "10 minute WPF app": a WPF app that consumes AX 2012 queries (without customization to AX).
• "10 minute Windows Azure app": send item data to an Azure site.
• "10 minute Windows Phone 7 app": get list of items on windows phone 7 app through trusted intermediary (without customization to AX)

I acknowledge to create these 10-minute apps I probably violated tons of best practices and I know I took a lot of shortcuts and skipped over things, just to make it work in 10 minutes. They are all proof-of-concepts and hopefully by taking these shortcuts you won't be inclined to just take the code and some things to create a customer solution. You should do it the right way, and take more than 10 minutes :-)

The whole point of these 10 minute apps is to enforce Microsoft's AX 2012 marketing buzz about "Powerfully Simple". The continued deep merging of AX with the rest of the Microsoft stack enables a lot of possibilities. And although a lot of the marketing is focused around AX 2012 being powerfully simple for the user, hopefully this 10-minute app series shows how the power of the integration with other Microsoft technologies makes things simpler for us developers too!

Let this be an inspiration. There are wonderful things you can do with these three examples if you start mixing and matching. Perhaps a service bus between Azure and AX, making mobile apps for mobile platforms using Azure (including Windows Phone). Or, as Sashi did, apply the base code and concepts to create an Android app.

If you created any other projects based on these apps, post it in the comments or let me know on twitter, and I will gladly reference them on my blog.

Monday, December 5, 2011

AX Mobile App for Android

The Windows Phone 7 app article has drawn quite some attention and interest. And (as I had somewhat hoped), someone has taken the series and created an Android front-end.
Technically that is all that would have to change: the front-end. If the intermediary is working, the WCF in between is up and running, all should work just fine. This author decided to make the WCF service RESTful, which took some extra effort.

Can't wait to see the final result!

Visit Shashi's blog to follow along with his article.