Dove vive oggi l’ambiente di sviluppo

Nella Unified Developer Experience (UDE) l’ambiente di sviluppo non è più una macchina virtuale isolata: è un ambiente Power Platform che include il componente finance and operations. Lo si crea, si assegna e lo si governa dal Power Platform admin center (PPAC), dove si decidono tipo di ambiente, capacità, copie e reset. Lo sviluppatore non lavora “dentro” la VM: installa in locale gli strumenti di sviluppo per finance and operations su Visual Studio, collega l’IDE all’ambiente e opera sui metadati dal proprio client, mentre gli artefatti compilati vengono distribuiti nell’ambiente collegato. Il senso della convergenza con Dataverse è che la stessa solution può contenere elementi X++ e componenti Power Platform.

Va tenuta ben distinta la funzione dell’Implementation portal: traccia il progetto di implementazione, le review e la go-live readiness. È governance di programma, non provisioning: non crea né distribuisce ambienti. Gli ambienti gestiti da LCS restano in scenari legacy, ma non vanno più presentati come l’unica strada. In sede d’esame lo scenario si scioglie quasi sempre con una domanda sola: sto creando o gestendo un ambiente (PPAC) oppure documentando avanzamento e prontezza (Implementation portal)?

Visual Studio e l’AOT

L’Application Explorer è la vista sull’AOT: elementi organizzati per tipo (table, form, class, EDT, enum, menu item, query, elementi di security) e filtrabili per model. Da qui si aggiungono elementi al progetto oppure, più spesso, si crea l’extension dell’elemento standard: sotto il modello corrente l’overlayering non è la strada, quindi il gesto corretto su un artefatto Microsoft è creare l’extension, non personalizzarlo in place. Ogni tipo ha il suo element designer (table designer, form designer, designer per EDT ed enum), mentre classi e metodi si scrivono nell’editor X++.

Il progetto raggruppa gli elementi e appartiene a un solo model; la solution ne raccoglie più d’uno, tipicamente uno per model quando la personalizzazione tocca più package. Le proprietà di progetto contano: model di destinazione, sincronizzazione del database alla build, oggetto di avvio. Le dipendenze fra model vivono nelle reference del package: se il tuo model estende una table di Application Suite, quel riferimento deve esistere o la build fallisce.

Build, sincronizzazione e debug

La build compila progetto o intero model e produce gli artefatti distribuiti nell’ambiente. Le modifiche allo schema (campi nuovi su una table extension, indici) richiedono la sincronizzazione del database: senza, il codice compila ma va in errore a runtime. Alla build si affiancano i controlli di best practice, alcuni warning e altri bloccanti; ignorarli è debito che ricompare quando serve generare il deployable package per sandbox e produzione.

Il debugger di Visual Studio lavora su X++ come su qualsiasi altro linguaggio: breakpoint anche condizionali, esecuzione passo-passo, finestre Locals, Watch, Call Stack, Immediate. Due punti pratici che l’esame ama: il breakpoint scatta solo sul codice effettivamente distribuito nell’ambiente collegato, quindi dopo una modifica si ricompila prima di stupirsi che non si fermi; e per le personalizzazioni il punto d’interruzione va nella tua classe di Chain of Command o nell’event handler, non nel metodo standard che non stai sovrascrivendo. Per il codice che gira nel batch framework, l’esecuzione avviene lato server in un contesto diverso da quello interattivo.

Prima di scrivere un workaround

Regola culturale che l’esame premia: davanti a un comportamento anomalo del codice standard, la prima mossa è la ricerca del problema noto negli strumenti di servizio Microsoft e nella documentazione ufficiale, non la customizzazione. Se esiste una correzione di piattaforma o applicativa, la soluzione supportata è aggiornare: un workaround in X++ su un bug già risolto è codice da mantenere per sempre e un conflitto annunciato al prossimo update. MB-500 è attivo, ha passing score 700/1000 e non è disponibile in italiano: conviene allenare il lessico originale degli strumenti.

Trappole tipiche d’esame

  • Serve un nuovo ambiente per uno sviluppatore → Power Platform admin center: è lì che gli ambienti si creano e si governano. L’Implementation portal non distribuisce nulla, e la risposta “LCS” è la scelta legacy quando lo scenario descrive la UDE.
  • Il management chiede lo stato del progetto e la prontezza al go-live → Implementation portal: governance del programma, non provisioning. Se la domanda parla di review, milestone o readiness, PPAC è il distrattore.
  • Aggiungere logica a un metodo standard → extension con CoC o event handler: dall’Application Explorer si crea l’extension. Le opzioni che descrivono la modifica diretta dell’elemento Microsoft (overlayering) sono sempre sbagliate.
  • Nuovo campo su una table extension che a runtime non esiste → sincronizzazione del database: la build compila i metadati, non allinea da sola lo schema SQL. “Ricompilare di nuovo” non risolve.
  • Il breakpoint non viene colpito dopo una modifica → build e distribuzione nell’ambiente collegato: si debugga ciò che è realmente distribuito, non il file aperto nell’editor.
  • Bug riproducibile nel codice standard → cerca il problema noto e aggiorna: il workaround custom è la risposta plausibile ma non supportata; l’update esistente è quella corretta.