The Microsoft Dynamics Application Checker is an excellent tool, which utilizes the BaseX XML-parsing software. Since all our objects and source code for Microsoft Dynamics 365 are represented as XML files, this presents an excellent opportunity to do XPath parsing. As a prerequisite for the software first, before you could include it in your build routine. We have seen an App Checker BaseX error like this:
Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Invalid maximum heap size: -Xmx15000m The specified size exceeds the maximum representable size.
When you deploy BaseX, it is recommended to increase the usable memory size in order to fit the entire Dynamics repository. Increasing the memory usage can result in the above error message. The solution is to deploy the 64-bit Java Runtime Environment, which makes the App Checker BaseX error disapper.
When you build your code, the results are hard to interpret and are being capped at 1000 entries per category within the Visual Studio error pane. The compiler does generate output files with more valuable content within each package. We have written PowerShell code for analyzing and interpreting compiler results of Microsoft Dynamics 365 for Finance and Operations in a more meaningful way.
The BuildModelResult.LOG and XML files have the details of your errors, warnings and tasks. Running the following script parses these files and counts the warnings and errors, to get a better idea of the remaining work during your implementation and upgrade:
The compiler results are displayed in the following format as an overview:
If you want to do a detailed analysis, we also have PowerShell scripts prepared for extracting the errors and saving them in a CSV file for better processing. Opening it with Excel allows you to format them into a table.
We typically copy all error texts to a new sheet, run the duplicate entries removal, then do a count on what is the top ranking error to see if we have any low-hanging fruits to be fixed.
We are preparing for the code upgrade from AX 2012 R3 to D365FO 8.1, the latest version recently released. As you know it is extensions-only, meaning we are not allowed to modify any of the standard objects directly. I would strongly suggest to familiarize yourself with Extensions if you are planning to go down this journey as well. An important part of this is that you need to send in Extensibility requests via LifeCycle Services, for code that cannot be moved to a pre- / post-event handler. Our large number of customized methods came out well above 1000+ overlayered objects when we ran the LCS code upgrade tool on our modelstore. We had to find standard code overlayering of all methods to narrow down the search on what should be inspected for extensibility.
I have been exploring the options to use the MetaData API for extracting package information of methods. We wanted to find any methods, which belongs to both a standard, and a custom package, like ApplicationPlatfrom and ApplicationPlatform.JAD (our module). That did not lead to anything useful other than realizing that you can only access such details up to the root node level (table, class) currently. Here is the code piece for partial results: