If someone of you has installed or upgraded a Dynamics 365 Business Central database instances with the new 15.3 version, I think that you could have noted that a new Microsoft extension is appeared on the Extensions Management page:
What is this Microsoft Application app?
This is a nice trick that Microsoft has done to solve a noisy problem that you could have if you modify the Base Application for the on-premise database. I’ve talked about this problem here in the past. If you modify the Microsoft Base Application and you change the appId or the name or the publisher, you break all the standard extension’s that depends from the Base Application.
To permit this, Microsoft has silently introduced the Microsoft_Application.app file. This app is nothing magic, it’s just an empty app that acts like a “proxy” and it’s defined as follows:
As you can see, this app has dependencies from the Microsoft’s System Application and Base Application (as every standard AL extension). Then, it has the propagateDependencies property set to TRUE. This property specifies whether the dependencies of this project should be propagated as direct dependencies of projects that depend on this one.
What does it mean for you now? With this new “proxy app” you can now create a new extension with the following app.json file:
As you can see, in my new extension here I have only a dependency from the new Microsoft Application extension. When you download symbols, also symbols from the Base Application are downloaded automatically:
You could now customize the Base Application to suite your needs and you could also change the app’s details (publisher and so on). If you do so, you need to change the references to the app.json file in the new Application app and nothing more. All other extensions will work again.
Embed partners and on-premises solutions can create a parent extension named Application, versioned according to base version, and with an appropriate, unique publisher. This parent extension is mainly used as an indirection proxy, and should contain explicit dependencies to the extensions actually implementing the application. In addition, the propagateDependencies property in the app.json file should be set to true. This will expose the dependencies to any extension taking dependency on the proxy Application version.
Please remember that an explicit dependency to Microsoft’s Base Application will take priority over the Application version, but is redirected to “application” if the Base Application is not present on the system.
I think we’ll see more about this later with version 16. Stay tuned…
We can just have empty “dependencies” and “application”: “184.108.40.206” in app.json. Like in MS apps. a-la _D365BC_15_Fall2019_W1_40822_15.3\Applications\EssentialBusinessHeadlines\Source
LikeLiked by 1 person
Hi @Stefano Demiliani , can you advise on this.
I am connected to sandbox via VS Code and publish the package directly from VS Code not by extension management . currently my vs code,.al packages contain all v15.x version and but the sandbox webclient update to v16.x . what steps to follow to update v16.x in my vs code alpackages.? how should i point my extension to new alpackages. pls advise.
Download symbols from your sandbox via VS Code and you will have V16 symbols.
The following warning and it’s about 400 + similar warning messages where every option type field used.
An implicit conversion is being performed from a value of type ‘Enum “Gen. Journal Document Type”‘ to a value of type ‘Integer’. This conversion can lead to unexpected runtime issues. This warning will become an error in a future release.AL(AL0603) #5832
should we manually replace by appending **.AsInteger()** at the end. or any other way to replace at one-go ? or any other solution . thanks.
If you have custom tables with option fields and assign to this option field the enum standard field, it throws a warning. As first step you can discard the warning or fix it in different ways (AsInteger, Evaluate, changing options to enums)
Noted. Thank you very much .