Developer Tooling | The .NET Blog

azd + GitHub Copilot: Penyiapan Proyek Berbantuan AI dan Pemecahan Masalah Error Cerdas

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

Artikel ini diterjemahkan secara otomatis. Untuk versi asli dalam bahasa Inggris, klik di sini.

Kamu pasti pernah mengalami momen ketika ingin men-deploy aplikasi yang sudah ada ke Azure, lalu menatap file azure.yaml yang kosong sambil mencoba mengingat apakah Express API-mu harus menggunakan Container Apps atau App Service? Momen itu kini jauh lebih singkat.

Azure Developer CLI (azd) kini terintegrasi dengan GitHub Copilot dalam dua cara yang nyata: scaffolding proyek berbantuan AI selama azd init, dan pemecahan masalah error cerdas ketika deployment gagal. Kedua fitur ini sepenuhnya berjalan di dalam terminal.

Setup dengan Copilot selama azd init

Saat menjalankan azd init, kini ada opsi “Set up with GitHub Copilot (Preview)”. Pilih itu dan Copilot akan menganalisis codebase-mu untuk menghasilkan azure.yaml, template infrastruktur, dan modul Bicep — berdasarkan kode aslimu.

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

Prasyarat:

azd 1.23.11 atau lebih baru — cek dengan azd version atau perbarui dengan azd update
Langganan GitHub Copilot aktif (Individual, Business, atau Enterprise)
GitHub CLI (gh) — azd akan meminta login jika diperlukan

Yang menurutku benar-benar berguna: ini bekerja dua arah. Membangun dari nol? Copilot membantu mengonfigurasi layanan Azure yang tepat sejak awal. Punya aplikasi yang ingin di-deploy? Arahkan Copilot ke sana dan konfigurasi akan dibuat tanpa perlu restrukturisasi kode apapun.

Yang sebenarnya dilakukan

Katakanlah kamu punya Node.js Express API dengan dependensi PostgreSQL. Daripada memutuskan manual antara Container Apps dan App Service, lalu menulis Bicep dari nol, Copilot mendeteksi stack-mu dan menghasilkan:

azure.yaml dengan pengaturan language, host, dan build yang tepat
Modul Bicep untuk Azure Container Apps
Modul Bicep untuk Azure Database for PostgreSQL

Dan menjalankan pemeriksaan awal sebelum mengubah apapun — memverifikasi direktori git bersih, meminta persetujuan alat server MCP di awal. Tidak ada yang terjadi tanpa kamu tahu persis apa yang akan berubah.

Pemecahan Masalah Error dengan Copilot

Error deployment adalah hal yang tak terhindarkan. Parameter yang hilang, masalah izin, ketersediaan SKU — dan pesan error jarang memberitahumu satu hal yang benar-benar perlu kamu ketahui: cara memperbaikinya.

Tanpa Copilot, siklusnya terlihat seperti: salin error → cari di docs → baca tiga jawaban Stack Overflow yang tidak relevan → jalankan beberapa perintah az CLI → coba lagi dan berharap. Dengan Copilot terintegrasi di azd, siklus ini runtuh. Saat perintah azd apapun gagal, langsung ditawarkan empat pilihan:

Explain — penjelasan dalam bahasa sederhana tentang apa yang salah
Guidance — instruksi langkah demi langkah untuk memperbaiki masalah
Diagnose and Guide — analisis lengkap + Copilot menerapkan perbaikan (dengan persetujuanmu) + retry opsional
Skip — tangani sendiri

Poin kuncinya: Copilot sudah memiliki konteks tentang proyekmu, perintah yang gagal, dan detail error. Sarannya spesifik untuk situasimu.

Mengatur Perilaku Default

Jika selalu memilih opsi yang sama, lewati prompt interaktif:

azd config set copilot.errorHandling.category troubleshoot

Nilai: explain, guidance, troubleshoot, fix, skip. Kamu juga bisa mengaktifkan auto-fix dan retry:

azd config set copilot.errorHandling.fix allow

Kembali ke mode interaktif kapan saja:

azd config unset copilot.errorHandling.category

Kesimpulan

Jalankan azd update untuk mendapatkan versi terbaru dan coba azd init di proyek berikutnya.

Baca pengumuman aslinya di sini.

Menulis Native Addon Node.js dalam C# dengan .NET Native AOT

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

Artikel ini diterjemahkan secara otomatis. Untuk versi asli dalam bahasa Inggris, klik di sini.

Ini skenario yang saya suka: sebuah tim yang mengerjakan tooling .NET memiliki native addon Node.js yang ditulis dalam C++ dan dikompilasi via node-gyp. Berhasil. Tapi itu mengharuskan Python terinstall di setiap mesin developer — versi Python yang lama, perlu dicatat — hanya untuk membangun sebuah paket yang tidak akan pernah disentuh langsung oleh siapapun di tim.

Jadi mereka mengajukan pertanyaan yang sangat masuk akal: kita sudah punya .NET SDK terinstall, kenapa kita masih menulis C++?

Jawabannya adalah Native AOT, dan hasilnya sungguh elegan. Drew Noakes dari tim C# Dev Kit menulis bagaimana mereka melakukannya.

Ide dasarnya

Native addon Node.js adalah shared library (.dll di Windows, .so di Linux, .dylib di macOS) yang bisa dimuat Node.js saat runtime. Antarmukanya disebut N-API — C API yang stabil dan kompatibel dengan ABI. N-API tidak peduli bahasa apa yang menghasilkan library tersebut, hanya bahwa ia mengekspor simbol yang tepat.

.NET Native AOT bisa menghasilkan tepat itu. Ia mengkompilasi kode C# kamu ahead-of-time menjadi shared library native dengan entry point sembarang.

Konfigurasi proyek

File proyek sangat minimal:

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

PublishAot memberitahu SDK untuk menghasilkan shared library saat dotnet publish.

Mengekspor entry point

Node.js mengharapkan library kamu mengekspor napi_register_module_v1. Dalam C#, [UnmanagedCallersOnly] melakukan persis itu:

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

Sufiks u8 menghasilkan ReadOnlySpan<byte> dengan string literal UTF-8, diteruskan langsung ke N-API tanpa alokasi encoding apapun.

Resolving N-API terhadap proses host

Fungsi N-API diekspor oleh node.exe sendiri, bukan library terpisah. Jadi alih-alih melakukan linking, kamu me-resolve-nya terhadap proses yang berjalan saat startup:

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

Dengan itu, deklarasi P/Invoke bekerja dengan bersih:

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

Memanggil dari TypeScript

dotnet publish menghasilkan native library spesifik platform kamu. Ganti namanya menjadi .node dan gunakan dengan require() standar:

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

Itu saja. TypeScript ke C#, tanpa Python, tanpa C++.

Kesimpulan

Tim C# Dev Kit mengganti overhead Python/C++ dengan kode C# yang bersih yang sudah bisa ditulis dan di-debug oleh semua orang di tim. Polanya tidak rumit setelah kamu melihatnya, dan ini adalah contoh bagus dari Native AOT yang memecahkan masalah nyata yang jarang dibicarakan.

Baca posting aslinya di blog .NET.