Developer Tooling | The .NET Blog

azd + GitHub Copilot: Configurazione del progetto con IA e risoluzione intelligente degli errori

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Questo articolo è stato tradotto automaticamente. Per la versione originale in inglese, clicca qui.

Conosci quel momento in cui vuoi fare il deploy di un’app esistente su Azure e ti ritrovi a fissare un azure.yaml vuoto, cercando di ricordare se la tua API Express dovrebbe usare Container Apps o App Service? Quel momento è appena diventato molto più breve.

L’Azure Developer CLI (azd) si integra ora con GitHub Copilot in due modi concreti: scaffolding assistito dall’IA durante azd init, e risoluzione intelligente degli errori quando i deployment falliscono. Entrambe le funzionalità rimangono completamente nel terminale — esattamente dove voglio che siano.

Configurazione con Copilot durante azd init

Quando esegui azd init, ora compare l’opzione “Set up with GitHub Copilot (Preview)”. Selezionala e Copilot analizza la tua codebase per generare azure.yaml, i template di infrastruttura e i moduli Bicep — basandosi sul tuo codice reale.

azd init
# Seleziona: "Set up with GitHub Copilot (Preview)"

Prerequisiti:

azd 1.23.11 o superiore — verifica con azd version o aggiorna con azd update
Abbonamento attivo a GitHub Copilot (Individual, Business o Enterprise)
GitHub CLI (gh) — azd chiederà il login se necessario

Quello che trovo genuinamente utile: funziona in entrambi i sensi. Stai costruendo da zero? Copilot ti aiuta a configurare i servizi Azure giusti sin dall’inizio. Hai un’app esistente che volevi deployare da tempo? Punta Copilot su di essa e genera la configurazione senza che tu debba ristrutturare nulla.

Cosa fa davvero

Diciamo che hai un’API Express Node.js con dipendenza da PostgreSQL. Invece di decidere manualmente tra Container Apps e App Service, e poi scrivere Bicep da zero, Copilot rileva il tuo stack e genera:

Un azure.yaml con le impostazioni corrette di language, host e build
Un modulo Bicep per Azure Container Apps
Un modulo Bicep per Azure Database for PostgreSQL

E prima di toccare qualsiasi cosa esegue verifiche preventive — controlla che la tua directory git sia pulita, chiede il consenso per gli strumenti del server MCP. Niente accade senza che tu sappia esattamente cosa sta per cambiare.

Risoluzione degli errori con Copilot

Gli errori di deployment sono inevitabili. Parametri mancanti, problemi di permessi, disponibilità degli SKU — e il messaggio d’errore raramente ti dice l’unica cosa che hai davvero bisogno di sapere: come risolverlo.

Senza Copilot, il ciclo è: copiare l’errore → cercare nella documentazione → leggere tre risposte irrilevanti su Stack Overflow → eseguire alcuni comandi az CLI → riprovare sperando. Con Copilot integrato in azd, questo ciclo collassa. Quando qualsiasi comando azd fallisce, offre immediatamente quattro opzioni:

Explain — spiegazione in linguaggio naturale di cosa è andato storto
Guidance — istruzioni passo dopo passo per correggere il problema
Diagnose and Guide — analisi completa + Copilot applica la correzione (con la tua approvazione) + retry opzionale
Skip — gestire da soli

Il punto cruciale: Copilot ha già il contesto del tuo progetto, il comando che ha fallito e l’output dell’errore. I suoi suggerimenti sono specifici per la tua situazione, non documentazione generica.

Configurare il comportamento predefinito

Se scegli sempre la stessa opzione, salta il prompt interattivo:

azd config set copilot.errorHandling.category troubleshoot

Valori: explain, guidance, troubleshoot, fix, skip. Puoi anche abilitare auto-fix e retry:

azd config set copilot.errorHandling.fix allow

Ritorno alla modalità interattiva in qualsiasi momento:

azd config unset copilot.errorHandling.category

Conclusione

Questo è esattamente il tipo di integrazione di Copilot che porta valore reale. Provalo eseguendo azd update per ottenere l’ultima versione e usa azd init nel tuo prossimo progetto.

Leggi l’annuncio originale qui.

Scrivere addon nativi Node.js in C# con .NET Native AOT

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Questo articolo è stato tradotto automaticamente. Per la versione originale in inglese, clicca qui.

Uno scenario che adoro: un team che lavora su strumenti .NET aveva addon nativi Node.js scritti in C++ e compilati tramite node-gyp. Funzionava. Ma richiedeva Python installato su ogni macchina dello sviluppatore — una vecchia versione di Python, per giunta — solo per costruire un pacchetto che nessuno nel team avrebbe mai toccato direttamente.

Si sono quindi posti una domanda molto ragionevole: abbiamo già il SDK .NET installato, perché stiamo scrivendo C++?

La risposta è stata Native AOT, e il risultato è genuinamente elegante.

L’idea di base

Un addon nativo Node.js è una libreria condivisa (.dll su Windows, .so su Linux, .dylib su macOS) che Node.js può caricare a runtime. L’interfaccia si chiama N-API — una API C stabile e compatibile con ABI. A N-API non importa quale linguaggio ha prodotto la libreria, solo che esporti i simboli giusti.

.NET Native AOT può produrre esattamente questo. Compila il codice C# ahead-of-time in una libreria nativa condivisa con punti di ingresso arbitrari. Questo è tutto il trucco.

Setup del progetto

Il file di progetto è minimale:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot dice all’SDK di produrre una libreria condivisa a dotnet publish. AllowUnsafeBlocks è necessario per l’interop N-API con puntatori a funzione e buffer fissi.

Esportare il punto di ingresso

Node.js si aspetta che la tua libreria esporti napi_register_module_v1. In C#, [UnmanagedCallersOnly] fa esattamente questo:

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

Cose da notare: nint è un intero di dimensione nativa — l’equivalente gestito di intptr_t. Il suffisso u8 produce un ReadOnlySpan<byte> con un letterale stringa UTF-8, passato direttamente a N-API senza alcuna allocazione di encoding. E [UnmanagedCallersOnly] esporta il metodo con esattamente il nome del punto di ingresso che Node.js cerca.

Risolvere N-API contro il processo host

Le funzioni N-API sono esportate da node.exe stesso, non da una libreria separata. Quindi invece di linkare contro qualcosa, le si risolve contro il processo in esecuzione all’avvio:

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

Con questo in place, le dichiarazioni P/Invoke funzionano correttamente con [LibraryImport] e marshalling generato da sorgente.

Una funzione esportata reale

Ecco il lettore del registro che hanno costruito:

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

Nota importante sul try/catch: un’eccezione non gestita in un metodo [UnmanagedCallersOnly] fa crashare il processo host. Cattura sempre e passa a JavaScript tramite ThrowError.

Chiamarlo da TypeScript

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk', 'InstallLocation');

TypeScript → C#, senza Python, senza C++.

Cosa hanno guadagnato

La vittoria immediata è stata nell’esperienza dei contributori: nessuna versione Python specifica necessaria, yarn install funziona con solo Node.js e il SDK .NET. Anche le pipeline CI sono diventate più semplici. Le prestazioni sono state comparabili all’implementazione C++.

Conclusione

Il team C# Dev Kit ha sostituito il carico di Python/C++ con codice C# pulito che tutto il team sa già scrivere e debuggare. Per il walkthrough completo con tutti gli helper di marshalling delle stringhe, dai un’occhiata all’articolo originale sul blog .NET.