You’re offline. This is a read only version of the page.
The following slide, presented during Directions EMEA 2020 Virtual event in October 2020, clarify the potential compatibility issue that might arise when deploying a runtime package within an application and platform (destination environment) different than the one it has been created (source environment).
Runtime packages are officially documented here:
and they are supported for On-Premises deployment only and they are widely used because of:
These are the reasons why they are so widely used but they have a strong dependency on the cumulative update (CU) they are created (highlighted by the sentence “tied to the compiler version and extension graph present on the server compiled”).
In practical terms, the runtime package will surely be deployed successfully and work as intended in environments that shares the same CU level, both application and platform.
Deploying the runtime package in a later or earlier major version or even CU would work as expected as well, if the destination environment respects the same structure.
What does it mean, then, respecting the same structure, in technical terms:
Compiler might have been enhanced within different major and, sometimes, minor versions. To give an example, that happened when application parameter has been added as validation source through a proxy extension (Application.app) instead of declaring dependencies directly in the app.json manifest file.
When these changes would happen, Dynamics 365 Business Central Modern Development team should capture changes in the VSIX marketplace changelog.
These might happen, again, in major versions and, more rarely, in minor versions. If and when this would happen, Dynamics 365 Business Central Application team is supposed to document it within major or minor release notes in the Knowledge Base (KB) articles.
This part is outside the control of Microsoft. E.g. an On-Premises ISV solution impacting a Per Tenant Extension (PTE) is outside the influence of Microsoft and should be handled accordingly by the maintaining ISV.
What is reported above, is highlighted in the official documentation through this note:
To reduce this risk and notify ISV, resellers and customer, about a different runtime version (mismatch) between source and destination – as stated in the last point of the slide – a warning message has been introduced starting from CU 16.7 and onwards.
The warning message is thrown when publishing a runtime package that has a different destination environment from its generating source.
Below an example of the aforementioned warning.
The best practice with runtime packages, then, is always to test and re-generate the runtime package using the same major and minor version (CU level) of the destination environment.
Thank you Duilio for sharing.
#1
Sohail Ahmed
2,669
Super User 2025 Season 2
#2
Sumit Singh
2,668
#3
Jeffrey Bulanadi
2,203
Share
Report
All responses (
Answers (
