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:

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

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.

We've had feedback from many sources (comments in this blog, emails, in-person meetings, partner advisory board, etc.) that we should fix the element ID problem in AX - the sooner the better. Thank you very much for this feedback. This post is intended to give a bit of background on this subject.

The element ID problem in AX causes pain on two fronts:

1. Uniqueness. Element IDs must be unique on any given installation. We have a suite of tools to help generating unique IDs, detect uniqueness conflicts, etc. Learning and using these tools are painful, resolving ID problems is even more painful, especially on live systems. Further the uniqueness issue makes it hard to combine solutions from different source in one installation.
   
2. Upper limit. Each layer has a finite number of IDs. This means there is an upper limit to how many model elements you can create. Microsoft's core development team knows exactly how this pain feels.

At any rate; this is a problem we need to address - and my team has been given the task. While many solutions spring to mind (use GUIDs or drop IDs completely) this is a case of Devil in the Details.

Business Data: IDs are persisted in the business data base. Any change to IDs would require upgrade scripts. To make matters even worse, IDs are also stored in unstructured blobs; making identification and migration even harder.

Business Logic: Business logic uses IDs. Both Microsoft's business logic; but certainly also the business logic in solutions authored by partners around the world. Changes to IDs would impact all this business logic.

Kernel: The implementation of the kernel used IDs heavily. Changing data type or dropping IDs totally would require rewrite of large portions of the kernel. The kernel provides the API for converting IDs to names and back again.

Application model: IDs (and Names) are stored in the Application Model. IDs are used as references between model elements and IDs bind customizations to the original element. Whatever changes we make, we cannot break the references in the model.

Getting challenges like this is what I love about my job.

A new feature in Dynamics AX 2009 enables developers to write developer documentation directly in the X++ Editor while writing the production code. The feature is very similar to the XML documentation feature in C#.

Basically any method can contain /// (triple-slash) comments followed by structured documentation in XML format. Here is an example:

The developer is assisted by a dynamic documentation template, which is inserted through an editor script. The template automatically builds a skeleton including all the required tags for the current method. On top of this the written documentation is validated by best practice rules; which effectively prevent the documentation from growing stale. Finally a tool enables extraction of the documentation, so it can be processed outside AX, e.g. for publishing on MSDN.

Dynamics AX 2009 contains about 125.000 table and class methods in the SYS layer. To give a perspective on this number, it will take you over 15 years to document them all, if you can document 5 methods an hour.

All the methods shipping with Dynamics AX 2009 will have some documentation:

• 10% will be available in the X++ source code, in the product documentation and on MSDN. This content has been written by developers for developers. (and reviewed by Content Publishing).
• 20% will only be available in the product documentation and on MSDN. This is pattern matched documentation for methods such as main(), construct(), pack(), unpack() and parm(). This documentation has been written once for each pattern, and then applied to all methods matching the pattern.
• 70% will only be available in the product documentation and on MSDN. This is automatically generated minimal documentation for methods that we haven't manually documented. It contains syntax and other high level information.

Or in other words:

• You will never see the dreaded boilerplate "At the time of publication..." again.
• About 40.000 methods contain human written developer documentation.

A new white paper has been published on how to intergrate a third party version control system with AX2009. The white paper is a case study of the steps the MorphX team had to go through in order to integrate Team Foundation Server (TFS) into AX2009.  

The white paper is available for download at these locations:

Microsoft Download Center:
http://www.microsoft.com/downloads/details.aspx?FamilyID=48f803fc-5ded-44a8-a442-e499f2db6382

CustomerSource:
https://mbs.microsoft.com/customersource/documentation/whitepapers/ax2009_integratingthirdpartyvcs

PartnerSource:
https://mbs.microsoft.com/partnersource/deployment/documentation/whitepapers/ax2009_integratingthirdpartyvcs

These days the first milestone of AX6 is being completed. It means the first wave of new functionality has been implemented, tested and documented. As always; it is an exciting time to be working on AX...

One of the features coming in MorphX in AX6 is set of improvements in the X++ Unit Test framework.

First of all the unit test framework in AX6 is leveraging the new attribute feature in the X++ langauge. For example; you can use an attribute to declaratively specify the target class for your test (i.e. the class that is being tested by this unit test). Here is how:

Starting in AX6; you can also use attributes to mark which methods on the unit test class are test methods:

If you are using both unit testing and a version control system, you can benefit from marking your most critical test methods as check-in-tests. When setting up the version control system, you can specify which test project to run during check-in, and whether to run all unit test methods, or only the unit test methods that are marked as check-in-tests. During a check-in process the specified unit tests will be executed, and only if they all succeed the check-in will be submitted. This gives you the flexibility to run the most critical unit tests during the check-in process, while still having a full suite of unit tests that can be run on-demand. Here is how to mark a method as a check-in-test:

This posting is provided "AS IS" with no warranties, and confers no rights.

Here is a sneak preview of the new MorphX developer workspace in Microsoft Dynamics AX 2012.

Notice the clear distinction between developer and application workspaces, and how the layout of the drop down menus makes it possbile to access tools with fewer clicks. You can launch the AX client directly in development mode using: AX32.exe -development.

This post is also available on Channel 9.

THIS POST IS PROVIDED AS-IS AND CONFERS NO RIGHTS.

On behalf of the Dynamics AX 2009 development team I'm proud to announce that as of build 5.0.529.0 we have reached zero X++ best practice errors in the SYS layer.

Version 4.0 was the first release of Dynamics AX without any best practice errors. Reaching this level of code quality was a mammoth effort; due to the huge backlog and many new TwC related BP rules.

In Dynamics AX 2009 the goal was significantly easier to reach, as we didn't have any backlog. However; we have introduced more than 60 new BP rules, including validation of XML documentation, inventory dimensions, upgrade scripts, workflow, list pages, AIF and performance. On top of this the SYS layer now contains much more functionality than ever before - the AOD file alone has grown with more than 50%. All of this now conform to the Best Practice rules implemented.

What does this mean for you as an X++ partner developer?

• When you use the best practice tool, and it reports a BP error - then you should pay attention to it, as you introduced a problem.
• The high quality of the code in the SYS layer should overall make your life easier, as it conforms to a set of standards, making the code easier to understand across the entire application.

For more information on MorphX Best Practices see: Channel 9 Screencast, or MSDN.

For more information on the importance of static code analysis see: Compiler warnings - and so what?

Just now I've held my first sample of the Inside Dynamics AX 4.0 book in my own hands. Before the proud owner walked away with it again, I had a chance to photo the beauty!

If you want a copy for yourself, it is now available on Amazon.

If you already own a copy, make sure to review it on Amazon. I'm eager to hear what you think!

There is a coding pattern that has been proliferating the X++ code base for years. It is not an X++ best practices – nor is it object oriented; yet it is used quite heavily (unfortunately). Consider a simple class hierarchy with an abstract base class and 3 derived classes. A typical implementation of a factory would be a static method on the base class, like this: (Please ignore the type of the parameter – it could  be anything, I choose str for simplicity)

Now; the problems with this approach are many.

• First of all the base class has references to the sub classes. Why is that a problem? Consider the base class is a framework class – is it a good idea for framework classes to have references to consumer classes of the framework? Of course not – we don’t like that coupling.
• Secondarily; the 3 subclasses are all referenced by the same method. Any new sub class would require an update to the factory. This turns the method into a congestion point, and it creates a coupling between sub-classes.

The coupling between the 4 classes spells trouble. If you try to modularize an application written like this, you will quickly realize that the pattern above is bad. You cannot have references from lower-level models (aka. assemblies/modules) to higher-level models. Yet; having a single factory method is valuable and a good practice.

SysExtension Framework to the rescue.

Consider you decorate the subclasses with an attribute, like depicted here:

Then you can rewrite the factory method to this:

The extension framework returns an instance of the right subclass automatically. It uses the attribute to determine which subclass instance to create. Quite simple – extraordinary powerful!

Now notice:

• Truly decoupled! New subclasses can be added without any changes to the base class.
• Less code is required! In the example here the delta is not significant – but sometimes you have switch statements spanning hundreds of lines.
• No change in the public API! The contract stays the same – this is an easy and low risk refactoring.
  

A few words of caution: There is a small performance impact on cold systems when using the SysExtension framework. In most cases you will not notice it; however – for performance critical paths, you should measure the impact of this change before going for it.

To learn more about the SysExtension framework see here.

The book is now being printed.

Read more here:

http://blogs.msdn.com/b/microsoft_press/archive/2012/10/10/rtm-d-today-inside-microsoft-dynamics-ax-2012.aspx