Starting with our own code before a version update

Hello, in this article I will walk through an example of how we can use AI during Dynamics 365 version updates. When a new version arrives, are our customizations affected, where might issues arise, and which operations should we test? I wanted to look for answers to these questions in the code.

I have Microsoft packages for two different builds on my development machine. Each contains more than 170 packages and tens of thousands of objects. Rather than looking at all of them, I first identified where our own model connects to the standard code and compared the relevant objects.

I used Claude Code for this work. I asked it to prepare the comparison script, review the changed code together with our customization, and explain the impact. The check took a few minutes for this model.

Here, I am looking at customizations on the shared X++ and metadata infrastructure of Finance, Supply Chain Management, Commerce, and Human Resources. The results I am sharing come from code review. I have not yet compiled against the new version or run application tests.

The two builds I compared

The packages for the following two builds were already on the machine where I work with UDE. I used these folders for the comparison:

%LOCALAPPDATA%\Microsoft\Dynamics365\10.0.2527.116\PackagesLocalDirectory   (current)
%LOCALAPPDATA%\Microsoft\Dynamics365\10.0.2645.99\PackagesLocalDirectory    (new)

My own models are in a separate metadata folder. For this example, I used the test model I developed for enforcement proceedings. Since the packages I needed were already on the machine, I did not have to install an additional tool or download any packages.

Let’s look at our own model first

First, I asked Claude Code to list where our model connects to Microsoft code. Which methods do we use through CoC, which tables and forms do we extend, and which standard classes do we call? I will refer to these as touchpoints throughout the article. The list came out as follows:

Table 1. Where our model connects to Microsoft code

This brought the number of Microsoft objects we needed to look at down to 14. We also compared the package lists. Five packages had been added and one removed in the new build. The removed package was not among our model’s direct references. At first glance, there did not seem to be an issue here; I will check the compilation side of the dependencies separately.

What has changed in these objects

We then compared the XML files for these 14 objects between the two builds. We looked at methods in tables and classes, and controls in forms. The result was as follows:

Table 2. Comparison results

LedgerJournalCheckPost was the first thing that caught my attention here. Our service for creating enforcement records posts the journal using this class. When I saw that the class’s posting methods had changed, I wanted to look here first.

Does the changed code run in our operation

The class has changed, so what happens in the flow we use? I asked it to review the differences together with our own code. What condition had been added, and does our operation meet that condition? That was what I really wanted to look at.

The change in LedgerJournalCheckPost

The newLedgerJournalTable and processOperation methods that we call directly were unchanged. We did not stop there; we also looked at the posting flow that follows. The relevant part of the checks added to the postJournalLines and checkJournalStatus methods is as follows:

if (ledgerJournalTrans.AccountType == LedgerJournalACType::Vend
&& LedgerJournalTrans::isVendorInvoice(ledgerJournalTrans))
{
…
if (ledgerJournalTableForValidation.JournalType
== LedgerJournalType::VendInvoiceRegister)
{
allOK = allOK
&& this.validateEstablishment(…)
&& this.validateVendorShipFromAddress(…)
&& this.validateRegistrationIds(…);
}
}

These checks run for vendor lines in vendor invoice register journals. Our enforcement journal, on the other hand, is a general journal consisting of customer and ledger account lines. Therefore, our operation does not enter this condition. The other change in the postJournal method was related to India-specific tax code.

We did not see a need to change our enforcement code for these changes we reviewed. If we had only compared the files, all we would have known was that “the posting class has changed.” Looking at the conditions under which the code runs helped us understand its relationship to our operation.

The situation with the other objects

In the CustTable table, an Italy-specific feature flag had been removed from the FiscalCode field. The validateWrite method that we wrap with CoC, and the find and name methods that we use, were unchanged. We found no differences affecting our code in the areas we looked at.

Two invoice-related parameter fields had been added to the CustParameters table, and four controls had been added to the form. We add our enforcement fields to the General tab. The GeneralFastTab and GeneralTabPage controls we attach to were still in place. Since the new controls were on other tabs, they did not conflict with our layout.

A new item had also been added to the OrganizationAdministration menu. This addition did not affect the placement of our menu extension.

What was the result and what will I test

Table 3. Impact assessment

Nine of the 14 objects were unchanged, and five had changed. Among the changed objects, we did not find anything requiring a code fix for the enforcement scenario we reviewed. We now need to verify this assessment in the new version. I will test the following operations first:

Creating an enforcement record and posting the journal. Since the posting class has changed, I will check that the operation completes with customer and ledger account lines.

Creating a new customer and editing an existing customer. I will check that the custom validation on CustTable works as expected with data that meets the rule and data that does not.

Checking the enforcement fields in Accounts receivable parameters. Are the fields in the right place, can the values be changed, and do the same values appear when the form is reopened after saving?

This list makes it clear which tests we are prioritizing and why. The project’s critical regression tests will also continue. The check we performed here shows us where to start testing our own customization.

Conclusion and next step

This work was an experiment I carried out on a small model. The changes we reviewed did not reveal a need for a fix in our own scenario. In a real project, however, we may encounter changes affecting hundreds of objects and situations where they conflict with our customizations. Reading the differences one by one and assessing their impact at that scale would take much more time.

I think this is where AI can help. By reviewing the changes together with our own code, we can identify potential issues earlier and decide where to start with fixes and testing. Of course, we also need to assess standard processes, parameters, data, and Feature management changes separately.

My next step will be to compile the model against the target build and run the tests we identified in a sandbox environment on the new version. I also want to repeat this experiment on a larger model and share the issues and results.

Best regards,
Fatih Demirci

The prompts I used for anyone who wants to try it

1 Touchpoints in our own model

List every place where our model DMRAITests touches Microsoft code: Chain of Command classes and the methods they wrap, table, form, menu and security extensions, data entities, and the Microsoft classes and methods our code calls. Show the result as a table.

2 Comparing packages

Compare the package lists of the two builds under %LOCALAPPDATA%\Microsoft\Dynamics365 (10.0.2527.116 and 10.0.2645.99). Which packages were added or removed, and does our model reference any of them?

3 Differences at the touchpoints

For each Microsoft object in the touchpoint list, compare its XML between the two builds. Report which objects are identical and which changed. For changed classes and tables, list added, removed and changed methods and fields; for forms, list added and removed controls. Tell me explicitly whether the methods we call or wrap changed.

4 The impact of the change on our own code

For every changed object, read the diff together with our code and decide whether it actually affects us. Show the relevant Microsoft code and explain under which conditions the new logic runs.

5 Form attachment points

Check that every control our form extensions attach to (parent or previous sibling) still exists in the new build.

6 Results and test list

Summarize the result as three groups: unchanged, changed but no direct impact identified in the reviewed scenario, changed with impact. Then give a short, prioritized test list for this upgrade and say why each test is on it.

7 Compiling against the new build

I have not run this last command yet. I will use it during the compilation step to compare the results for the current and target builds.

Compile DMRAITests with xppc against the 10.0.2645.99 packages and list any errors or warnings that do not appear when compiling against 10.0.2527.116.