Developer Tooling | The .NET Blog

azd + GitHub Copilot: Konfiguracja projektu z AI i inteligentne rozwiązywanie błędów

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

Ten artykuł został przetłumaczony automatycznie. Oryginalną wersję angielską znajdziesz tutaj.

Znasz ten moment, gdy chcesz wdrożyć istniejącą aplikację na Azure i patrzysz na pusty azure.yaml, próbując przypomnieć sobie, czy Twoje Express API powinno używać Container Apps czy App Service? Ten moment właśnie stał się znacznie krótszy.

Azure Developer CLI (azd) integruje się teraz z GitHub Copilot na dwa konkretne sposoby: scaffolding projektu wspomagany przez AI podczas azd init oraz inteligentne rozwiązywanie błędów gdy wdrożenia kończą się niepowodzeniem. Obie funkcje działają całkowicie w terminalu.

Konfiguracja z Copilotem podczas azd init

Po uruchomieniu azd init pojawia się opcja “Set up with GitHub Copilot (Preview)”. Wybierz ją, a Copilot przeanalizuje Twój codebase i wygeneruje azure.yaml, szablony infrastruktury oraz moduły Bicep — na podstawie Twojego rzeczywistego kodu.

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

Wymagania:

azd 1.23.11 lub nowszy — sprawdź przez azd version lub zaktualizuj przez azd update
Aktywna subskrypcja GitHub Copilot (Individual, Business lub Enterprise)
GitHub CLI (gh) — azd poprosi o logowanie jeśli potrzeba

To co uważam za naprawdę użyteczne: działa w obu kierunkach. Budujesz od zera? Copilot pomaga skonfigurować właściwe usługi Azure od początku. Masz istniejącą aplikację do wdrożenia? Wskaż Copilotem na nią — konfiguracja zostanie wygenerowana bez konieczności restrukturyzacji kodu.

Co faktycznie robi

Powiedzmy, że masz Node.js Express API z zależnością od PostgreSQL. Zamiast ręcznie wybierać między Container Apps a App Service, a potem pisać Bicep od zera, Copilot wykrywa Twój stack i generuje:

azure.yaml z właściwymi ustawieniami language, host i build
Moduł Bicep dla Azure Container Apps
Moduł Bicep dla Azure Database for PostgreSQL

Przed jakąkolwiek zmianą przeprowadzane są wstępne sprawdzenia — weryfikuje czystość katalogu roboczego git, pyta z wyprzedzeniem o zgodę na narzędzia serwera MCP. Nic nie dzieje się bez Twojej wiedzy.

Rozwiązywanie błędów z Copilotem

Błędy wdrożenia są nieuniknione. Brakujące parametry, problemy z uprawnieniami, dostępność SKU — a komunikat o błędzie rzadko mówi to, co naprawdę musisz wiedzieć: jak to naprawić.

Bez Copilota pętla wygląda tak: skopiuj błąd → szukaj w dokumentacji → czytaj trzy niepowiązane odpowiedzi na Stack Overflow → uruchom kilka poleceń az CLI → spróbuj ponownie. Z Copilotem w azd ta pętla znika. Gdy jakiekolwiek polecenie azd kończy się błędem, natychmiast oferuje cztery opcje:

Explain — wyjaśnienie w zrozumiałym języku, co poszło nie tak
Guidance — instrukcje krok po kroku jak naprawić problem
Diagnose and Guide — pełna analiza + Copilot stosuje poprawkę (za Twoją zgodą) + opcjonalne ponowienie
Skip — samodzielna obsługa

Kluczowa kwestia: Copilot ma już kontekst Twojego projektu, nieudanego polecenia i szczegółów błędu. Jego sugestie są specyficzne dla Twojej sytuacji.

Ustawianie domyślnego zachowania

Jeśli zawsze wybierasz tę samą opcję, pomiń interaktywny monit:

azd config set copilot.errorHandling.category troubleshoot

Wartości: explain, guidance, troubleshoot, fix, skip. Możesz też włączyć automatyczną naprawę i ponowienie:

azd config set copilot.errorHandling.fix allow

Powrót do trybu interaktywnego w dowolnym momencie:

azd config unset copilot.errorHandling.category

Podsumowanie

Uruchom azd update po najnowszą wersję i wypróbuj azd init w swoim następnym projekcie.

Przeczytaj oryginalny komunikat tutaj.

Pisanie natywnych dodatków Node.js w C# z .NET Native AOT

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

Ten artykuł został przetłumaczony automatycznie. Oryginalną angielską wersję znajdziesz tutaj.

Oto scenariusz, który uwielbiam: zespół pracujący nad narzędziami .NET miał natywne dodatki Node.js napisane w C++ i kompilowane przez node-gyp. Działało. Ale wymagało zainstalowania Pythona na każdej maszynie dewelopera — starej wersji Pythona, nawiasem mówiąc — tylko po to, by skompilować pakiet, którego nikt w zespole nigdy nie dotykał bezpośrednio.

Więc zadali bardzo rozsądne pytanie: mamy już zainstalowany .NET SDK, po co w ogóle piszemy C++?

Odpowiedzią był Native AOT, a wynik jest naprawdę elegancki. Drew Noakes z zespołu C# Dev Kit opisał, jak to zrobili, i uważam, że warto to zrozumieć nawet jeśli nie budujesz rozszerzeń VS Code.

Podstawowy pomysł

Natywny dodatek Node.js to biblioteka współdzielona (.dll na Windows, .so na Linux, .dylib na macOS), którą Node.js może załadować w czasie wykonywania. Interfejs nazywa się N-API — stabilne, zgodne z ABI API języka C. N-API nie obchodzi, w jakim języku wyprodukowano bibliotekę, tylko żeby eksportowała właściwe symbole.

.NET Native AOT może dokładnie to zrobić. Kompiluje kod C# z wyprzedzeniem do natywnej biblioteki współdzielonej z dowolnymi punktami wejścia.

Konfiguracja projektu

Plik projektu jest minimalny:

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

PublishAot mówi SDK, by przy dotnet publish wygenerował bibliotekę współdzieloną.

Eksportowanie punktu wejścia

Node.js oczekuje, że biblioteka wyeksportuje napi_register_module_v1. W C# robi to [UnmanagedCallersOnly]:

[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 tworzy ReadOnlySpan<byte> z literałem łańcucha UTF-8, przekazywanym bezpośrednio do N-API bez żadnej alokacji kodowania.

Rozwiązywanie N-API względem procesu hosta

Funkcje N-API są eksportowane przez sam node.exe, nie przez osobną bibliotekę. Zamiast linkować do czegoś, rozwiązujesz je względem działającego procesu przy starcie:

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

Z tym deklaracje P/Invoke działają czysto:

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

Wywołanie z TypeScript

dotnet publish produkuje natywną bibliotekę dla twojej platformy. Zmieniasz jej nazwę na .node i używasz ze standardowym require():

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

Tyle. TypeScript do C#, bez Pythona, bez C++.

Podsumowanie

Zespół C# Dev Kit zastąpił narzut Python/C++ czystym kodem C#, który każdy w zespole już umie pisać i debugować. Wzorzec nie jest skomplikowany po tym, jak się go zobaczy, i jest świetnym przykładem Native AOT rozwiązującego realny problem.

Przeczytaj oryginalny wpis na blogu .NET.