mfp's two cents

...on Dynamics AX Development!

April, 2008

  • mfp's two cents

    What's up with this semicolon?


    The most visual idiosyncrasy in X++ is the dangling semicolon separating the variable declarations from the actual code. But why is it there and why is it needed?

    Best practices in X++ (as in most other modern languages) suggest using TitleCase when declaring (and referring to) types, and using camelCase when declaring variable types. Here is an example of what an X++ developer could write:

    AccountNum accountNum;
    accountNum = "4000";

    As X++ (unlike most other modern languages) is case insensitive, this is what the compiler will see:

    accountnum accountnum;
    accountnum = "4000";

    Suppose the dangling semicolon wasn't there. Then the "accountnum" statement in the second line is ambigious. It could either refer to the type or to the variable. The X++ compiler assumes it is the type, and thus generates a compilation error when encountering the equal (=) sign; as you cannot assign into a type. By inserting the dangling semicolon you instruct the compiler that there will be no more variable declarations; and thus "accoutnum" is a reference to the variable and not the type.

    If it was made a priority to get rid of dangling semicolons, what could be done?

    1. X++ could be made case sensitive. This would likely break all customizations and solutions available; unless it is accompanied with a code "beautifier".
    2. The compiler could be made more intelligent by looking one more token ahead before giving up. As human beings easily can see through the ambiguity; the compiler should be able to do so too. I guess the developer solving this issue would kudos in AX-land.

    The above is a draft of a blog post I wrote last week. I wrote it for two reasons: Mainly to explain the dangling semicolon issue, and secondarily to lay out bait for a developer on the X++ team. As it turned out more progress was made this weekend than the past eleven years in this corner of AX . After writing the draft above I decided to take a look under the covers in the compiler; to gauge the challenge, I guess. So I installed the latest version of VS and downloaded the latest source code for the kernel. (These are some of the freedoms you enjoy when working for Microsoft). After playing around with the grammar for a while, I came to the conclusion that the grammar is crisp and clear; the scanner is just feeding the wrong tokens to the parser. I found the spot where non-keyword tokens are evaluated. I discovered that if a token shares name with an X++ type (Class, Table, EDT, etc.) the parser assumes it is a type-token. After finding this spot it took me less than two hours to write some code that reads one token ahead and only assumes the current token is a type-token when it is followed by another non-keyword token. Sunday afternoon I had build 585 (the Release Candidate (RC0) of AX 2009) with a twist on my box: The dangling semicolon is no longer a requirement. I enjoyed the rest of the day in the sun with my family.

    This morning I have created a package with my findings and sent it to the X++ team for evaluation. This change will not make it into AX 2009; but I'm confident those of us writing X++ code at Microsoft will enjoy this very soon. The rest of you will have to wait for AX6.0.

  • mfp's two cents

    New Layers in Dynamics AX 2009


    4 layers have been renamed in Dynamics AX 2009 . DIS / DIP / LOS / LOP have become HFX / SL1 / SL2 / SL3 respectively. HFX is reserved for releasing hot fixes, and the 3 new solution layers (SL1/SL2/SL3) will be used to release Microsoft Dynamics Industry Solutions.

    The purpose of having 3 solution layers is to enable side-by-side install of Industry Solutions. At deployment time any SL1 layer can be renamed to SL2, SL3, BUS or BUP through a regular file rename. The AOS will recognize the layer, and honor its position in the layer stack. This will enable installing up to 3 Industry Solutions on the same system (or up to 5 Industry Solutions if the BUS and BUP layers are vacant.)

    Another aspect of side-by-side installation is conflicting names and IDs in the model. The AX platform requires unique names and IDs of all model elements, we will ensure uniqueness across Industry Solutions through our engineering processes. Naturally there will be logically overlayering conflicts for certain elements; but as the Industry Solutions by nature are verticals we anticipate very few of these. These conflicts will need to be resolved; one way is to reclaim one of the SLx layers as an adaptation layer. More information on this will be available as the Industry Solutions become available.

    Why not just support an unlimited numbers of layers?

    Frequent feedback we get is to add more layers; and open them up for consumption by the partners. And heck, why we are at it why not have an unlimited number of layers?

    Currently; there is an upper limit on the number of layers the kernel can support. This number is 16. The technical explanation has to do with referencing of the elements in the model. Each model element is stored in a record in the AOD file. The RecId for model elements is a 32 bit integer. 4 of these bits denote the layer; the remaining 28 bits are used to calculate the offset into the AOD file where the record is located. In version 3.0 (and previously) the block size was 1 byte. This basically mean the maximum size of an AOD file is about 256MB (2^28). In version 4.0 we moved this limit by denoting one of the 28 bits to control the block size. When the bit is not set, the 27 bits is the direct offset in to the file. When the bit is set, a block size of 48 bytes is used to calculate the offset in the file. This enables AOD files with sizes up to about 6.5 GB (2^27 * 48), while enabling binary backwards compatibility with 3.0 AOD files (with sizes less than 128MB (2^27)).

    If we decide to use one bit more to denote the layer (giving us 32 layers); it means we are only backwards compatible with AOD files with sizes less than 64MB (2^26). As that is not acceptable; tools to align the contents in AOD files would be needed. For 6.0 we are investigating options to tear down these limitations once and for all.

  • mfp's two cents

    Customization and Upgrading of ERP Systems - An Empirical Perspective


    Yvonne Dittrich and Sebastien Vaucouleur have just published a report on their research into Customization and Upgrading of ERP systems. More specifically they have studied Dynamics AX and Dynamics NAV; and their report reveals some interesting insights into the how problematic it can be to "build a house on the back of an elephant". 


    An increasing number of software systems are developed by customizing a standard product that provides the major part of the functionality. The customizations of Enterprise  Resource Planning systems are examples of such a practice. Nonetheless, little empirical research on the specific characteristic of this kind of software development is available. Do the recommendations for “normal” software development also apply in this case? We present an empirical study on ERP customization practices based on video recordings, interviews and a survey. The observed and reported practices challenge some of the principles of software engineering acknowledged as good practices. Based on the analysis, we discuss essential challenges and identify directions to take when addressing specific difficulties. Besides bearing the potential to influence the development of future generations of enterprise systems, the presented research provides insights in software development practices changing and amending a software product “from within” rather than developing the central functionality from scratch or re-using components “from without”.

    For more information please see:

  • mfp's two cents

    I am working on AX6.0 - what are you working on?


    The ready-set-go call has just resonated through the hallways at Microsoft, and we are now officially working on the next release of AX. What will the next release of AX look like? What features will it contain? What architectural changes will we make? What tools should we support? These are some of the many questions we will be working on during the upcoming months while we are defining the scope for the next release. I work in the Developer and Partner Tools team. This means I get to influence decisions like: "Should MorphX move into Visual Studio?", "How many layers should AX 6.0 have?", "Should X++ support eventing?", "Do we need an Entity concept in the AOT?", "How do we make our unit test cases available to partners?" - just to name a few. These are the questions that can get me out of bed in the morning - for a lot of good reasons, but primarily because I know my job makes a big difference to a lot of people.

    If you want to join me shaping the future of AX at Microsoft Development Center Copenhagen, please visit:

  • mfp's two cents

    Free eBook available: Inside Microsoft Dynamics AX 4.0


    Dive deep in to the architectural details of Microsoft Dynamics AX to make relationships clear and development tasks easier. The first part of the book is aimed at consultants and developers who are new to Microsoft Dynamics AX but have backgrounds in business application development using traditional languages, frameworks, and tools. It describes the architecture and development environment and explains key application frameworks that developers need for their customization, extension, and integration projects. The second part of the book is a reference guide for developers who work with Microsoft Dynamics AX deployments, with information on developing new functionality and supporting users. It covers more complex development concepts such as advanced forms and reports, reflection over the application metadata, performance, upgrades, migration, and setup. This is the first book written by the Microsoft product group architects and the first to take developers deep inside Microsoft Dynamics AX.

    Inside Microsoft Dynamics 4.0 is now available for download at: 

  • mfp's two cents

    What’s your take on the Rapid Configuration Tool ?


    We are planning future versions of our partner-oriented tools and understanding your use of the Sure Step Rapid Configuration Tool is important to us. Please spend 3-5 minutes to tell us what you think of the RCT. The survey can be found here. Your feedback is very much appreciated!

    Here’s the full address to the survey:

  • mfp's two cents

    The first customers go live on Dynamics AX 2009

    In the entire development cycle this is my favorite day. My mail box is getting filled up with testimonies of customers going live on Dynamics AX 2009, followed by various happy mails. Some might consider it spam; I could read them all day long.
Page 1 of 1 (7 items)