Let’s put an App on AppSource Part #4

The saga continues, another day, another failed submission, this time it’s a BC version issue. If you’re new to this series, the story starts here and continues here.

https://youtu.be/htDSENX97zI


In this fourth installment of the “Let’s Put an App on AppSource” series, Erik walks through a failed certification attempt and demonstrates how to diagnose and fix the issue — specifically a mismatch between the runtime and application settings in the app.json file.

Certification Failed — Now What?

After submitting the app in Part 3 (where marketplace settings and the app name were updated), Erik received a failed certification notification from Microsoft. Opening the app in Partner Center confirmed the failure, with one issue flagged in the validation report.

The good news: the marketplace-related checks all passed. Those tend to be the more difficult ones to resolve. The failure was purely technical — an issue with the app.json configuration.

Diagnosing the Error

The validation report (admittedly not the most readable format) contained the following key information:

  • The validation process detected an issue when validating for version 17.2, country Austria
  • The runtime version of the extension package was set to 7.0
  • The runtime must be set to 6.2 or earlier for the targeted application version

Looking at the app.json file, the runtime was set to 7.0 while the application property was set to 17.0. These two values were out of sync.

Understanding the Root Cause

The application setting in app.json acts as a minimum version requirement. In normal development, as long as you can get symbols that are this version or newer, Visual Studio Code is perfectly happy. You might not even notice a mismatch during local development.

However, when submitting to AppSource, Microsoft’s validation process uses the application setting — not the runtime setting — to determine which version of Business Central to test the app against. If the runtime version is higher than what’s supported by the targeted application version, the validation fails.

The takeaway: for AppSource submissions, the runtime and application settings must be in sync. You can potentially set the application version higher or the runtime version lower, but they need to be compatible with each other.

Applying the Fix

Erik chose to bring the application version up to match the runtime rather than lowering the runtime. He also noted that Microsoft recently changed the default initialization of new app.json files to set the platform to 1.0.0.0.

After updating the settings:

  1. Downloaded fresh symbols to ensure compatibility
  2. Ran a build, producing a new version (version 15) of the app package
  3. Waited for the translation process to complete across all supported languages (Iceland, Norway, Belgium, and many others)
  4. Confirmed the compilation succeeded and the app was signed

Resubmitting to Partner Center

With the fixed app file in hand, Erik updated Partner Center:

  1. Updated the version number to 15 in the app properties
  2. Removed the previous submission (version 13) from the technical configuration
  3. Uploaded the newly built and signed app file
  4. Ran through “Review and Publish” to confirm the updated properties and app file
  5. Hit publish to resubmit for certification

Summary

This episode highlighted an easy-to-miss but critical configuration issue: the runtime and application versions in app.json must be compatible when submitting to AppSource. While Visual Studio Code won’t complain about a mismatch during development, Microsoft’s validation process absolutely will. The fix was straightforward — align the two settings, rebuild, and resubmit. Erik plans to do at least one more part in this series to close out the story, whether the next submission succeeds or surfaces additional issues.