Sometimes big things happen which get little press or coverage, such as the case with the move to the file based code deployment in our newest version of AX. In this post, we’ll look at some real-world, but currently undocumented ways, to truly utilize the new changes towards efficient best practice, continuous improvement code methodology. There are significant consequences of this and we will create some real life scenarios to demonstrate it. This switch to file based code management has really opened up some doors.

First, Puff goes the “Model Store” database. In comes the File Based Deployment.

Microsoft got it right with a major step towards continuous code improvement in Dynamics AX. First, gone is the model store database. Instead, we have a bunch of XML files that can be compiled and stored in a database. The presence of file based XML makes it so that you could theoretically use anything to checkin XML for TFS. There is an inherent advantage in all of this, you can pretty much adjust your code strategy to be anything you want. All you have to do is manage a bunch of XML files. Likewise, it also provides opportunities for the newly revamped extension model and code performance testing enhancements.

Let’s go through some real-world examples:

Example 1 Problem: You’ve just started a new implementation and have been told the code is a mess. Bunches of people along with multiple ISV’s and Vars have worked on the code before you and no one seems to know what was done. You need to quickly get a list of all the code deployed so as to get an idea of what has been changed to stabilize the implementation so as to get development going again.

Example 1 Solution: Using our newfound knowledge that the code is really just a bunch of XML files, we go a step further than Microsoft’s XPath queries and go straight back to Powershell.

We simply perform a command:

Get-ChildItem
-Path
“C:Packages*”
-Recurse
-Include
*.xml `

|
select
FullName, Name
|Sort-Object
FullName |
out-gridview

And this produces a perfect example. Notice what happens.. Under Packages, the model is ApplicationFoundation. Removing the prefix “AX” for example, tells you the name of each element in that model.

Now, that makes things easy. So essentially, gone are most of the powershell commandlets, but not really. You have far more available. I could have called the last Powershell commandlet GET-AXMODELCONTENT and it would have given me everything listed in the modelstore.

Example 2: Problem You need to count how many Classes are in a model to get an idea of the amount of work that will need to be done to fix some ISV that just isn’t working on your deployment. How could you do this quickly and easily?

Example 2: Solution This is easy. Using Powershell makes it easy to search and count files. No need for big, bad XPATH.

[System.IO.Directory::GetFiles(C:PackagesApplicationFoundationApplicationFoundationAxClass*”,”*.xml”).count

Example 3: Problem Something has happened in the code but everyone swears that no one has done anything. You need to determine what was the last code that changed within the last 6 months.

Example 3: Solution Once again, this becomes a trivial task with powershell.

Get-ChildItem
-Path
“C:Packages*”
-Recurse
-Include
*.xml `

|
Where{$_.LastWriteTime –ge (Get-Date).addDays(-180)} |Sort-Object
lastWriteTime | out-gridview

In ascending order, I can easily see the last modified code items.

Wow… More, More, More our developers screen.. all in due time, I suppose. After all, I’ve only shown that Powershell can now be used with Dynamics AX more than ever. What I haven’t covered is what we can do now with MongoDB and Powershell or some other NOSQL database. We are pretty much unlimited here in being able to modify our code patterns to whatever situation needed. This wasn’t as easy to do previously. I think that is a big positive step. My only negative feedback, and this has to do with AX 7 being new more than anything else, is that this is all virtually undefined with Microsoft at the moment. It took me 15 minutes to show 3 real-world cases. Releasing 30 or so code management or administration management commandlets would go a long way towards making the new framework more adaptable. Chances are high that it will come in time. Still, overall, it’s nice to see that AX took a major code leap towards continuous improvement in the new version of AX.