The ID for the Field is not valid. It should be withing the range which is allocated to the application. (v13.0.937154 (pre-release))

[ptrk-tr]

1. Describe the bug After updating to the newest pre-release version of the AL extension (v13.0.937154 (pre-release)) the compiler/code cop throws warnings (PTE0022) on field IDs in our table extensions that are not withing the specified object ID range in the app.json (in this case we put FlowFields with ID >= 60000, while the app.json specifies a max. ID of 50699). This warning wasn't there in the previous AL version (pre-release) and is not present in v12.5.914975.

Is this something we actually have to look at or is this warning not meant to be thrown? I at least am not aware that field IDs have to match the specified object ID range.

2. To Reproduce Specify a valid ID range in the app.json, then create a field in a table extension with an ID outside the range of what was specified in the app.json.

3. Expected behavior No warning is thrown as fields are not objects in license terms.

4. Actual behavior Code cop throws PTE0022 on fields that are not within the specified ID range from the app.json.

5. Versions:

• AL Language: v13.0.937154 (pre-release)
• Visual Studio Code: 1.86.0
• Business Central: DE Business Central 23.1 (Platform 23.0.13804.0 + Application 23.1.13431.13812)
• List of Visual Studio Code extensions that you have installed:

[EmilDamsbo]

Hello, yes this is a new requirement as it is generally bad practice to use field IDs outside your defined ID ranges, as was pointed out by this issue: https://github.com/microsoft/AL/issues/7547

For a while we have had rules in AppSourceCop that does a similar job for the AppSource object ID range: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/analyzers/appsourcecop-as0013 https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/analyzers/appsourcecop-as0099

As the new PTE0022 and PTE0023 rules are both in pre-release, the documentation has not yet been updated with guidance on how to act on them. We invite you to share your perspective on the new rules so we might improve them if necessary.

[ptrk-tr]

While I agree that the rule in itself makes sense, I don't find it useful for the ID range 50.000 - 99.999 which is reserved for customizations. I assume extensions that use this ID range will only ever be developed for, and installed in one specific customers environment, so ID clashes with existing objects would most likely be apparent while developing these customizations as they'd be developed against these customers symbols.

As a general question, what is the best practice to put into the app.json for the valid ID range if I develop in the 50.000 - 99.999 range?

Last time I checked I could publish extensions with objects defined outside the license but within the specified valid object ID in the app.json, which then made problems as they couldn't be used at runtime, so I specified the valid ID range in the app.json to what the license allows me to do.

Asking because, theoretically I could be a small company with a license only including the ID range of 50.000 - 50.005 because generally I only need a couple of objects for customization, with the new rule I could also only add 5 fields into a table extension (if I specify the valid ID range in the app.json to my license object ID range).

So if I see this correctly I have three options:

1) Define the valid ID range in the app.json to 50k-99.9k and run into the danger of publishing an extension including objects outside the valid ID range of my license.

2) Define the valid ID range to just cover my license and then potentially be bound to restrict the number of fields in my table extensions to the valid range.

3) Ignore the warning in the code cop and hope it won't turn into an error eventually.

What would be the best approach in this case?

[dannoe]

Just a note: The license problem only exists on-premises, because in the cloud you can use all objects in the range 50000..99999 for free in PTEs.