Updated 30-06-2012 official beta version available here: http://informationsource.dynamics.com/RFPServicesOnline/Rfpservicesonline.aspx?ToolName=Microsoft+Dynamics+AX+2012+Combine+XPO+Tool+Beta+1.0

Updated 14-01-2011 to support UniCode XPO files. Notice the change in parameters.

So now you are using version control - and you just realized the master is no longer the AOD layer file, but instead a zillion of XPO files. Still you want to provide an AOD file to your consumers, as that is the way to deploy an AX application.

Page 96 in Inside Dynamics AX 2009 contains a description on how to build an AOD file from XPO files. In this section an SDK and a tool are mentioned. While we are working on providing you with the SDK for building a layer file, I can make the CombineXPOs.exe tool available.

See the attached file.

Usage: CombineXPOs.exe -XpoDir XPOfolder -CombinedXpoFile DestinationFile.xpo -utf8

Example: CombineXPOs.exe -XpoDir USR -CombinedXpoFile myFile.xpo

Files in the XPOFolder folder must match the AOT structure. This is automatically ensured when using AX version control integration.

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

Source code is written once; and read over and over again. So make sure it is easy to read and understand.

I keep seeing a poor coding practice. I see it in production code, in test code, in X++ code, in C# code, in C++ code, in examples on the web, when interviewing candidates. I see it where ever I look. It is a practice that adds unnecessary complexity to source code, it make the source code harder to read, and harder to write. And what disturbs me the most is, how easy it is to avoid.

Take a look at this simple code:

Now I got it off my chest :-)

About a milestone ago I announced SQL AOD. Since then it has been quite quiet on my blog - for two reasons 1) I've been heads down in new features and 2) I've been on paternity leave. Now the completion of M2, the next milestone of AX "6", is within reach and I've returned to my office. This means I can share some more exciting news.

Since the days of AOD files are numbered we need a new vehicle for deploying metadata elements to an AX installation. To address this need we introduce Models. A model is a containment of metadata elements.

To create a model you use the new command line utility AxUtil:

This will create a new model with the name "My Model" in the USR layer. This new model can be selected in the AX client configuration utility as the default model. When you start AX the status bar will tell you which model you are currently working in - just next to where the current layer is shown. When you make changes in the AOT, like overlayering elements, creating new elements, changing X++ code etc., the resulting elements will automaticaly be contained in your model.

When you have completed all your changes, then your model is complete. In other words it is time to move the model from your developer box to a production system. In AX2009 you would copy your AOD files - with models you need to export it to a physical file. Again you will use AxUtil:

Now you can copy this file to the production system and import it there:

You can even uninstall it again - if that is what you want. This is semantically the same as deleting an AOD file in AX2009:

So far I have described the model capabilities that gives parity with AOD files: We have a file based container that can be xcopy deployed and we can delete models again.

From what I've described so far models aren't much different than layers and AOD files. They are; and provide some highly desirable capabilities - which will be the topic of a near-future post - so stay tuned.

This post is a part of a series on models:

1. Deploying models
2. Manifest and signing
3. Multiple models per layer
4. Working with models inside MorphX

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

Today we built the first official build of Dynamics AX ever that does not run on AOD files. Starting today Dynamics AX's model database is stored in a Microsoft SQL Server database.

Seen from within MorphX you hardly notice the difference. Everything works as it used to; there are no new feautures; but yet it feels different. The responsiveness of MorphX has slowly been deteriorating as the number of elements in the model has grown over the last releases. Today the speed is back. Navigating the AOT is suddently a pleasure again. Meta data heavy operations, like searching, completes an order of magnitude faster. For example; searching all methods on forms for any text completes in 2 seconds.

But wait a minute; AOD files were not just a database, they were also a deployment vehicle - what is the replacement? Dynamics AX supports a new file format: axmodel-files. (extension: "axmodel", example: "AxSYS.axmodel"). These are binary files, and provides the same deployment capabilites as AOD files did - and yet they are less than half size. Using a new tool you can import/export axmodel files to/from SQL. You can also import AOD files into SQL.

So far we have aimed at providing 1-to-1 parity with AOD files; but the potential of this is amazing - I hardly know where to start...

• Performance can be further improved as the subsystems querying the meta data store starts levarging the powers of SQL. For example; the ISAM database used for the AOD files (and still used by temp tables) doesn't support joins. Due to this many subsystems are overly chatty when reading meta data as they query row-by-row.
• Solving the element ID problem is now possible, as we can leverage the flexibilty and powers in SQL for modifying and extending the model schema.
• Capabilities... There are so many cool scenarios we can enable - but you'll have to wait for an sneak preview after the next milestone to learn more. But to get you thinking: What deployment capabilties did AOD files lack?

To night we celebrate this major achievement with the team. 

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

In my first two posts on models in AX (Part 1 and Part 2) I covered the deployment specific behaviors of .axmodel files - it should be apparent we introduced .axmodel files as a deployment replacement for AOD files. In the process we added some nice capabilities like a manifest and signing. The real benefit of models, and the ultimate reason we are adding this level of abstraction is because:

You can have as many models per layer as you want.

Let us examine this statement. In AX2009 a layer is the confinement unit of model elements. The layer is the unit of which you can export, deploy and delete model elements. (Here I'm deliberately ignoring the capabilities provided by XPO files, as these are suitable for development purposes only, and not deployment.) In AX6 this limitation has been removed, that means you can segment your layer into as many models as you like.

Here are a few examples where this could be useful in development scenarios: 

• If you deliver more than one solution:
  You can have a model for each of the solutions you are working on. This enables you to work on them simultaneously while having visibility into which model you are working on.
   
• If your solution is getting too big:
  You can segment your solution into several models - and have teams/team members work on their own model. The models can be either self-contained or have dependencies to other models. This enables you to clearly define ownership between the models, clearly define the APIs between the models, build the models individually, etc.
   
• If you write unit test:
  You can have a model for your production code and a model for your unit tests. This enables you to easily import all your unit tests, run them, and remove them again from the system.
   

Let's examine the statement a bit deeper. There are two ways of getting a model: Either you create one on your own, or you receive it from someone else. If you can have as many models as you want per layer, it also means:

You can deploy models from several sources into the same layer.

Here is an example: You are a customer and would like to install two ISV solutions that both are available in the BUS layer. In AX2009 you would have a tough choice to make: Either you picked your favorite solution and learned to live without the other one, or you invested in having the two solutions merged into one layer. This merge is technical challenging, and a costly affair once updates to either solution are being released. In AX6, however, you download the two models, and use AxUtil to import them. When a new version of either model is released, you simply use AxUtil to update the model.

The catch

This all sounds too good to be true, what is the downside? There is one limitation to what a model can contain:

An element can only be defined once per layer.

This means that two models containing a definition of the same element cannot be installed in the same layer. For example; if the two models both contain a class named: "MyClass" they will not be able to install side-by-side in the same layer. Model elements have two alternate keys, they are: [Type, Parent, ID] and [Type, Parent, Name]. Each layer can only contain elements that can uniquely be identified via the two alternate keys. In less technical terms, this means that two elements of same type under same parent (or without a parent) cannot co-exist if they have same name or same ID. For example: A table cannot have two fields with same name, or two fields with same ID. Another example: You cannot have two display menu items with the same name.

There are three ways you can be hit by this limitation:

1. You create an element, and give it a name that accidentally also has been chosen for another element by someone else in their model. A good way to avoid this to prefix your new elements with short string that uniquely identify you or your company. So instead of me naming my class "MyClass" I should name it "MfpMyClass". You can think of this as poor-man's namespaces. This is a practice that is already widely used.
    
2. You create an element that will be assigned an ID by the system, which already has been assigned to another element created by someone else in their model. Our plan is that this cannot occur once we ship AX6 - we are close to a full implementation of this, but we are not there yet. I'll return with more details on this at a later point.
    
3. You customize an existing element that also has been customized by someone else in their model. There is really nothing you can do to avoid this collision, except to avoid customizing - which is not desirable nor possible. To alleviate this problem we are investing in changing the granularity of elements. In AX2009 tables and classes are stored with a fine granularity. This means that there is no collision if two models change two different methods on the same class or table. In AX6 all new concepts introduced in the model will also use a fine granularity - further we are breaking down some of the existing concepts, so far we have completed this work for Menus.
    

So apparently we cannot guarantee that models can co-exist in the same layer - so what are the options when two models are in conflict? When you import a model that conflicts with an already imported model, you get three options:

• Push-up (default)
  This option creates a new model in layer above containing the conflicting elements. This enables you to log into this layer and resolve the conflicts using the MorphX tools you are used to. Please notice that only the few elements in-conflict will be moved into this model, so the resolutions required are limited, and the original models will co-exist in the model store - but not only in the same layer.  
  
  For example; if two models ("ModelA" and "ModelB") are imported into the BUS layer, then "ModelA" is imported without any problems, and "ModelB" will be imported into two models: "ModelB" in the BUS layer, and "ModelB_Conflicts" in the BUP layer.
   
• Overwrite
  This option will overwrite any existing definitions with the definitions in the new model. Any model containing element definitions that get overwritten will be logically grouped with new model. The grouping ensure that an eventual uninstall of a model doesn't leave the system in an in-complete state. This option is primary useful for patches that are accumulative in nature.
  
  For example; If a model "ModelA" containing PatchA is already installed, and a new model "ModelB" containing PatchA+B is being installed then this is the right option. Later; if "ModelB" is being uninstalled, then "ModelA" is also automatically uninstalled.
   
• Abort
  This option aborts the operation and leaves the model store untouched - perhaps you specified the wrong model file, perhaps you want to investigate the models before continuing. 
   

Conclusion

Models enable a lot of highly desirable scenarios, one of the most important scenarios being that models from different sources - for example, two ISVs - can be installed in the same layer side-by-side.  There are a few technical limitations; but the risk of conflicts is much reduced in AX6 and even when conflicts occur there is a less-expensive way to make the models co-exist.  

More on models...

This post is a part of a series on models:

1. Deploying models
2. Manifest and signing
3. Multiple models per layer
4. Working with models inside MorphX

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

Deepak Kumar and myself hosted a session on the upgrade process at Convergence in Orlando. A big thank you to everyone who attended; we are truly humbled by the great feedback we are receiving for our session. An even bigger round of applause is due to Paul Langowski from Tectura, who joined us on stage to give testimony on two "double-leap" upgrades he has worked on.

For those of you who wasn't able to attend, I've attached the slide deck to this post.

Here is the excerpt of the session:

Upgrading to Microsoft Dynamics AX 4.0 and Microsoft Dynamics AX 2009; 3/13/2008 10:00AM-11:00AM; W204

This session will take you through the end-to-end flow of upgrading from Microsoft Dynamics AX 3.0 to Microsoft Dynamics AX 4.0 and Microsoft Dynamics AX 2009. You will see an overview of the code upgrade as well as the data upgrade process along with recommended best practices. Examples of the improved upgrade documentation, with a focus on the implementation guidelines that come with a dedicated section for upgrade, will also be covered. This session will also include tips on performing data upgrade and code upgrade more efficiently and effectively. Additionally, you'll learn tips on the extra steps needed to upgrade if you've extended your solution. This session is designed for partners and customers who are planning to upgrade or would like to learn more about a Microsoft Dynamics AX upgrade.

PartnerSource: https://mbs.microsoft.com/partnersource/support/selfsupport/productreleases/AX2009DemoData.htm

CustomerSource: https://mbs.microsoft.com/customersource/downloads/servicepacks/AX2009DemoData.htm

Today Microsoft Dynamics AX 2009 is RTM. This means DVDs are now being mass produced, and the product is available for download at Partner Source.

My favorite features in DAX2009:

• Brand new UI: List pages, role centers, crumb-bar, activity centers and ribbons.
• Improved performance. Especially I like the near-instantly startup of the clients.
• Workflow support.
• Improved reporting and BI facilties; powered by SSRS.
• Enhanced developer experienced: TFS integration, XML documentation, ER diagrams, CLR interop and much more.
• New suite of tools for code upgrade.

I'm proud to have been a part of the extraordinary team building this extraordinary product, executing on a 2 year plan and delivering on time. Since you are reading my blog, I feel confident this product will have a postive impact on your professional life. Starting today!

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.

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: http://download.microsoft.com/download/2/5/8/258C8894-B94A-4A87-81EA-4DBB9776F8F2/622579eBook.pdf