Application Composer, Visual Builder and the Setup and Maintenance work area give way to Visual Studio, the Application Explorer and the D365 designers — a move from browser-based configuration to a desktop compiler with a build pipeline, an update cadence, and a debugger you have never had before.
Chapter 2 was about the language. This chapter is about the workshop you write it in, and the honest headline is that the workshop itself changes more than the language does.
Two consequences follow from putting the primary tool on a desktop rather than in a browser. First, environment provisioning becomes a real prerequisite: you cannot start writing X++ until a Tier-1 box exists, Visual Studio is installed and connected to it, and your extension model is created and building cleanly.
Fusion's unit of configuration is the sandbox: you edit inside one, then publish it, and the published state simply becomes the environment's new behaviour. D365's unit of configuration is the model — a named container of everything you build — which lives inside a package, which can declare referenced packages to consume element types…
Fusion promotes configuration between environments with Configuration Set Migration — exporting a sandbox's live configuration and importing it elsewhere — on a cadence tied to the platform's mandatory quarterly update. D365 replaces both halves of that story with a source-controlled, versioned pipeline:
Application Composer gives you Groovy log statements and a diagnostic-test framework: you run something, then go and read what happened. Visual Studio gives you a real debugger — breakpoints set directly in X++ source, step-into/step-over/step-out execution control, watch windows, and cross-tier debugging, which lets you follow execution…
An OTBI report running slowly or an Enterprise Scheduler Service (ESS) job taking too long both leave a trail you inspect after the fact — a job log, a query diagnostic panel.
BI Publisher templates over an OTBI subject area or a BI Publisher data model cover a wide range of output shapes in Fusion, and that range is exactly why one D365 tool cannot replace it. The honest mapping is by shape, not by name:
Fusion has no equivalent to a build failing for reasons unrelated to whether your logic is correct, because there is no build. D365 introduces best-practice static-analysis checks that run as part of every build, ranging from advisory warnings — a missing label, an unconventional name — to violations that block a deployable package…
The tools change shape more than they change purpose. Every Fusion capability in this chapter has a D365 counterpart; the difference is almost always that the counterpart sits behind a compile step, a package, or a deliberately captured trace, rather than being available live and by default.