D365 Business Central : Use AppSourceCop to Detect Breaking Changes

When developing the D365 Business Central App Source extension, we are required to comply with AppSource rules. To ensure our extension meets these standards, the AppSourceCop Analyser is a valuable tool. AppSourceCop Analyser is an analyser that enforces rules that must be respected by extensions meant to be published to Microsoft AppSource. Failing to comply with the rules whose default severity is set to Error will fail the submission of your extension to the AppSource marketplace.

Among its features, AppSourceCop can help identify potential breaking changes, such as modification to fields or primary key.

In this article, we will set up AppSourceCop to detect these breaking changes effectively.

Creating a Sample App for Testing

To start, let’s create a simple app. Starting at version 1.0.0.0, we introduce a new table called “My App Source_TNG”. Our goal is to trigger a breaking change by modifying the Description field length in the next version.

Create new table

Enable AppSourceCop

We can start by enabling AppSourceCop. We do this by creating an AppSourceCop.json file in the workspace root and specifying the ${AppSourceCop} in our setting file.

Specify ${AppSourceCop} in setting file
Create AppSourceCop.json

Configuring AppSourceCop for Breaking Change Detection

Four settings are related to detecting Breaking Changes: name, publisher, version, and baselinePackageCachePath.

{
    "name": "ExtensionName",
    "publisher": "ExtensionPublisher",
    "version": "1.1.0.0",
    "baselinePackageCachePath": "./.appSourceCopPackages"
}

Define the baseline version of the extension against which breaking changes will be compared. By utilising the “version” property within your “AppSourceCop.json” file, we pinpoint the exact version for comparison. The “name” and “publisher” properties aren’t necessary in this context.

The “baselinePackageCachePath” property allows us to designate a folder that will serve as a cache for the baseline package and its dependencies for the AppSourceCop analyser. This step is crucial to ensure that the previous version of the extension is loaded correctly, along with its dependencies. If not explicitly set, the baseline and its dependencies will be assumed to reside in the default dependency package cache path. To avoid confusion, setting the “baselinePackageCachePath” property is recommended, particularly if we’re working with multiple projects in a Visual Studio Code workspace.

Let’s proceed by specifying the version in our “AppSourceCop.json”.

{
    "mandatoryAffixes": ["TNG"],
    "version": "1.0.0.0"
}

*Note: the ‘mandatorySuffix’, ‘mandatoryPrefix’, or ‘mandatoryAffixes’ property is required for AppSource extensions.

Next is to place our baseline app in the designated folder.

Place app file in the designated folder

Triggering the Breaking Change

We are ready to test the AppSourceCop validation. Let’s modify the Description field length from 50 to 30.

Error AS0080: Field ‘Description’ has changed

We can see that the AppSourceCop gives the error AS0080.

By using AppSourceCop to detect breaking changes effectively, you can ensure that your extensions remain compliant across versions. Remember to accurately specify the baseline version and cache paths to avoid hiccups during detection.

thatnavguy

Experienced NZ-based NAV Developer and Consultant with 15+ years of experience leading multiple IT projects, performing business analyst, developing, implementing, and upgrading Dynamics NAV and Business Central. Passionate to deliver solution that focuses on user-friendly interface while keeping high standard of compliance with the needs.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *