Dynamics 365 Business Central: Changed the default runtime version when it is not explicitly specified in the manifest (app.json)

Dynamics 365 Business Central

Hi, Readers.
Minor update 22.3 for Business Central 2023 release wave 1 has been released last week. More details:Cumulative Update Summary for Microsoft Dynamics 365 Business Central (July, 2023), and what’s new and planned for update 22.3 and AL Language Changelog version 11.5 (AL Release Notes) were also made public together.

One of them caught my attention:

Changed the default runtime version when it is not explicitly specified in the manifest (app.json). It changes from the latest supported by the compiler to the first runtime version of the current major. For BC 2023 release wave 1, since we have already released a compiler version with 11.1 as default runtime version, the default will exceptionally remain as 11.1. However, when runtime 11.2 will be introduced, the default will not change and you will have to explictly sepcify 11.2 if this runtime is required by your app.

https://marketplace.visualstudio.com/items/ms-dynamics-smb.al/changelog

In this post, I would like to briefly talk about this topic.

As you might know, the capabilities and features of AL for Business Central are determined by the runtime version. The runtime version can be specified in the app.json file for a project. It is expressed with the following syntax, for example: “runtime”: “11.0”.

The runtime version specified in the app.json file determines which runtime the project is targeting. An extension can be published to a server with the same or a later runtime version as the runtime version specified in the app.json file of the extension.

Although you need to specify the target platform when you create the new AL project, this setting is not actually mandatory.

More details: JSON files

For example, it is possible to publish an extension without this setting. Because there is a default runtime version.

As mentioned above, Microsoft have already released a compiler version with 11.1 as default runtime version. But here’s a small problem, if the compiler is automatically upgraded, but the environment has not been upgraded, an error similar to the following will appear.

Or

The runtime version of the extension package is currently set to ‘2.0’. The runtime version must be set to ‘1.0’ or earlier in the app.json file in order to install the extension package on this platform.

The solution to it is also very simple, just specify the right “runtime” version (the same or a earlier runtime version).

This update will fix this issue, it changes from the latest supported by the compiler to the first runtime version of the current major. For example, as far as I understand, for Business Central 2023 release wave 2, the default runtime version will always be 12.0. Enjoy this small change!😁

PS: You can find more details in Choosing runtime version in AL
1. Currently available runtime versions: The available options for setting the runtime in AL are:

Runtime versionShipped withInternal version
1.0Business Central April 2018 Release12.0
2.0Business Central Fall ’18 Release13.0
3.0Business Central Spring ’19 Release14.0
4.0Business Central 2019 release wave 215.0
5.0Business Central 2020 release wave 116.0
6.0Business Central 2020 release wave 217.0
6.1Business Central 2020 release wave 2 update 117.1
6.2Business Central 2020 release wave 2 update 217.2
6.3Business Central 2020 release wave 2 update 317.3
6.4Business Central 2020 release wave 2 update 417.4
7.0Business Central 2021 release wave 118.0
7.1Business Central 2021 release wave 1 update 118.1
7.2Business Central 2021 release wave 1 update 218.2
8.0Business Central 2021 release wave 219.0
9.0Business Central 2022 release wave 120.0
9.1Business Central 2022 release wave 1 update 120.1
9.2Business Central 2022 release wave 1 update 220.2
10.0Business Central 2022 release wave 221.0
11.0Business Central 2023 release wave 122.0

2. Setting the runtime version
Selecting the runtime depends on the circumstances. If you, for example, have customers that run on older versions, you should set the runtime to be the minimum version that works to ensure compatibility. This will prevent you from inadvertently using features that are not supported on the older server.
If an earlier runtime is picked, it can be good idea to have a daily or weekly build that tests the extension against the latest version of the runtime. Testing against the latest runtime can detect new diagnostics, such as warnings or errors, that are introduced in the compiler or changes in the platform runtime. Though it may not be possible to refactor code for a future runtime, while using an older runtime, staying on top of these changes may help making design decisions early on.

3. Things to be aware of

  • An error will be thrown when you publish an extension with a higher runtime version than the one that platform supports. For example, if you set the runtime value to 2.0, you get the following error message.
    The runtime version of the extension package is currently set to ‘2.0’. The runtime version must be set to ‘1.0’ or earlier in the app.json file in order to install the extension package on this platform.
  • When you lower the extension runtime version, you may get warnings about the newest features not supported by the earlier versions of the platform.
  • A best-effort compilation is made when you publish an extension compiled with a lower runtime version. This is allowed in order to avoid recompilation of the extension package every time you upgrade the platform.

END

Hope this will help.

Thanks.

ZHU

コメント

Copied title and URL