May 5, 2016
Filed under: #daxmusings #bizapps

This is Part 3 in my design, compile, run series. Please first read Part 1 about paradigms, and especially Part 2 on design, compile, run in AX 2012.

In part 2 I explained the design time, compile time and run time differences in AX2012. However subtle and vague they may be, they are there. We can (mostly) choose to ignore them, if we wish, but ultimately that is how the system works. In the new Dynamics AX (AX7), these three distinct phases are hard facts that you cannot work around. There is a design time in Visual Studio where you create your code and your metadata. There’s a compile time where that code and metadata is taken and compiled into DLLs. And then there is a run time that can run those DLLs. And although the compile time is integrated into Visual Studio (the design time), it’s essentially a command-line utility that Visual Studio calls to invoke that compile time. Let’s look at what this looks like.

I’ll re-use the graphics from the previous post, in reverse order, to build back up to the paradigms in the next post. First, let’s look at the tools we use in AX 7. As you probably know by now, AX 7 no longer has a client. Everything runs server-side, and there is some browser code (arguably that could be considered a type of client) that displays everything from the server. So the AX 2012 client which hosted both the design time, compile time and run time is entirely gone, so there is no tool left that spans all three phases.

Immediately noticable is that each tool handles a specific phase, there is no overlap anywhere. There’s design-time tools (Visual Studio), compile-time tools (xpp compiler - xppc) and the .NET run-time running with the AOS kernel in IIS. Note also that there is no X++ interpreter anymore. X++ is now a 100% managed language running in the .NET CLR. The compiler is now rewritten entirely and compiles directly to .NET assemblies (and is scalable… give it more memory and more CPU and it will go faster). Of course, this has some implications to the traditional way I described in the previous post. For one, you always have to compile everything (although there’s good news here, we’ll describe what “everything” really means in the next post). If you have a compile error, you don’t have anything to run. This also means you actually have compiled binaries to deploy. The run-time can’t do anything with code, it can only run binaries. Which means for deployment purposes, you’re deploying binaries not source code. So no merging and all that because that is a design-time task.

Next, let’s look at the next slide of what “file formats” exist in each phase.

So, yes, XPOs are finally gone! And make no mistake, the XML files are not just a replacement - they ARE your code files now. Since design-time is separated from run-time, you don’t “import” your code into a server. The code is a bunch of (XML) files on disk. The next question that comes up a lot is then - but how do I run the code in Visual Studio? Well, just like you would be creating an ASP.NET app or such, Visual Studio will run the compiler for you, then copy the binaries into a local IIS server, and start the IIS process. Visual Studio doesn’t run your code, after compiling it deploys the binaries and then opens a browser - exactly like a C# ASP.NET project. That means when you edit code and or change forms from within Visual Studio, you are actually editing XML files. This has a few important implications!

1) You cannot “share” a development box for several reasons. If two developers are editing the same file at the same time, the last one that saves wins and overwrites. Think of editing a .TXT file in Notepad. If two people open the same file at the same time, the first one makes a change and saves. The second (who doesn’t have the first one’s changes) makes a different change and saves. Essentially, only the second person’s changes end up in the file. The other reason is similar to AX 2012 - if someone has work in progress you could have compile errors, which now in AX7 entirely prevent you from generating the assembly DLLs for the runtime. 2) Since all code is files, and we are working inside Visual Studio, source control is a breeze! Where in previous releases of AX there was always an export to XPO and then check into source control (essentially a two-step process in different formats), you are now editing EXACTLY what you will check into source control. More on this in the next post when we talk about the new paradigms. 3) Some “automatic” relationships that existed when the AOT was part of the runtime (let’s say, renaming a field) no longer resolve. If you rename a field, you’ll have to get the list of references (or do a compile to get the errors) and fix the artifacts and their files (for example, form controls etc.). This is a good thing: in AX 2012 this could cause issues when using source control - a field rename would fix some things automatically in your AOT, but wouldn’t check-out and re-export the XPOs of those “fixed” artifacts, probably causing issues for other developers, builds, etc.

Of course, these are the file formats for the artifacts that the phases use. But now we have another new concept - file formats for DEPLOYING those artifacts.

The concept of an AxModel still exists, and it’s now essentially just a zip file with all your model’s XML files in it (plus the model manifest, now called the “descriptor file”). AxModels are a format to distribute code around, but mostly between different development parties (such as an ISV, a Partner and a Customer). To keep source code in sync between developer’s machines at the same company, we use what we everyone else is using: source control. Although some new LCS features require you to use VSTS (Visual Studio Team Services) with TFVC (Team Foundation Version Control), for source control purposes only you can use whatever Visual Studio or its plugins support. You can use VSTS with git, you could use GitHub, etc. Note that VSTS with TFVC is currently required for project management and code upgrade features - support for other source control systems is being evaluated and may get added in later versions. The concept of the model store needs some rethinking, we’ll discuss that in the next post. But as we discussed here, the run-time just needs the DLLs of your custom code. We don’t want you to just copy DLL files around, so there’s a concept of a “deployable package” which is essentially a collection of one or more DLL files with scripts to deploy it. Today there are some manual steps to deploy that deployable package, but automation for this is just around the corner. So, when deploying code to a test environment or production environment, the deployable package is the vehicle to distribute your compiled assemblies.

Both the model file and the deployable package can be outputs of your automated builds. We’ll discuss builds and automation some other time.

Next post, let’s put these tools and file formats in perspective and review the paradigms and architecture in AX 7.

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!