Dynamics 365 Business Central: I think it’s the time to clean your app.json file

Do you remember this post I wrote lots of time ago?

This post described the new Microsoft’s Application app introduced with Dynamics 365 Business Central version 15.3. This app encapsulates all the dependencies from the System Application and Base Application apps and provides an abstraction to protect AppSource and PTE extensions running on top of that from not being able to resolve dependencies to these apps, maybe if (and when) Microsoft will refactor things.

What does that mean?

That you SHOULD start using the Application app on your extensions for having a benefits of this “abstraction”. What you need to do on all your apps (AppSource or PTE apps) is simply:

  1. Add the "application" property in the app.json file and provide here the minimum Microsoft Base Application version that your app is compatible with.
  2. Remove the direct dependencies to the Base Application and System Application.

Your app.json file should be as following:

Please remember an important thing: what I’ve written in this post is what I’ve always recommended to do an all your apps starting from Dynamics 365 Business Central version 15.3 (who was at my trainings knows that because I normally spend a lot of time emphasizing this), but today this is more than a recommendation, it’s becoming a must!

Soon, all extensions submitted on AppSource must respect this requirement (it will be mandatory for the technical validation step). Please update your app.json file as soon as possible, it’s just a very simple step that can save your life 🙂

4 Comments

  1. Hi Stefano, Does this also apply to the app.json for your test app? do you still have to refer to
    {
    “appId”: “5d86850b-0d76-4eca-bd7b-951ad998e997”,
    “publisher”: “Microsoft”,
    “name”: “Tests-TestLibraries”,
    “version”: “15.0.0.0”
    },
    {
    “appId”: “dd0be2ea-f733-4d65-bb34-a28f4624fb14”,
    “publisher”: “Microsoft”,
    “name”: “Library Assert”,
    “version”: “1.0.0.0”
    },
    {
    “appId”: “23de40a6-dfe8-4f80-80db-d70f83ce8caf”,
    “publisher”: “Microsoft”,
    “name”: “Test Runner”,
    “version”: “1.0.0.0”
    }

    Like

  2. Interesting, so with the previous style of dependencies, you ended up with three files:
    Microsoft_Base Application_17.0.17126.0.app
    Microsoft_System Application_17.0.16993.0.app
    Microsoft_System_17.0.16974.0.app

    And with the new style, you get these three plus:
    Microsoft_Application_17.0.16993.0.app

    Can’t help thinking that if this goes on we’ll get lost in so many layers of undocumented abstraction that it ends up taking longer to find the right entry point for what you want to do than to actually do it. Or we’ll have needless duplication where there are new entry points because it has taken too long to find one that already exists. But apparently that is called “progress”.

    Like

    1. This is a huge benefit if you need to modify the base app or for ha doing future refactoring of the Base App by Microsoft. You can only depend from Application and all other dependencies are transparently inherited.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.