New resources available on Microsoft Learn
Did you know that Microsoft Learn offers free training modules to assist you on your path to mastering Dynamics 365 for Finance and Operations? Become an expert at your own pace or share with your team to foster growth.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
We have an AX 2012 R3 modelstore that went through the upgrade to 8.0 and there are a whole bunch of overlayering. We are trying to use reflection to identify programmatically that which standard AX methods exist in a package that is customized by us.
I only have been able to pull such information on a class or table level, but have been unable to pull details on method content.
Let's have an example, we have changed \Classes\Application object by modifying the dbSynchronize, logInsert, logDelete, logUpdate methods, and added a couple of new methods on our own.
If I use the Metadata Search tool with the search string as per below, it does return all methods from the Application class incorrectly, because the object itself is marked as being in both ApplicationPlatform, and our custom JAD package as well:
Here is the piece of code we currently have in a C# project. It can display that which packages does the parent table belong to, and we check the names of the methods within the table if it contains our prefix of JAD. However those will not reveal standard methods overlayered. How would we get those listed as well?
TreeNode is deprecated, the metadata providers do not have method-level inspection as far as I can tell, and DictMethod also does not reveal package information.
Any ideas please?
static void Main(string args)
var environment = Microsoft.Dynamics.ApplicationPlatform.Environment.EnvironmentFactory.GetApplicationEnvironment();
var packagesLocalDirectory = environment.Aos.PackageDirectory;
IMetadataProvider diskMetadataProvider = new MetadataProviderFactory().CreateDiskProvider(packagesLocalDirectory);
var l = diskMetadataProvider.Tables.ListObjects("ApplicationPlatform");
var le = l.GetEnumerator();
AxTable t = diskMetadataProvider.Tables.Read(le.Current);
var mi = DesignMetaModelService.Instance.CurrentMetadataProvider.Tables.GetModelInfo(t.Name);
Console.Write("Table " + t.Name + " models: ");
for (int j = 0; mi != null && j < mi.Count; j++)
var bla = mi.ElementAt<ModelInfo>(j);
Console.Write(bla.Name + " ");
Microsoft.Dynamics.AX.Metadata.Core.Collections.IKeyedObjectCollection sen = t.Methods;
for (int i = 0; sen != null && i < sen.Count; i++)
Microsoft.Dynamics.AX.Metadata.MetaModel.AxMethod method = (Microsoft.Dynamics.AX.Metadata.MetaModel.AxMethod)sen.getObject(i);
Console.WriteLine("\\Data Dictionary\\Tables\\" + t.Name + "\\Methods\\" + method.Name /*+ treeNode.AOTLayers().toString()*/);
Console.WriteLine("------- Press any key -------");
considering overlayering is in separate files in Delta folders, you could just go directly against the XMLs. This is effectively what the metadata providers do as well, and was assuming there's a way to do this with the metadata API. But barring that, the raw XMLs have the data.
When I open the Delta XML file for our ApplicationPlatform.JAD\AxClass\Delta\Application.XML, the VS UI does that already for us directly by showing it as if it would be the AOT, highlighting the conflicts and the automerged overlayering, so it has been coded somewhere.
It would be great if we could somehow use the same logic via reflection either by getting a list of the packages on a method, or at least a flag like isOverlayered.
I have tried pulling in a bunch of assemblies and searching for something useful in the object explorer without much luck, and decompiling the VS extension for D365 would be a pain.
If you could pull out something readily available or put this requirement in the pipeline, that would be great.
Manually inspecting a thousand methods is not optimal :) Our goal with this is to identify which methods are overlayered with a conlict, and then automagically inspect whether the code is at the beginning/end of the method (so it could be moved to an extension), or it might need a method hook for extensibility which we could send in as a support request.
We have been able to get it done using a different approach, with BaseX tool through XQuery/XParth for the Delta folder.
I'll make a post about it tomorrow for anyone interested!
Business Applications communities