Developer Tooling | The .NET Blog

azd + GitHub Copilot: AI-gedreven projectopzet en slimme foutoplossing

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

Dit artikel is automatisch vertaald. Voor de originele Engelse versie, klik hier.

Ken je dat moment waarop je een bestaande app naar Azure wilt deployen en je naar een lege azure.yaml staart, terwijl je probeert te herinneren of je Express API Container Apps of App Service moet gebruiken? Dat moment is zojuist een stuk korter geworden.

De Azure Developer CLI (azd) integreert nu met GitHub Copilot op twee concrete manieren: AI-ondersteunde projectscaffolding tijdens azd init, en intelligente foutoplossing wanneer deployments mislukken. Beide functies blijven volledig in de terminal.

Setup met Copilot tijdens azd init

Wanneer je azd init uitvoert, is er nu een optie “Set up with GitHub Copilot (Preview)”. Selecteer die en Copilot analyseert je codebase om de azure.yaml, infrastructuursjablonen en Bicep-modules te genereren — gebaseerd op je echte code.

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

Vereisten:

azd 1.23.11 of nieuwer — controleer met azd version of update met azd update
Actief GitHub Copilot-abonnement (Individual, Business of Enterprise)
GitHub CLI (gh) — azd vraagt om login als dat nodig is

Wat ik echt nuttig vind: het werkt in beide richtingen. Bouw je van de grond af? Copilot helpt je de juiste Azure-services vanaf het begin te configureren. Heb je een bestaande app die je wilt deployen? Wijs Copilot daarop en het genereert de configuratie zonder dat je iets hoeft te herstructureren.

Wat het eigenlijk doet

Stel je hebt een Node.js Express API met een PostgreSQL-afhankelijkheid. In plaats van handmatig te kiezen tussen Container Apps en App Service en dan Bicep van de grond af te schrijven, detecteert Copilot je stack en genereert:

Een azure.yaml met de juiste language-, host- en build-instellingen
Een Bicep-module voor Azure Container Apps
Een Bicep-module voor Azure Database for PostgreSQL

En het voert voorafgaande controles uit voor wijzigingen — verifieert dat je git-werkdirectory schoon is, vraagt van tevoren toestemming voor MCP-servertools. Niets gebeurt zonder dat je precies weet wat er gaat veranderen.

Foutoplossing met Copilot

Deployment-fouten zijn onvermijdelijk. Ontbrekende parameters, toestemmingsproblemen, SKU-beschikbaarheid — en het foutbericht vertelt je zelden het enige dat je echt moet weten: hoe je het oplost.

Zonder Copilot ziet de lus er zo uit: kopieer de fout → zoek in docs → lees drie irrelevante Stack Overflow-antwoorden → voer wat az CLI-opdrachten uit → probeer opnieuw en hoop. Met Copilot geïntegreerd in azd stort deze lus in. Wanneer een azd-opdracht mislukt, biedt het onmiddellijk vier opties:

Explain — uitleg in begrijpelijke taal van wat er mis ging
Guidance — stapsgewijze instructies om het probleem op te lossen
Diagnose and Guide — volledige analyse + Copilot past de oplossing toe (met jouw goedkeuring) + optioneel opnieuw proberen
Skip — zelf afhandelen

Het cruciale punt: Copilot heeft al context over je project, de mislukte opdracht en de foutdetails. Zijn suggesties zijn specifiek voor jouw situatie.

Een standaardgedrag instellen

Als je altijd dezelfde optie kiest, sla de interactieve prompt over:

azd config set copilot.errorHandling.category troubleshoot

Waarden: explain, guidance, troubleshoot, fix, skip. Je kunt ook automatisch herstellen en opnieuw proberen inschakelen:

azd config set copilot.errorHandling.fix allow

Op elk moment terug naar de interactieve modus:

azd config unset copilot.errorHandling.category

Samenvatting

Voer azd update uit voor de nieuwste versie en probeer azd init op je volgende project.

Lees de originele aankondiging hier.

Native Node.js-addons schrijven in C# met .NET Native AOT

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

Dit artikel is automatisch vertaald. Voor de originele Engelse versie, klik hier.

Hier is een scenario dat ik geweldig vind: een team dat werkt aan .NET-tooling had native Node.js-addons geschreven in C++ en gecompileerd via node-gyp. Het werkte. Maar het vereiste Python op elke machine van een ontwikkelaar — een oude versie van Python, let wel — alleen om een pakket te compileren dat niemand in het team ooit rechtstreeks zou aanraken.

Dus stelden ze een heel redelijke vraag: we hebben de .NET SDK al geïnstalleerd, waarom schrijven we überhaupt C++?

Het antwoord was Native AOT, en het resultaat is oprecht elegant. Drew Noakes van het C# Dev Kit-team schreef op hoe ze het aanpakten.

Het basisidee

Een native Node.js-addon is een gedeelde bibliotheek (.dll op Windows, .so op Linux, .dylib op macOS) die Node.js tijdens runtime kan laden. De interface heet N-API — een stabiele, ABI-compatibele C API. N-API maakt niet uit welke taal de bibliotheek heeft geproduceerd, alleen dat die de juiste symbolen exporteert.

.NET Native AOT kan precies dat produceren. Het compileert je C#-code ahead-of-time naar een native gedeelde bibliotheek met willekeurige invoerpunten.

De projectconfiguratie

Het projectbestand is minimaal:

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

PublishAot vertelt de SDK om een gedeelde bibliotheek te produceren bij dotnet publish.

Het invoerpunt exporteren

Node.js verwacht dat jouw bibliotheek napi_register_module_v1 exporteert. In C# doet [UnmanagedCallersOnly] precies dat:

[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;
}

Het u8-achtervoegsel produceert een ReadOnlySpan<byte> met een UTF-8 string-literal, rechtstreeks doorgegeven aan N-API zonder enige coderingstoewijzing.

N-API oplossen tegen het hostproces

N-API-functies worden geëxporteerd door node.exe zelf, niet door een aparte bibliotheek. Dus in plaats van ergens tegen te linken, los je ze op tegen het actieve proces bij opstarten:

NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

Daarmee werken P/Invoke-declaraties netjes:

[LibraryImport("node", EntryPoint = "napi_create_string_utf8")]
internal static partial Status CreateStringUtf8(
 nint env, ReadOnlySpan<byte> str, nuint length, out nint result);

Aanroepen vanuit TypeScript

dotnet publish produceert jouw platformspecifieke native bibliotheek. Hernoem het naar .node en gebruik het met een standaard require():

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

Dat is het. TypeScript naar C#, geen Python, geen C++.

Samenvatting

Het C# Dev Kit-team verving de overhead van Python/C++ door schone C#-code die iedereen in het team al weet hoe te schrijven en debuggen. Het patroon is niet ingewikkeld zodra je het ziet, en het is een geweldig voorbeeld van Native AOT die een echt probleem oplost dat niet genoeg wordt besproken.

Lees de originele blogpost op het .NET-blog.