In this video, I look closely at the emails Microsoft is sending out now that v24 is close by. Every 6 months, these emails are both a great help but also the source of a lot of confusion among the receivers. Let’s see if I can help to reduce the confusion. Check out the video:
Every six months, when a new major version of Business Central is on the horizon, Microsoft sends out validation emails to tenants warning about extensions that won’t compile on the upcoming version. In this video, Erik walks through several real examples of these emails, deciphers their sometimes confusing formatting, and explains the common issues you’ll encounter — from obsolete fields to removed pages and missing codeunits.
The Semi-Annual Email from Microsoft
Microsoft provides a genuinely valuable service: before each major version release, they go through every single tenant, check all installed extensions, and attempt to compile them against the next version. If an extension fails to compile, they send an email to the recipients configured in the Admin Center. This is a great proactive measure — but the emails themselves can be confusing and hard to read.
The Version Number Confusion
The first thing that trips people up is the subject line itself. You’ll see something like:
“Modify your extension so it’s compatible with the version 24.1.17188.0”
If your tenant is currently on version 23.4 or 23.5, and you know that 24.0 is coming, this creates immediate confusion. Does this mean you can safely upgrade to 24.0 but not 24.1? Or is this actually a warning that your extension won’t work starting with 24.0 at all? The distinction matters because it determines whether you have a burning platform right now or one that’s slightly further out. Erik invites Microsoft to clarify this distinction, as it’s genuinely ambiguous from the email alone.
Reading the Validation Results
The email contains an “Extension Validation Result” section — though Erik notes that some variations of the email are missing this section entirely, which isn’t helpful. When present, the validation results are formatted as a single block of text with no clear separation between individual errors. You have to carefully read through to identify where one issue ends and the next begins.
Example 1: Obsolete Fields
The first example shows an app with two issues, both in a data conversion file called import bank statement lines.al. The error indicates that a Type field has been removed, with the obsolete reason stating: “This field is prone to confusion and is redundant.”
This is a common scenario — a field that was used during an initial data conversion (migrating bank statements from an old system to BC) references something that’s been made obsolete. The fix is often straightforward: since the data conversion has already run, the code referencing the obsolete field can likely just be removed.
An interesting side note: whatever message you put in the ObsoleteReason property of a field ends up in these emails. So when you obsolete your own objects, make sure the message is actually instructional and helpful to whoever reads it later.
Example 2: Missing Codeunit
The second example shows the error: “Codeunit O365 Sales Invoice Management is missing.” You’ll also notice that spaces in names appear as %20 — this is URL encoding, where %20 is the hexadecimal representation of ASCII character 32 (the space character).
This is a typical issue that arises when you’ve made a copy of a base object. Before report extensions existed (or for reports that were hard to extend), developers would copy the base object. Then Microsoft changes the underlying codeunit — they fix their own invoice report, but your copy still references the old codeunit. You’ll need to update your copy to reference whatever replaced it.
Example 3: Removed Email Fields on API Pages
The third example is almost readable thanks to fortunate formatting. It shows four identical errors on an API page for Sales Invoices:
Last Email Sent Time— not foundLast Email Sent Status— not foundSent as Email— not foundLast Email Notif Cleared— not found
The old email-related fields on the Sales Invoice Header have been removed after being obsolete for several versions. If you included these fields on an API page (perhaps ignoring the compiler warnings about obsolete fields), they’re now gone entirely. The fix is to regenerate the extension and remove references to those fields.
Example 4: Removed or Non-Extensible Pages
The fourth example comes from an app that extends pages which no longer exist. The error reads: “The target page 3213/2313 for the extension object is not found.”
This happens when Microsoft removes pages, marks them as non-extensible, or moves functionality around as part of housekeeping. These pages worked fine in version 23 but are gone in version 24. You’ll need to find the replacement pages (if any) and update your extension objects accordingly.
How to Deploy Fixes for the Next Version
If your extension works fine on the current version but needs changes for the next version, you don’t have to wait. When deploying through Extension Management, you can specify whether the app is for the current version, the next minor, or the next major. This lets you upload a fixed version that will sit and wait until the upgrade happens.
One caveat Erik mentions: uploading an app targeted at the next major version has historically prevented you from updating the app on the current version. So it’s best to do this close to the upgrade window to avoid any interruptions to your current deployment workflow.
A Note on Extension Setup
For reference, here’s an example of a typical app.json configuration for a Business Central extension:
{
"id": "b419d778-fcf5-45ee-9914-64b957f65f8c",
"name": "BC Chess",
"publisher": "Hougaard.com",
"version": "1.0.0.0",
"dependencies": [],
"platform": "17.0.0.0",
"application": "17.0.0.0",
"idRanges": [
{
"from": 57300,
"to": 57349
}
],
"showMyCode": true,
"runtime": "6.0"
}When preparing for a major version upgrade, you’ll likely need to update the platform, application, and runtime values to match the target version, then address any compilation errors that arise — exactly the kinds of errors these Microsoft emails are warning you about.
Conclusion
The validation emails from Microsoft are genuinely helpful — they tell you exactly what will break before it breaks. The challenge is that the formatting makes them difficult to parse: errors run together without line breaks, spaces appear as %20, and the version numbering in the subject line creates unnecessary confusion. The common issues you’ll encounter are:
- Obsolete fields finally removed — fields you were warned about are now gone
- Missing codeunits or objects — base objects you copied have been replaced
- Removed or non-extensible pages — pages you extended no longer exist
- API pages referencing removed fields — fields included on API surfaces that are no longer available
Regardless of whether the email says 24.0 or 24.1, you need to fix these issues. Don’t ignore the warnings, and when you obsolete your own fields and objects, write clear, instructional obsolete messages — they’ll end up in someone else’s email someday.
