Developer Tooling | The .NET Blog

azd + GitHub Copilot: Configuración de proyectos con IA y resolución inteligente de errores

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

Este artículo fue traducido automáticamente. Para ver la versión original en inglés, haz clic aquí.

¿Conoces ese momento en que quieres desplegar una app existente en Azure y te quedas mirando un azure.yaml en blanco, intentando recordar si tu API Express debería usar Container Apps o App Service? Ese momento acaba de volverse mucho más corto.

El Azure Developer CLI (azd) ahora se integra con GitHub Copilot de dos formas muy concretas: scaffolding asistido por IA durante azd init, y resolución inteligente de errores cuando los despliegues fallan. Ambas funciones se quedan completamente en tu terminal, que es exactamente donde quiero que estén.

Configuración con Copilot durante azd init

Cuando ejecutas azd init, ahora aparece la opción “Set up with GitHub Copilot (Preview)”. Selecciónala y Copilot analiza tu codebase para generar el azure.yaml, las plantillas de infraestructura y los módulos Bicep — basándose en tu código real, no en suposiciones.

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

Para que funcione necesitas:

azd 1.23.11 o superior — comprueba con azd version o actualiza con azd update
Una suscripción activa de GitHub Copilot (Individual, Business o Enterprise)
GitHub CLI (gh) — azd pedirá login si es necesario

Lo que me parece genuinamente útil es que funciona en los dos sentidos. ¿Construyendo desde cero? Copilot te ayuda a configurar los servicios Azure correctos desde el principio. ¿Tienes una app existente que llevas tiempo sin desplegar? Apunta Copilot hacia ella y genera la configuración sin que tengas que reestructurar nada.

Lo que hace realmente

Imagina que tienes una API Express en Node.js con dependencia de PostgreSQL. En lugar de decidir manualmente entre Container Apps o App Service, y luego escribir Bicep desde cero, Copilot detecta tu stack y genera:

Un azure.yaml con los ajustes correctos de language, host y build
Un módulo Bicep para Azure Container Apps
Un módulo Bicep para Azure Database for PostgreSQL

Y hace comprobaciones previas antes de tocar nada — verifica que tu directorio git esté limpio, pide consentimiento para las herramientas del servidor MCP. Nada ocurre sin que sepas exactamente qué va a cambiar.

Resolución de errores potenciada por Copilot

Los errores de despliegue son inevitables. Parámetros faltantes, problemas de permisos, disponibilidad de SKUs — y el mensaje de error raramente te dice lo único que realmente necesitas saber: cómo solucionarlo.

Sin Copilot, el ciclo es: copiar el error → buscar en docs → leer tres respuestas irrelevantes de Stack Overflow → ejecutar algunos comandos az CLI → volver a intentarlo y rezar. Con Copilot integrado en azd, ese ciclo se colapsa. Cuando cualquier comando azd falla, ofrece inmediatamente cuatro opciones:

Explain — descripción en lenguaje natural de qué salió mal
Guidance — instrucciones paso a paso para solucionarlo
Diagnose and Guide — análisis completo + Copilot aplica la solución (con tu aprobación) + reintento opcional
Skip — gestionarlo tú mismo

Lo clave: Copilot ya tiene contexto sobre tu proyecto, el comando que falló y la salida del error. Sus sugerencias son específicas para tu situación, no documentación genérica.

Ejemplos reales donde brilla

Proveedor de recursos no registrado:

ERROR: deployment failed: MissingSubscriptionRegistration:
The subscription is not registered to use namespace 'Microsoft.App'.

Esto falla a cualquiera que despliega en una suscripción nueva. Copilot puede registrar el proveedor y relanzar el despliegue automáticamente.

SKU no disponible:

ERROR: deployment failed: SkuNotAvailable:
The requested VM size 'Standard_D2s_v3' is not available in location 'westus'.

Copilot explica qué tamaño de VM o región está bloqueado y sugiere alternativas disponibles en tu suscripción.

Colisión de nombre de cuenta de almacenamiento:

ERROR: deployment failed: StorageAccountAlreadyTaken:
The storage account named 'myappstorage' is already taken.

La unicidad global le pasa a todo el mundo al menos una vez. Copilot sugiere añadir el nombre del entorno o un sufijo aleatorio a tus parámetros Bicep.

Configurar un comportamiento predeterminado

Si siempre quieres la misma opción, salta el prompt interactivo:

azd config set copilot.errorHandling.category troubleshoot

Opciones: explain, guidance, troubleshoot, fix, skip. También puedes habilitar auto-fix y reintento:

azd config set copilot.errorHandling.fix allow

Vuelve al modo interactivo en cualquier momento:

azd config unset copilot.errorHandling.category

Por qué importa esto para los desarrolladores .NET

Si estás construyendo en Azure — ya sea una app .NET Aspire, una API en contenedor, o cualquier otra cosa — azd es la herramienta que debes conocer. Esta integración con Copilot elimina la última barrera de fricción que antes hacía que necesitaras una chuleta para empezar.

La pieza de scaffolding es genial para proyectos brownfield. Tienes una app ASP.NET Core funcionando localmente perfectamente, pero llevarla a Azure siempre ha requerido algo de conocimiento de infraestructura. Ahora Copilot tiende ese puente. Y la función de resolución de errores es algo que desearía haber tenido la última vez que pasé 45 minutos depurando un error SkuNotAvailable en tres regiones diferentes.

Conclusión

Esta es exactamente el tipo de integración de Copilot que aporta valor real — no IA por el gusto de la IA, sino IA que entiende tu contexto y te ahorra tiempo real. Pruébalo ejecutando azd update para obtener la última versión, y usa azd init en tu próximo proyecto. El equipo está trabajando en funciones más profundas incluyendo personalización de infraestructura asistida por Copilot, así que ahora es un buen momento para apuntarte a la investigación de usuarios.

Lee el anuncio original aquí.

Escribir addons nativos de Node.js en C# con .NET Native AOT

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

Este artículo fue traducido automáticamente. Para ver la versión original en inglés, haz clic aquí.

Este es un escenario que me encanta: un equipo que trabaja en herramientas .NET tenía addons nativos de Node.js escritos en C++ y compilados con node-gyp. Funcionaba. Pero requería instalar Python en la máquina de cada desarrollador — una versión antigua de Python, nada menos — solo para construir un paquete que nadie del equipo tocaría directamente.

Así que se hicieron una pregunta muy razonable: ya tenemos el SDK de .NET instalado, ¿por qué escribimos C++ en absoluto?

La respuesta fue Native AOT, y el resultado es genuinamente elegante. Drew Noakes del equipo de C# Dev Kit documentó cómo lo hicieron, y creo que vale la pena entenderlo aunque no estés construyendo extensiones de VS Code.

La idea básica

Un addon nativo de Node.js es una biblioteca compartida (.dll en Windows, .so en Linux, .dylib en macOS) que Node.js puede cargar en tiempo de ejecución. La interfaz se llama N-API — una API C estable y compatible con ABI. A N-API no le importa qué lenguaje produjo la biblioteca, solo que exporte los símbolos correctos.

.NET Native AOT puede producir exactamente eso. Compila tu código C# ahead-of-time en una biblioteca nativa compartida con puntos de entrada arbitrarios. Ese es todo el truco.

Configuración del proyecto

El archivo de proyecto es mínimo:

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

PublishAot indica al SDK que produzca una biblioteca compartida al ejecutar dotnet publish. AllowUnsafeBlocks es necesario para el interop con N-API que usa punteros a funciones y buffers fijos.

Exportar el punto de entrada

Node.js espera que tu biblioteca exporte napi_register_module_v1. En C#, [UnmanagedCallersOnly] hace exactamente eso:

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

Algunas cosas que vale la pena señalar: nint es un entero de tamaño nativo — el equivalente gestionado de intptr_t. El sufijo u8 produce un ReadOnlySpan<byte> con un literal de cadena UTF-8, pasado directamente a N-API sin ninguna asignación de codificación. Y [UnmanagedCallersOnly] exporta el método con el nombre de punto de entrada exacto que Node.js busca.

Resolver N-API contra el proceso host

Las funciones de N-API las exporta node.exe en sí mismo, no una biblioteca separada. Así que en lugar de enlazar contra algo, las resuelves contra el proceso en ejecución al inicio:

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 eso en su lugar, las declaraciones P/Invoke funcionan limpiamente, con [LibraryImport] y marshalling generado por código fuente.

Una función exportada real

Aquí está el lector de registro que construyeron — la función completa, desde leer argumentos hasta devolver un resultado:

[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 sobre el try/catch: una excepción no manejada en un método [UnmanagedCallersOnly] provoca el crash del proceso host. Siempre captura y reenvía a JavaScript mediante ThrowError.

Llamándolo desde TypeScript

interface RegistryAddon {
 readStringValue(keyPath: string, valueName: string): string | undefined;
}

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;

const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
 'InstallLocation'
);

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

Lo que ganaron

La victoria inmediata fue en la experiencia del contribuidor: ya no se necesita ninguna versión específica de Python, yarn install funciona solo con Node.js y el SDK de .NET. Los pipelines de CI también se simplificaron.

El rendimiento fue comparable a la implementación en C++. Native AOT produce código nativo optimizado, y para marshalling de cadenas y acceso al registro, la diferencia es insignificante.

Por qué me parece interesante más allá de las extensiones VS Code

Cualquier entorno que pueda cargar una biblioteca nativa compartida — apps Electron, extensiones Python vía ctypes, Rust vía FFI, Node.js vía N-API — es ahora un posible host para código C#. Para desarrolladores .NET que tenían escenarios de interop en mente pero no querían aprender un sistema de compilación C++, este patrón vale la pena conocerlo.

Conclusión

El equipo de C# Dev Kit reemplazó la sobrecarga de Python/C++ con código C# limpio que todo el equipo ya sabe escribir y depurar. Si quieres el recorrido completo con todos los helpers de marshalling de cadenas, consulta el artículo original en el blog de .NET.