Add support for the AppSourceCop.json file

[jwikman]

As discussed in the Office Hour, we would like to get support for the AppSourceCop.json file.
You can find docs on that file here: AppSourceCop analyzer - Business Central | Microsoft Learn

In our DevOps solution we updated the version in AppSourceCop.json from our release pipeline to the build that we just shipped. This was committed to the repository. This enabled the breaking changes rules of the AppSourceCop, the compiler emitted warnings directly and the developer had to revert the change (or handle in some other way).

From what I see in AL-Go, breaking changes are only detected in pipelines. And if you have forgot to remove an old skipUpgrade setting from the repo, this is omitted totally 😬.

In the era of Copilot agents, this feature would be very useful - With the warnings from AppSourceCop, Copilot can revert changes right away instead of waiting for feedback from a pipeline run.

[jwikman]

I can do a PR with this, if you think it's a good idea.

I believe that if we enabled this via a new setting, AppSourceCop.json will be updated with the released version in the Create Release workflow and committed to the repository.

Having the previous app available at compile time, will be the responsibility of the developer (and maybe solved by the localDevEnv script? 🙂).

[fvet]

@jwikman Did you make any progress on this topic?

We did customize the update of the AppSourceCop.json upon releasing in Azure Devops / ALOps, and are looking for an alternative in AL-Go.

Off-topic: Would be great if the AL team could include the referenced version from the AppSourceCop.json file as part of the downloaded symbol files. This would make them immediately available in VS Code and warn the dev on breaking changes if AppSourceCop is enabled.

[jwikman]

Hi @fvet,

No, we have not made any progress here. I do miss the AppSourceCop.json now and then, when PR pipelines fails with errors that should have been caught during development.

And your suggestion on auto-downloading previous version symbols is great!

[aholstrup1]

Just catching up to this thread again.

Would an extra step in the "Create Release" workflow that updates the version property of your AppSourceCop files be enough as a starting point? @jwikman / @fvet

[jwikman]

Yes, that would be how I'd expect this to work. 👍
And the version would be the exact build version of the app we are releasing.

[fvet]

That's in fact how we manage it currently. Upon release, update the AppSourceCop with the released build version number.
That would be nice!

---

Follow-up question (more AL related):

As-is

• Up till now, we updated our app versions as part of the release process (versioningStrategy = 3)
  • App.json : version 27.0.1.x (x is replaced by build when compiled by runner)
• Create release : version 27.0.1
  • AppSourceCop.json : version 27.0.1.x (based on the new Create release suggestion)
  • App.json : version 27.0.2.x
• ...

To-be
We're debating internally to no longer manually maintain versions, and use versioningStrategy = 2 instead (yyyyMMdd)
Thus upon release, not committing any version updates.

Doiing so would leave our app.json file untouched

• App.json : version 27.0.0.0

Alternative : we might opt for the Directory.App.Props with a fix app_currentVersion

In this scenario, I'm not sure if the AppSourceCop will properly detect the correct version, as the current app (while developing locally in VS Code / Cursor) would have a lower version (27.0.0.0) than the app referenced by the AppSourceCop (27.0.yyyyMMdd.hhmmss)?