What's New in AL: Dependency Publishing (2024 release wave 2)
Dependency publishing in AL (2024 release wave 2): when a developer publishes a changed app from VS Code, direct dependencies are recompiled and reapplied in order. Covers the default, ignore and strict options, restore after a failed deployment, and the limits.
- The dependency management challenge
- How VS Code handles deployment and failures
- Demonstration setup and scenario
- Dependency publishing failure and recovery
- Dependency publishing options explained
- Limitations and conclusion
Overview
The video explains why replacing an app that other extensions depend on is hard: dependents must be removed first, and getting back to the original state after a failed deployment can be difficult. Dependency publishing detects changes in the app and recompiles its direct dependencies during deployment, then reapplies the dependent extensions in the right order.
A demo shows a deployment failing and the original extensions being restored. The video then explains the three publishing options (default, ignore, strict) and the limitations, including that app downgrades are not supported and that changing the app version breaks the restore.
Key points
- Dependency publishing options is a setting in the launch config that controls how dependent apps are recompiled when publishing from VS Code with F5.
- Default option recompiles all direct dependencies of the changed app, whether or not they are in the current workspace.
- Ignore option recompiles only the published (changed) app, so dependent extensions can start getting runtime errors.
- Strict option requires all dependencies to be in the workspace and fails from the start if the changed app has dependencies not present in the workspace.
- If a deployment fails, the original extensions are restored, so the developer does not have to manually rebuild the previous extension setup.
- Restore does not work if the app version was changed as part of the deployment, because Business Central does not support app downgrades due to possible destructive changes.
Features
| Feature | Status | At |
|---|---|---|
| Dependency Publishing | status not stated, demoed | 4:47 |
| Dependency Publishing Options - Default | status not stated, demoed | 4:47 |
| Dependency Publishing Options - Ignore | status not stated | 5:40 |
| Dependency Publishing Options - Strict | status not stated | 5:56 |
| Extension restore on failed deployment | status not stated, demoed | 4:37 |
AL objects mentioned
As heard in the captions. A name that matches one object page by exact type and name links to it; the others stay as named.
- other “Extension management” at 2:23
Quotes
- 0:17 “To change out a dependency, you need to remove all the things that depend on it first.”
- 2:10 “it can be quite hard sometimes to get back to the original state on the left side here in order for me to continue”
- 4:47 “we have a option in the launch config called dependency publishing options”
- 4:57 “setting it to default here will recompile all the direct dependencies of the changed app whether or not they’re in the workspace I’m working”
- 5:25 “because we have improved the way we detect what is getting published and uninstalled and ready to be reapplied, we can now restore this”
- 6:20 “One of the core scenarios is is that we do not support in Business Central uh the downgrade of apps because they have destructive”
- 6:46 “for a normal developer like me looking here and changing some small things, pressing every every F5 every now and then, this will be”
- 6:46 “So, if you change the version as part of a small change, then it does not work with the restore.”
Disclaimers in the video
- 6:10 other: We do not support in Business Central the downgrade of apps because they have destructive changes
- 6:46 other: If you change the version as part of a small change, then it does not work with the restore
Presenters (as heard): Stefan Balslev.