Tooling, ALM and deployment — from VS Code to Visual Studio, from .app to deployable package
A structured comparison of the Business Central and D365 Finance and Supply Chain Management development toolchains: VS Code plus the AL Language extension versus Visual Studio plus D365 developer tools; app.json/launch.json versus models and packages; sandbox containers versus cloud-hosted dev environments; AppSource validation versus Power Platform admin center deployment; Git and Azure DevOps CI/CD on both sides; and Application Insights telemetry patterns.
What you will be able to do
Set up a D365 Finance and Supply Chain Management development environment and explain how it differs from a BC sandbox container
Explain the model-and-package concept and how it replaces app.json dependency management
Build and deploy a deployable package to a sandbox environment via the Power Platform admin center
Design an Azure DevOps pipeline for D365 that parallels an existing AL-Go or BC pipeline
Configure Application Insights telemetry for D365 and compare the signal to BC telemetry patterns
Introduction
A Business Central developer's daily tools — VS Code, the AL Language extension, Docker containers, app.json, the symbol download, the F5 debug cycle and the AppSource or per-tenant deployment path — have no equivalent binaries on the D365 side.
IDE: VS Code versus Visual Studio
The transition from VS Code to Visual Studio is not merely swapping one editor for another. Visual Studio provides:
Project structure: app.json versus model descriptor
BC project structure D365 project structure Model descriptor versus app.json
Build and compilation
The AL compiler produces a single .app file — a signed package containing compiled AL and metadata. Build time for a typical extension: 10–30 seconds.
Development environments
[!IMPORTANT] In D365, each developer typically has their own cloud-hosted development VM. There is no shared development server equivalent. The VM runs the full stack (AOS, SQL, batch, SSRS, Visual Studio) and costs money while running.
Deployment: .app versus deployable package
Build produces .app file Upload to admin centre or publish via API Install or upgrade on target environment (seconds to minutes) Immediate availability — no downtime for per-tenant extensions
Both BC and D365 development use Git, but the branching strategy differs due to deployment mechanics.
Telemetry and monitoring
Business Central emits telemetry to Application Insights with a structured event schema:
Environment lifecycle and service updates
Business Central online receives monthly minor updates and two major updates per year. Per-tenant extensions must be compatible — breaking changes cause install failures. Developers validate using the AppSourceCop analyser and compatibility tests.
Knowledge check
Summary
The toolchain transition from BC to D365 is a complete change of environment, IDE, build system, deployment model and monitoring surface. The concepts — write, compile, test, package, deploy, monitor — survive, but every tool implementing them changes.