More than an year ago I wrote this article for Simplanova website mentioning some “architectural choices” when moving a C/AL solution to the extension model.
One of the ideas mentioned here was to create an “hidden layer” that can contain common business logic and objects and then create N separated extensions on top of this layer. This permits you to “share” common logic between extensions and to reduce dependencies:
You can see what I called here as “Base Layer” as something like an extension that contains a set of libraries for your main extension. This is a preface for introducting the “hidden” concept of Library Apps.
When you create an extension and you decide to go through the AppSource validation (publishing of your solution on the Microsoft’s marketplace) in your offer’s configuration, under the Technical configuration section, you need to upload your extension package file (.app file) and you can also upload other two things:
- Dependency package file: .app or .zip file for an extension that must be installed together with this extension and is published on the AppSource.
- Library extension package file: .app file for an extension that must be installed together with this extension, but must not be published to the AppSource. This is what is called a “Library app“:
What is a Library App? This is a normal extension (.app file) that your real extension depends on (dependencies setting on app.json file) and that you can submit together with your real extension. This library extension will not be visible on AppSource. When a customer downloads your extension from the AppSource marketplace, this library extension is automatically installed together with your published extension.
As you can see in the above image, the AppSource submission portal permits you to upload a single .app file, but if you have more that one Library app where your extension depends on, you can zip all your library apps into a single .zip package and upload this .zip package to the portal directly. Remember that all .app files must be digitally signed.
I think that Library extension packages are really useful on lots of scenarios (they helps you to avoid lots of dependencies, they permits you to create libraries of business logic that you can reuse on different apps, they permits you to easily separate concerns etc.) and I don’t know why there’s no official documentation about this possibility, at least at the moment (this is why I’ve used the word “mistery” in the title of this post).
Now you know that you’ve also this possibility when you create your extensions for the marketplace… 🙂