Install, develop, and deploy for Business Central
The inner loop
Development happens in Visual Studio Code with the AL Language extension. A project is defined by app.json (id GUID, name, publisher, version, idRanges, dependencies, platform/application/runtime versions, features) and launch.json (environment name, tenant, breakOnError, startupObjectId/startupObjectType). Before compiling you must download symbols, which pulls the reference packages for the System and Base Application.
Deployment paths
- Sandbox: publish directly from VS Code (AL: Publish to Environment) - fast, disposable, the default target while developing.
- Production: upload the .app as a per-tenant extension in the admin center, or deploy through a pipeline (AL-Go for GitHub, Azure DevOps). AppSource apps are installed per environment from the marketplace.
- On-premises: build a Docker container with BcContainerHelper (New-BcContainer), which also gives a local sandbox and the test framework.
Version discipline: bump the version in app.json for every deployment. Business Central refuses to install a lower version over a higher one, and redeploying an identical version can be skipped or fail.
Runtime vs application: they are separate numbers. Runtime 6.0+ removes the implicit with statement and changes other behaviour, so verify which runtime the target environment runs before using newer syntax.
ID ranges: object IDs must sit inside the idRanges declared in app.json, which themselves must fit the range assigned to the tenant or partner. Out-of-range IDs fail validation at publish time.
Rule of thumb: develop in a sandbox, download symbols, bump the version, then publish - never point launch.json at production while iterating.
Traps: forgetting that a dependency (another PTE) must be installed first; assuming publishing to production works without app management rights; mixing application and runtime version numbers.