AS0084: ID Range Error for client extensions

[MBK75]

Hello, just this morning we started receiving compiler errors for client extensions as follows:

error AS0084: The ID range '[60000..60011]' is not valid. It must be within the range allocated to the partner for AppSource, within the range '[1000000..75999999]' allocated to AppSource applications, and outside the range '[50000..99999]' allocated to per-tenant customizations.

I built one extension twice this morning with no problem; upon trying to build it the third time (after a small change), I received this error. Another developer on another project has reported the same problem. Is there a new undocumented setting?

[MBK75]

For what it is worth, the compiler points to the app.json file as the error

[DParkerRSM]

I have now run into the same issue with all my custom code. I have the following in the app.json which has worked until tonight. I really hope this is another weird error that disappears tomorrow. "idRanges": [ { "from": 63700, "to": 63799 } ],

[MBK75]

We ended up installing the prior version of the AL Language VSIX (under the gear in the extension list) and it worked

[DParkerRSM]

Could you let me know which VSIX extension you installed? Did you uninstall anything?

[DParkerRSM]

I found a viable answer it seems. I updated the rule set to ignore this error and it worked as usual.

[MBK75]

I installed the next prior version. From the drop list, you can see the versions in descending order by date. I will post when I am in front of my computer

[MBK75]

v5.0.329509

[qutreson]

We have introduced a new AppSourceCop rule (AS0084) that validates that the ID range specified in the manifest is within the object range reserved for AppSource extensions. You can read more about it here: Object Ranges in Dynamics 365 Business Central.

As mentioned in our documentation, the "AppSourceCop is an analyzer that enforces rules that must be respected by extensions meant to be published to Microsoft AppSource.".

If your extension does not target AppSource, but you sill want to benefit from the AppSourceCop rules, then you will have to suppress the rules that don't apply for your extension using rulesets. You can read more about them here: Using the Code Analysis Tools with the Ruleset.

[johndcollins]

It would be great if you could give us all a heads up when you make changes like this. We have several developers stuck most of the day because of this error, not able to deploy code to customers.

[atoader]

@johndcollins could you share more about your internal development process? I'm guessing that the apps in question were not meant for AppSource and I'm wondering how people are using AppSourceCop for non-AppSource scenarios.

[jeffreypoen]

To ignore this issue you can add a rule;

Filename: ignore.ruleset.json { "name": "Ignore ID Range Error", "description": "These rules must be respected by all the AL code written within the company.", "rules": [ { "id": "AS0084", "action": "None", "justification": "Ignore ID Range Error" } ] }

Then add the al.ruleSetPath (VS Workspace settings) { .. "settings": { ... "al.ruleSetPath": "ignore.ruleset.json" }

}

[MBK75]

We want our developers to write code that is up to App Source standards and which has some organization and is standardized. AppSourceCop is great for this. Thus, I discourage things like side-stepping errors through ignoring them in a ruleset file.

Thus, it does not make sense to me to make an ID range a compiler error and limits this nice feature (albeit slightly) for us. What would be a better solution is if the compiler could simply tell if it is an App Source extension by the ID range in the app.json file. That would make way more sense to me.

On a side note, is the "record must be modified before saving to the database" rule going to be fixed any time soon? That one has been around for months now

[jeffreypoen]

We want our developers to write code that is up to App Source standards and which has some organization and is standardized. AppSourceCop is great for this. Thus, I discourage things like side-stepping errors through ignoring them in a ruleset file.

Thus, it does not make sense to me to make an ID range a compiler error and limits this nice feature (albeit slightly) for us. What would be a better solution is if the compiler could simply tell if it is an App Source extension by the ID range in the app.json file. That would make way more sense to me.

On a side note, is the "record must be modified before saving to the database" rule going to be fixed any time soon? That one has been around for months now

I agree to follow the standards, even for on-prem extensions. The AppSourceCop works nice. Maybe it's possible that such validation changes triggers a notice/warning first, resulting an error message in a feature release?