Dynamics AX7 Add-ins : Resolving build issues

When creating add-ins for the newest version of Microsoft Dynamics AX, you may also want to set up a build definition for your project. And as you go along, you will most likely run into one of these 2 problems:


  • First, you will see warnings in your build log that assemblies could not be resolved
  • Second, you will see error that a registry key does not exist followed by the error text : Rainier tools not installed

Resolving assembly references

Though I am not fully sure as to why this is an issue. (Believe me it would take me about 3 posts telling you about the csproj files and the <import> tags to import targets that point to assembly locations, the Dynamics AX tooling not being in the same fixed location and so on). But there is an easy and quick solution that will help you out to get your build result. (Read: there might be a more elegant and elaborate way of doing this, but this solution serves its purpose.

Install the assemblies located in the Dynamics AX Visual Studio extension folder into the GAC. (Look for the assemblies on the file system and you will quickly find where they are installed and pick the ones that you use in your addin because there are quite a lot).


On my system they were installed in the following path:

"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\0ueyjx1c.4xo\

Running the following command installs one of the assemblies I needed: (The GACUtil.exe command utility can be found on the file system if the Windows SDK is installed)

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\0ueyjx1c.4xo\Microsoft.Dynamics.Framework.Tools.Core.dll"

This will make sure your MSBuild will be able to resolve the needed references. Do this for all of the references you need.

Resolving ‘Rainier tools not installed’

To resolve this one, we need to take a look at the post-build event that is put in your project properties when creating a Microsoft Dynamics AX Developer Tools Addin project. My previous post already talked about this script. But if we take a closer look we can see that the script checks for the presence of a registry key that tells us that the Dynamics AX Developer Tools are installed. And the problem lies in the fact that it is looking at the HKEY Current User branch. This key is only available for the user that was deploying the Dynamics AX Developer Tools and not for MSBuild running the build process.


The good news is that it can be easily solved. The post-build event is used to copy your assemblies to the right Visual Studio folders to install the add-in. But when the source code is built using an automated build process, the post-build event can be skipped. To do this, we modify the Visual Studio Build step and pass in the following arguments to MSBuild:


/p:PreBuildEvent= /p:PostBuildEvent=









Problem solved!


Update: Beware of the following. When using this solution you must separate your build machine from your development machine. This will make sure MSBuild finds the references but it also causes Visual Studio not to show all of the add-ins available for Dynamics AX. I haven’t got to the bottom of that side effect but I suspect because it loads them from another location and the MEF extension doesn’t allow those when loading the extensions from the file system.

Dynamics AX7 Add-ins : Deploying separate assemblies

A small tip today for those creating add-ins for Dynamics AX7. If you are creating an add-in, the template provides you with a project containing a class for your menu add-in.

    public class MainMenuAddIn : MainMenuBase

The other thing present in your project is a post-build script that will copy the target assembly to the extension folder of the Dynamics AX 7 Visual Studio extension. By doing so, your add-in will be picked up and loaded by the Dynamics AX 7 extension.

While creating some extensions, I often use separate projects that result in class libraries that contain logic. But if you do this, by default, your add-in will throw exceptions that the referenced assembly could not be loaded. This is because your assembly also needs to be in the folder containing the Dynamics AX 7 extension.

To solve this, you can change the post-build script to also copy other required assemblies.
Look for the line containing:

    SET InstallingAssembly=%1

And add the following line below. (Note that the sample filter MyProject*.dll needs to be replaced with a filter that matches your assemblies that you want to copy)

    SET InstallingMyAssembliesFilter=%2MyProject*.dll

A bit further, add the following line behind the xcopy line

    call xcopy /q /y %InstallingMyAssembliesFilter% .

That should do it for the script itself. The last thing to do is call it post build.
So in the project properties, add the following in the post-build event command line:

    call "$(ProjectDir)\installtovs.bat" "$(TargetPath)" "$(TargetDir)"

Now when you build you solution, you should see the following in your output window:

“Copying “C:\Users\Administrator\Documents\Visual Studio 2015\Projects\MySolution1\MyProject1\bin\Debug\MyAddIn.dll” to Dynamics Addins folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\0ueyjx1c.4xo\AddinExtensions.”

1 File(s) copied
2 File(s) copied

========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========

CombineXpos.exe Length cannot be less than zero

When I was using the combineXPOs.exe executable the other day on a new project, I ran into an issue. The error message thrown by the tool was the following:


CombineXPOs.exe : Warning [-5] CombineXPOs.exe : Error [<pathToXpo>] Length cannot be less than zero.


I remembered that Martin Dráb ran into the same error previously so I went to take a look at his blog post on this type of error. In his post, he explains this might be because of empty / corrupted XPO files and indeed, this error pops up when you either have an empty XPO file or a (corrupted) shared project node that contains no objects.

Removing 2 of 6000+ XPO files that turned out to be empty indeed helped and the tool got further in the list of XPO files. But wait, it still gave the same error message?! So what was different here? I saw that the error code being returned was not -4, but -5. And I did not have empty XPO files anymore. And on top of that, now it was the directory with all the Shared Project XPO files that returned errors.
I couldn’t see right away what the issue was here, so I decided to peek into the executable and reverse engineer a C# project out of it. The I stepped through the process of combining a single file and managed to see what was going on. Somewhere inside there, there is an XPOReader class that opens the XPO files and looks at the encoding of the files.

if (fileStream.Length > 3L && (int)numArray[0] == 239 && ((int)numArray[1] == 187 && (int)numArray[2] == 191))
    this.fileEncoding = (Encoding)this.utf8Encoding;
    num1 = 1;
    this.fileEncoding = Encoding.GetEncoding(1252);

Looking at the code, it turns out that it looks for UTF8 files, and if that is not the case, assumes it has to be CP1252 (Latin 1). What if my files have another encoding? And looking at the files, they turned out to be LCS-2 LE BOM. Until now, I haven’t looked into it why these project XPO files have a different encoding. To solve the issue in this case, a bit of additional code makes sure the XPO reader can correctly read the XPO through codepage 1200.


if (fileStream.Length > 3L && (int)numArray[0] == 239 && ((int)numArray[1] == 187 && (int)numArray[2] == 191))
    this.fileEncoding = (Encoding)this.utf8Encoding;
    num1 = 1;
    // KeSae : Check for codepage UCS-2 LE
    if (numArray[0] == 0xFF && numArray[1] == 0xFE)
        this.fileEncoding = Encoding.GetEncoding(1200);
        this.fileEncoding = Encoding.GetEncoding(1252);

Rebuilding the project resulted in a customized CombineXPOs.exe executable that correctly handles the shared project nodes in

Dynamics AX 7 Tip : What services are exposed?

Hi guys! This is not actually a full blown blog post, but a small, convenient and quick way too list the services that are being exposed by the AOS.
This can be used to see if you custom created service is actually being exposed.


In your browser, go to the following URL: https://<yourAosIisWebsite>/api/services.
In my sample : https://usnconeboxax1aos.cloud.onebox.dynamics.com/api/services


The response is a JSON file listing your running services.


“ServiceGroups”: [
{ “Name”: “AxClient” },
{ “Name”: “AxManageabilityServiceGroup” },
{ “Name”: “AxServerBase” },
{ “Name”: “BIServices” },
{ “Name”: “CuesServiceGroup” },
{ “Name”: “DMFDataManagementServiceGroup” },
{ “Name”: “DMFService” },
{ “Name”: “DMFServiceGroup” },
{ “Name”: “DocumentHandling” },
{ “Name”: “FinancialDimensionServices” },
{ “Name”: “FMVehicleInventoryServiceGroup” },
{ “Name”: “GSMGameStoreManagementServices” },
{ “Name”: “JmgShopfloorServiceGroup” },
{ “Name”: “MonitoringAndDiagnosticsServices” },
{ “Name”: “ProvisioningService” },
{ “Name”: “ReqDemPlanServices” },
{ “Name”: “RetailCDXRealTimeService” },
{ “Name”: “RetailProvisioning” },
{ “Name”: “SharedServices” },
{ “Name”: “SysSecurityFieldAccessServiceGroup” },
{ “Name”: “SysSecurityServices” },
{ “Name”: “SysTestServices” },
{ “Name”: “SysWorkflowEditorServices” },
{ “Name”: “Tracing” },
{ “Name”: “UpgradeServiceGroup” },
{ “Name”: “UserSessionService” },
{ “Name”: “WHSMobileDevicesServices” },
{ “Name”: “WHSServices” },
{ “Name”: “WorkflowService” }

There, quick and easy!

What about this new eXceLleNT Dynamics AX compiler?

As the new major release of Dynamics AX is released, we can now dig a little deeper into some of the new stuff available to us now. And boy did they put in a lot of effort! Previous major releases did bring us some new tools, but there was a balance between new tooling and new functionality. With this major release, the focus is definitely more on getting the technology stack up to date. One of those new things available to us, is a whole new nice and shiny compiler!


Many of you guys will recognize the picture below. In Dynamics AX 2012 RTM and FP, you could literally wait for hours for your compiler to finish. This was because of the single threaded 32-bit compiler in the client. R2 CU6+ brought some relieve by introducing a command line tool that could compile your application with multiple workers, but still the process of compiling X++ and CIL afterwards, was not quite what it should be.


But now those days are over! A new compiler rises! So let’s have a look and see what stuff this brings along.

XLNT (X++ language Toolkit aka Excellent)

XLNT is a framework written in C# that is similar to the Roslyn compiler framework (but much smaller) (https://roslyn.codeplex.com/).  It has been built up from scratch in C# because the old compiler stack (C++) was from a time where hardware and CPU power was not as powerfull as today.


Below you can see a simplified schema of how the compiler is built now. It uses a more phased approach where you are able to ‘plug in’ passes based on what you want to achieve (Compilation, Best Practice checking, …). You can see the compiler as a set of building blocks that you can use for different scenario’s.


Visual Studio Integration

In this major version of Dynamics AX, Visual Studio has become the IDE for all of your X++ source coding on a daily basis. And because of that, one of the two ways you can access the compiler is from within the GUI of Visual Studio (and the other one is a command line tool called xppc, which can be a post on it’s own)


To start a compilation, you can do one of two things:


  • you can just build your solution / project as you would do with any other C# application. This will invoke an incremental compile of what has changed. To be able to give you a good experience within Visual Studio, this type of compilation is triggered when you go around and change things and will only compile a subset of your model by only recompiling the netmodules in which the changed objects reside.
  • Another way of compiling is to use the new Dynamics AX menu to perform a build on the models you select. This is called a full compilation of the model and will compile all of the netmodules related to your selected models.


If you save your source code written in Visual Studio, every single method is persisted into its own XML file. The XLNT framework is responsible of writing to and reading back from the XML files. (aka stitching and unstitching).


Basic navigation (stuff like Go to declaration) relies on cross references. So to be able to do this, the compiler will contain a pass that handles cross references and bulk copies related data to the cross reference database (DYNAMICSXREFDB). Also keep in mind that when you do not need a building block like this (say in a nightly build), you can just leave it out and compilation time will be much less.

X++ Compilation

In previous versions, not all of the code was generated in MSIL. A part of the code was still compiled into P-Code and being interpreted at run time. Another part was transformed into MSIL by XSL transforming P-Code generated by the compiler. But as of now, this is entirely gone and everything is generated in MSIL managed code by the compiler!


On top of that, the new compiler is massively parallel : as Microsoft states: “This thing will get his hand on all of the resources it can take to do as many things in parallel as possible. It means that you need to run this on a machine with at least 16GB of memory for a full build. That’s just how it’s designed.”


Another feature which is really nice, is the diagnostics support. At each point in time, the compiler can output error messages that will be included in the diagnostic telemetry available for the application. Based on this telemetry data, you can get an insight into different aspects of compilations. Microsoft is able to act on compiler errors, crashes, … much quicker then before to improve the compiling experience.

Best Practices

Let’s not leave out best practices. As Peter Villadsen quoted : “BP’s are important, anyone who says different, has not been in the industry long enough and not suffered enough. They are the result of many years of industry practice and should not be disregarded.” And I could not agree more. For years know, we have been making an effort and succeeded in customizing Dynamics AX without introducing new best practice violations. And to help with this, the XLNT framework also provides the tooling for checking best practices and authoring custom rules.


The best practice checking tool, like the compiler, can be run automatically when compiling or can be called using a command line tool. And Microsoft has clearly taken this seriously because for the first time ever, they too have adopted a zero tolerance approach for all of their code. So yes, all best practices have been addressed!


So this is in a nuttshell what the new compiler is all about. Stay tuned for more!

How we do AX releases – Part 1

“Good release management practices ensure that when your software is built, it will be successfully deployed to the people who want to use it. You have the opportunity to satisfy existing customers and hopefully to win new ones.”  It’s a statement coming from a excellent article dicussing 7 ways to improve your releases. Before continuing here, make sure you read the article entirely. It really deals with all of the facets of releases, starting from planning to infrastructure and automation of the process.


Let’s elaborate on a few of the topics in the article and explain how this series will provide a way of doing this for Microsoft Dynamics Ax releases (And remember: It will be A way to do it, not THE way):


  • Plan your releases!
    Captain obvious to the rescue.. But let’s be honest, how many of you technicals are often forced into a situation where an ad hoc release is asked…? So it is of the utmost importance to establish a regular release cycle. That way, all of the stakeholders have a clear view on the timetable and when to expect to see progress. Your release cycle is not about when your customer wants the release. It’s about when you can deliver it to the desired level of quality.One thing we have done to support planning releases and follow up the time spent on releases, is creating a custom work item type ‘Release’. On that custom work item type, we can put all the details concerning the release (Title, Original Estimate, Actuals, linked queries to be able to query for the work items related to this release)


  • Establish your release infrastructure early
    For Dynamics projects, this is even more important. Especially because a full Microsoft Dynamics AX environment requires quite some resources. This is one of the most difficult topics to discuss when it comes to figures. Having all of the needed environments (DEV, QA, UAT, STAGING, MIGRATION, PRODUCTION) will make you expensive as opposed to other vendors stating that a DEV, QA and PRD are enough. But in the end, the customer will notice during the implementation that he does need those to do things as they should be done.


  • Release notes are not optional!
    And yet I still come accross projects where releases are done without informing the customer what has actually been changed. And it’s all about perception here. You do not want all of the bugs to be on the notes, but the ones reported by the customer do need to be mentioned. That way, customers have the notion of progress and key users can be informed about the changes.To achieve this, we have done two things. First we have added a field Release note (No / Yes) to the work item types available on release notes. This way we can actually filter out the things we do not want on the notes. Secondly, we created a Visual Studio Team Explorer add-in to enable us to generate release notes based on a selected work item of the type Release. Through the use of the OpenXML SDK, we generate a word document containing a couple of sections and each section is linked to a work item query.


In the next post of this series, we will take a closer look at the custom work item type ‘Release’.

AX2012 Extension framework generation wizard

Many of you might have come accross the Extension Framework while venturing in AX2012 for some years now. Personally, I use this pattern a lot in my code as the benefits of using it are obvious:

  • Your extensions are more decoupled from the standard code which reduces upgrade work
  • Your code will be more robust and cleaner
  • Implementing extra different behavior is easy if the pattern is already in place
  • And let’s admit it, we have indeed become lazy and do stuff the easy way. Result is code that wouldn’t be written if it were in another language

Before jumping into the wizard, you should read the following posts giving a nice overview of what this pattern is all about.

After using this pattern so many times, I wanted to share a tool that allows you to specify some of the needed information and then creates all of the elements for you. This allows you to use this pattern without having to complain about the ‘overhead’ it might be causing you. So let’s jump in then.

First, before all else, we need an enum that contains the different behaviors that will be available. In our sample we will use two methods of calculating, adding and multiplying. Do not forget the none value so that we can easily see if the type has been passed on.

Base enum

Then opening the wizard and clicking next, it shows the second tab page allowing you to specify the following information:

  • Attribute class name
  • The XML comment class name description of the attribute class
  • The system element name of the enum
  • A variable name that will be used for your enum when generating the pattern

Second Tab Page

When ready, move to the third tab and fill in the class name and XML documentation description for the following objects:

  • The interface
  • The base class
  • The factory class
  • The parameters class


With all of this filled in, click finish and you are ready with your end of the bargain. Now sit back and let the wizard take care of the following part. The result should look like this:

  • The attribute

  • The interface

  • The abstract base class

  • The parameters class

    This class is required to get around what I call the one hickup with this pattern. Since it uses reflection to get to the class containing the right attribute, there is a makeObject() involved. This will in it’s turn call the new() method of our behavior classes thus preventing us from passing different sets of parameters for different behaviors. I usually solve this by creating a parameter class containing the possible parameters in behaviors. You can fill in the parameters for the behavior you need at that time and leave the ones your do not use empty. The wizard by default creates the object with one dummy boolean and corresponding parameter method.
  • The factory class mainly contains a factory method to create the behavior


So as you can see, the wizard created the most of the stuff containing the plumbing with enums, attributes, …

The only thing we have to do to get things up and running is creating the behaviors ourselves since the wizard does not know what we want to do. So to implement our two behaviors, we need to do the following:

  • Add parameters to the parameter class
    We will be adding or multiplying two integers, so let’s add these.


  • Add a calculation method to the interface / abstract base class



  • Create the two calculation behaviors.
    To do this, create two classes that each use an attribute and each implement the doCalculation method. The ‘add’ behavior is show below.


Now that everything is in place, we can use it so let’s add and multiply the numbers.


This should output the following:


And there we have it, just calling the same code with different enums changes the behavior of the calculation. And the best part, from now on, if a developer wants to extend this and write other behaviors, the only thing he need to do is add and enum element and write a class that passes that enum to the attibute!

The source code of the wizard can be found here 

RM for VS2013 : Creating the deployment sequence

This is the third post in a series discussing automated releases for Dynamics AX 2012 with ReleaseManagement for Visual Studio 2013. Before, we discussed the following topics:

  • Part 1 discussed the pros and cons of ReleaseManagement and gave a glimpse on how we would fit in Dynamics AX.
  • With part 2 , a first tool was created. This gave an overview of the central PowerShell module and explained the use of tool wrappers.

In this post, I wanted to tell you all about setting up servers, environments, paths and so on, but this is already well documented in the user’s guide. Also for AX, this does not differ from other products. (http://download.microsoft.com/download/2/9/B/29B10D38-3473-4AC2-9CEB-7D471E0A8ECD/Release%20Management%20for%20Visual%20Studio%202013%20User%20Guide.pdf) (Sorry for the links in here, but WordPress is bugging me with some issues in the editor :))


Instead, let’s focus on the AX specific parts. More specifically:

  • Component configuration
  • Release Template configuration
  • Deployment sequence

Component configuration

Components can be seen as logical parts of a solution. This can be a database, a website, … These components can be configured in RM and you can assign deployment tools to them, link them to sources, … For Dynamics AX, we state that the component is comprised of the set of models or model store in the build output.

So for us, the configuration of an ‘AX Component’ is pretty straight forward. We create a component “AX2012Solution” and there are 2 things to configure: Where are your component sources and how do we deploy these source to the agents?


First, we define where the component sources are located. There are 3 options here:

  • Builds with application
    This links the component to a TFS Build definition defined in the release template. By doing so, RM knows what build drops to take and use these as the source for your deployment. So different release templates can be attached to different definitions. We use this when branching environments.
  • Builds independently
    In short, this is the same as the first option, but the build definition is linked to the component and not to the release template.
  • Builds externally
    Use this when you have no access to TFS from you deployment machines. You are able to have ‘offline’ source available in a folder.

In our case , this is linked to TFS through the release template.


Next, the Deployment tab is up. Here we’ll tell RM how to deploy the selected resources to the deployment agents (the machines involved in your deployment). And for AX, we can use the XCopy deployer here. Why?? Because we can use it to simply copy the sources from the build output folder to a known variable (__installationPath__) within RM. From then on, we can use that variable in our release template.


Release Template configuration

Next, you need to create a release template. This is when all of the pieces fall together. Start of by selecting the properties of your template. There you can specify the release path to be used. All of the stages in your path will result in a tab on your template. So it is possible to have a different deployment sequence for the different stages.

The second important thing here is the connection to the TFS Build definition. When you specify a build definition, RM will be able to present a list of recent builds when starting a new release.


Deployment sequence

And now, the magic of the whole thing! Putting together a sequence of actions that define your release. In the sequence editor you can see the following:

  • At the left side, the toolbar containing your servers, components and inventory (tooling)
  • Top right, you can see a tab for each of you stages in the release path. (To be able to have deployment template per stage)
  • In the main area, you can drag and drop your action to the canvas. Depending on the action, you can input the parameter values needed.

So you can start of by dragging actions and composing your deployment. There a few rules here to keep in mind.

  • Actions run on a certain server, so you have to start dragging the machine you want to use first.
  • Your component is also available in the toolbox, so you can use your component shape to copy the build sources to the corresponding server.

Below, you can see a part of the deployment sequence and how it all falls together. The Install AX model action will collect parameters and pass them on to the PowerShell wrapper tool. From there on, the central PowerShell module is called and parameters are passed.



 There you go! I hope this has shed some light on how to configure you deployment sequence for AX. In the next post, we will take a look at starting a release and how we can follow up deployments. After that, we should also take a look into the TFS Build template to trigger RM releases from within TFS Builds.


Permission denied in database ‘TempDB’

Today, opening the Global address book form presented me this nice error: Permission denied in database ‘TempDB’. And this is not the first time this one surfaced, but most of the online solutions are not entirely correct. So let’s explain this one.

Doing an online search will show you that the reason of this is simple, the AOS has no permission in the TempDB as the error states. But why? Well, the first important thing you need to keep in mind is that the TempDB database is recreated when the SQL Server is restarted. Thus, something will need to reapply the needed permissions for the AOS after a restart. Most online solutions show you how to apply these permissions, others even schedule a T-SQL command to run periodically to do so!! But this is not how this is intended to work.

When installing an AOS, the installer will create stored procedures in the Master database to set the needed permissions on the TempDB. These procedures are called by the AOS when SQL has been restarted and appropriate permissions are missing. And this is where the problem mostly comes from. When the account running the AOS service has been altered, these stored procedures haven’t and they still have the old AOS user account. This means, when they are called to grant permissions to the TempDB, they do so for the wrong AOS account!


Altering these to contain the correct AOS user account will solve the issue in case of a SQL reboot.

RM for VS2013 : Increase TFS deployment timeout

Today I saw that the TFS build had triggered the ReleaseManagement client but that it had failed. A closer look at it told me that TFS thought it had been waiting long enough and decided that the deployment failed. So I went to the ReleaseManagement client and tried to increase the timeout for TFS Triggered deployments. But the maximum value allowed in the client is 99 minutes. Yes… 99 minutes so clearly my AX deployment will take longer due to full compile, report deployment, portal deployment, …























To get around this, you can skip the client and dive into the SQL database of ReleaseManagement. There is a table called SystemSettings which contains all of the RM settings. To get the timeout above the 99 minutes, just update the DeploymentStatusCheckMaxWaitInMinutes field with the value you need here.


UPDATE [ReleaseManagement].[dbo].[SystemSettings]
SET    DeploymentStatusCheckMaxWaitInMinutes = 180

Reopen the client and there you have it.