Thursday, September 14, 2017

Sample loop through metadata of model

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;
using Microsoft.Dynamics.AX.Metadata.Management;
using Microsoft.Dynamics.AX.Metadata.Modeling;
using Microsoft.Dynamics.AX.Metadata.Storage;
using Microsoft.Dynamics.AX.Metadata.Providers;
using Microsoft.Dynamics.AX.Metadata.MetaModel;

namespace MetaDataExample
    class Program
        static void Main(string[] args)
            string packagesLocalDirectory = @"J:\AosService\PackagesLocalDirectory";
            IMetadataProvider diskMetadataProvider = new MetadataProviderFactory().CreateDiskProvider(packagesLocalDirectory);

            var l = diskMetadataProvider.Tables.ListObjects("MyModelName");
            var le = l.GetEnumerator();

            while (le.MoveNext())
                AxTable t = diskMetadataProvider.Tables.Read(le.Current);



Wednesday, September 6, 2017

Important caveat with the "Chain of command" (CoC) feature

If you use CoC with the July 2017 application release, you need to compile and deploy the standard models you eventually use CoC with. The reason being that the standard models are compiled with Update 8 which didn't have CoC.

This is a temporary inconvenience, and will not be necessary after the "Autum" release.

So, if you write ISV/VAR solutions, you might want to postpone usage of CoC for anything you release before the "Autum" release.

Thursday, August 17, 2017

Package problem with LCS Code Upgrade to July 2017 release

If you get an error like "There is a problem with package 'ContactPerson'. Either the source version being upgraded from is incorrectly identified, or the target version has a package with the same name as a custom package." and you don't have a custom package of the same name, the solution could be the following.

In your existing source (Main branch) you should remove dependencies to the failing models from you model definitions. Check in the change and start the upgrade tool again.

When the upgrade tool is finished you should roll back your change in Main, to keep that branch working.

Wednesday, August 9, 2017

Database log changes in Update 8

Update 8 changes how the database log is logging changes to data. Before Update 8 this was handled through triggers in the kernel and then some application code.

In Update 8 this now happens on triggers created on the SQL Database for each table you enable logging on.

You can still find the old application code in Update 8, but it is not triggered anymore.

There is a bit more information on this community thread:

Friday, July 14, 2017

Clear the AOD cache, including the SysExtension cache, from the UI

There is really no place in the UI of "Microsoft Dynamics 365 for Finance and Operations, Enterprise Edition" where you can find a button to clear the AOD cache.

If you for example introduce a new class to an extension based on SysExtension this is a problem, because it wont be picked up until the cache has been cleared.

The earlier workaround doesn't seem to work in the "July 2017" update.

But the class to clear the cache is runable, so you can build a URL to call it:

https://[your AOS]

Or just make the URL for the menu item:
https://[your AOS]

Big thank you to Volker Deuss for giving me this idea.

Wednesday, July 12, 2017

New "Retail" model in "July 2017" creating backwards compatibility issues

The "July 2017" release has a new model called "Retail" and elements have been moved from other models to this model.

Even if you have made your own solutions exclusively with extensions, this might break your build because you might now need to add a reference to the "Retail" model.

But when you add that, you can't build your solution on the "1611" release anymore because build will complain about not knowing the "Retail" model listed in the Descriptor file.

So, even if your code works perfectly on both "1611" and "July 2017", you could have a need to branch out in VSTS to have two different Descriptor files.

Thursday, June 1, 2017

Merge externally modified label files

Sometimes you may need to have your label files reviewed or changed by an external party not having access to Visual Studio or your VSTS project.
This is a description of how a developer can merge the external changes back into the version control.

The tool used

You can of course use all sorts of different software to help you compare the files and merge the files. In this description we use the Diff and Merging tool that already comes with Visual Studio. This is the tool you'll see open when you have conflicts between local files and files in the source control repository.

These are the steps

The Diff and Merging tools doesn't have a menu in Visual Studio for opening it. So it must be opened through a command prompt and it must be given parameters about the files you want to work with.

Open Visual Studio

Open Visual Studio as you'd normally do. Remember to open it with "Run as administrator".
Make sure that Visual Studio doesn't have a label dialog open.

Get latest label files

Ensure that your system is updated with the latest label files from the version control.

Open the command prompt

1. Click the Window button:

2. Click the arrow:

3. Scroll to the right until you find the "Developer Command Prompt for VS2015":

4. Right-click it and choose "Run as administrator":

5. This opens the command prompt:

Start the merge tool

The merge tool needs to know of four file names:
  • Source file (in our case the current label file)
  • Target file (in our case this is the external file you have to merge in)
  • Base file (in our case also the current label file)
  • Result file (in our case also the current label file – as this is where we want to store the merge)
The following is an example with labels in a package called "EGDiagnosticsPlatform" and a model called "EG Diagnostics Platform". The external label file has been placed in H:\External.

Here are my changes, shown with another compare tool (Code Compare):

The command prompt looks like this:
vsdiffmerge "J:\AosService\PackagesLocalDirectory\EGDiagnosticsPlatform\EG Diagnostics Platform\AxLabelFile\LabelResources\en-US\EGDiagnosticsPlatform.en-US.label.txt" "H:\External\EGDiagnosticsPlatform.en-US.label.txt" "J:\AosService\PackagesLocalDirectory\EGDiagnosticsPlatform\EG Diagnostics Platform\AxLabelFile\LabelResources\en-US\EGDiagnosticsPlatform.en-US.label.txt" "J:\AosService\PackagesLocalDirectory\EGDiagnosticsPlatform\EG Diagnostics Platform\AxLabelFile\LabelResources\en-US\EGDiagnosticsPlatform.en-US.label.txt" /m

Here it is in the command prompt:

And this is the result:

Note that this way of looking at source vs. target, makes the tool suggest to remove the new labels made in-house while the file has been out for review. This is something you must fix manually.

Not what we want:


Version control

Note how running the tool immediately flagged the label file as a pending change (because we choose it to be the Result file):


If you don't want to have to figure out how to fill the prompt each time do this merge, you could use a PowerShell script like this:

Run PowerShell as Administrator

Go to the location of the script and run it

Enter the location of your internal file and of the external file:

Version with parameters

If you need to merge the same filter repeatedly, you might want another version of the script. If I knew PowerShell better, I'm sure these could be combined, so the script only asks for parameters if they are not given.

The base function

The call of the function

Running it