Dynamics 365 Business Central: checking for breaking changes on obsoleted, internal and OnPrem objects.

When creating AL extensions for Dynamics 365 Business Central, you could have one (or more than one) of the following situations:

1. You can have obsoleted objects.
2. You can have objects marked as Internal.
3. You can also have methods decored with the Scope(‘OnPrem’)] attribute (I hope no ).

The AL language extension permits you to use different code analyzers to check your code before releasing an extension. The AppSourceCop analyzer is a code analyzer that enforces rules that must be respected by extensions meant to be published to Microsoft AppSource (and it’s mandatory to be used before releasing an app to the Marketplace).

When checking technical validation for AppSource, the AppSourceCop analyzer can be configured by adding a file named AppSourceCop.json in the project’s root folder, and here you can specify parameters for your code validations. One of the most important parameters in this file is the version parameter, that permits you to specify the version of a previous version of this package with which you want to compare the current package for breaking changes (in more simple words, I want to release version N+1 of my extension and I want to detect breaking changes with version N currently released on the marketplace).

What happens in these cases?

Imagine that in the release N of your extension, you have obsoleted a procedure like in the following example (the procedure has changed its parameters):

Now, before releasing the new version N+1 of your extension on the marketplace, a developer changes the signature of the obsoleted procedure (don’t ask me why someone should do this):

This type of change is not detected by the AppSource technical validation!

The same is for Internal procedures. Imagine to have the following code in your published extension:

and a crazy developer changes the signature of the internal procedure in the next version:

Again, this type of breaking change is not detected by the AppSource technical validation!

The same is for procedures decored with Scope(‘OnPrem’)] ():

If a crazy developer changes the signature of this procedure:

this type of breaking change is not detected by the AppSource technical validation!

By default, all these objects are not validated by AppSourceCop nor by the AppSource technical validation process. 

What can I do to detect those changes?

In the current AL language extension, Microsoft added new AppSourceCop configuration settings enabling validation of breaking changes on objects which are marked as Obsolete, marked with Internal accessibility or marked with Scope(‘OnPrem’)].

The new settings are the followings:

• validateObsoleteSymbols: specifies whether the breaking change validation should be enabled on symbols which are obsolete in the baseline. By default, the validation of breaking changes allows breaking change done on symbols which are obsolete in the baseline (except for schema breaking change validation which is always performed).
• validateInternalSymbols: specifies whether the breaking change validation should be enabled on internal symbols. By default, the validation of breaking changes is performed only on symbols that are part of the public API (except for schema breaking change validation which is always performed).
• validateOnPremSymbols: specifies whether the breaking change validation should be enabled on symbols with Scope(‘OnPrem’)]. By default, the validation of breaking changes is generally performed only on symbols with the default Scope(‘Cloud’)] (except for schema breaking change validation which is always performed).

To detect those changes in your AL code validation, you need to add the previously explained parameters to the AppSourceCop.json file:

This is important, expecially for Internals symbols. Remember that you could have extensions with the internalsVisibleTo property in use (see here for more informations) and not detecting those changes could cause breaking changes in your code (quite often really difficult to discover).

The internalsVisibleTo in the app.json file property permits you to specify a list of extensions that can access internal objects declared in the current extension:

In the above example, objects and procedures declared as internal in APP_A are visible also to APP_B and APP_C. If someone for example changes the signature of an internal procedure declared in APP_A, you could break code in APP_B or APP_C (that maybe can use the internal event from APP_A). Be careful on that, because AppSource validation is not checking for those problems…

Original Post https://demiliani.com/2025/07/22/dynamics-365-business-central-checking-for-breaking-changes-on-obsoleted-internal-and-onprem-objects/