Dynamics AX 2012 and Visual Studio 2013: Are you talking to me?

Feb 25, 2016
Written by

By Graham Richardson

Making changes to an SSRS report for AX is designed to be a simple process. Create and Edit the report in Visual Studio then build and deploy back into the AOT, then publish to the SSRS instance.

When making changes to an SSRS Report through Visual Studio however, we were getting some very strange behaviour. We had updated the data provider with several new fields, but no matter what we did they were not showing in Visual Studio.

We ran through the usual gamut of standard fixes that I am sure most of you would have tried:

  • Check correct configuration selected for Visual Studio
  • Restart AOS
  • Incremental CIL build
  • Clear XppIL folder and full CIL build
  • Full X++ recompile then clear XppIL folder and full CIL build

Nothing worked. The fields stubbornly refused to appear in the Data Provider. When looking at the AOT in Visual Studio, everything was fine, the fields were there, staring back at us, just not in the Data Provider.

The cause, we realised, was that we had specified the AX configuration for Visual Studio on start-up.

Visual Studio had used the specified configuration for the AOT and the object therein.  However when looking up the data providers, it turned into a lazy print job, and fell back onto the default configuration.


We used the AX client configuration tool to change the default configuration to the same as the configuration file we had specified.  This allowed us to continue, although I would not call it a fix. There does not appear to be a fix for Visual Studio at the moment either.

 Replication Steps:

The steps to replicate are fairly straightforward:

  • Create two AX instances, ENV1 and ENV2
  • Change a Data Provider in ENV2
  • Set the default AX configuration to ENV1
  • Set the Visual Studio axconfig parameter to ENV2
  • Start Visual Studio and edit an SSRS report based on the changed data provider
  • When loading data providers in Visual Studio they will be loaded from ENV1 not ENV2



Based on everything that happened and until a fix is located for visual studio, I recommend ensuring that Visual Studio is only installed somewhere where changing the default configuration will not impact another user. This ideally means it is installed on a local machine where you can change the configuration as you like or installing it on a server where there are no end users.