Dotnet | The .NET Blog

Hooks d'azd en Python, TypeScript i .NET: adéu als scripts de shell

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Aquesta publicació ha estat traduïda automàticament. Per a la versió original, feu clic aquí.

Si alguna vegada has tingut un projecte completament en .NET i tot i així has hagut d’escriure scripts Bash per als hooks d’azd, coneixes bé aquell dolor. Per què canviar a sintaxi de shell en un pas de pre-provisioning quan tota la resta del projecte és C#?

Aquesta frustració té ara solució oficial. L’Azure Developer CLI acaba de llançar suport multi-llenguatge per a hooks, i és exactament tan bo com sona.

Hooks, breument

Els hooks són scripts que s’executen en punts clau del cicle de vida d’azd — abans del provisioning, després del desplegament, i més. Es defineixen a azure.yaml i permeten injectar lògica personalitzada sense modificar la CLI.

Abans només s’admetien Bash i PowerShell. Ara pots usar Python, JavaScript, TypeScript o .NET — i azd s’encarrega de la resta automàticament.

Com funciona la detecció

Simplement apuntes el hook a un fitxer i azd infereix el llenguatge per l’extensió:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Sense configuració addicional. Si l’extensió és ambigua, pots afegir kind: python (o el que correspongui) per especificar-ho explícitament.

Detalls importants per llenguatge

Python

Col·loca un requirements.txt o pyproject.toml al costat del script (o en qualsevol directori pare) i azd crea un entorn virtual, instal·la dependències i executa l’script.

JavaScript i TypeScript

El mateix patró — posa un package.json a prop del script i azd executarà npm install primer. Per a TypeScript, usa npx tsx sense pas de compilació ni tsconfig.json.

.NET

Dos modes disponibles:

Mode projecte: Si hi ha un .csproj al costat del script, azd executa dotnet restore i dotnet build automàticament.
Mode single-file: En .NET 10+, pots posar un fitxer .cs independent i s’executa directament amb dotnet run script.cs. Sense fitxer de projecte.

Configuració per executor

Cada llenguatge admet un bloc config opcional:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Per què importa per a desenvolupadors .NET

Els hooks eren l’últim lloc d’un projecte basat en azd que t’obligava a usar un altre llenguatge. Ara tot el pipeline de desplegament pot viure en un sol llenguatge. Pots reutilitzar les teves utilitats .NET existents als hooks, referenciar llibreries compartides i evitar el manteniment de scripts de shell.

Conclusió

És un d’aquells canvis que semblen petits però que eliminen molta fricció del dia a dia amb azd. El suport multi-llenguatge per a hooks ja està disponible — consulta el post oficial per a la documentació completa.

Windows App Dev CLI v0.3: F5 des del terminal i automatització de UI per a agents

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Aquesta publicació ha estat traduïda automàticament. Per a la versió original, feu clic aquí.

L’experiència F5 de Visual Studio és fantàstica. Però haver d’obrir VS només per llançar i depurar una app Windows empaquetada és excessiu quan estàs en un pipeline de CI, executant un workflow automatitzat, o quan un agent d’IA fa les proves.

Windows App Development CLI v0.3 acaba de sortir i ho aborda directament amb dues funcions destacades: winapp run i winapp ui.

winapp run: F5 des de qualsevol lloc

winapp run pren una carpeta d’app sense empaquetar i un manifest, i fa tot el que VS fa en un debug launch: registra un paquet loose, llança l’app i preserva el LocalState entre re-deploys.

winapp run ./bin/Debug

Funciona per a WinUI, WPF, WinForms, Console, Avalonia i més. Els modes estan pensats per a developers i workflows automatitzats:

--detach: Llança i retorna el control al terminal immediatament.
--unregister-on-exit: Neteja el paquet registrat en tancar l’app.
--debug-output: Captura missatges OutputDebugString i excepcions en temps real.

Nou paquet NuGet: dotnet run per a apps empaquetades

Per a developers .NET hi ha un nou paquet NuGet: Microsoft.Windows.SDK.BuildTools.WinApp. Afegeix-lo al projecte i dotnet run gestiona tot l’inner loop: build, preparar un paquet loose-layout, registrar a Windows i llançar — tot en un pas.

winapp init
# o
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: UI Automation des de la línia de comandes

winapp ui et dóna accés complet d’UI Automation a qualsevol app Windows en execució — WPF, WinForms, Win32, Electron, WinUI3. Pots llistar finestres, navegar l’arbre de UI Automation, trobar elements, fer clics, prendre captures de pantalla i esperar l’aparició d’elements.

Combina winapp ui amb winapp run i tens un workflow complet build → llançar → verificar des del terminal. Un agent pot executar la teva app, inspeccionar l’estat de la UI i validar el resultat.

Altres novetats

winapp unregister: Elimina un paquet sideloaded quan acabes.
winapp manifest add-alias: Afegeix un àlies per llançar l’app per nom des del terminal.
Tab completion: Configura completat amb una sola comanda per a PowerShell.

Com obtenir-ho

winget install Microsoft.WinAppCli
# o
npm install -g @microsoft/winappcli

Consulta el repositori a GitHub per a documentació completa i l’anunci original per a tots els detalls.

Deixeu de fer de cangur al vostre terminal: el mode desconnectat d'Aspire canvia el flux de treball

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Cada vegada que executeu un Aspire AppHost, el vostre terminal desapareixerà. Tancat. Ocupat fins que en feu Ctrl+C. Necessites executar una comanda ràpida? Obre una altra pestanya. Voleu comprovar els registres? Una altra pestanya. És una petita fricció que s’acumula ràpidament.

Aspire 13.2 soluciona això. James Newton-King va escriure tots els detalls, i sincerament, aquesta és una d’aquestes característiques que canvia immediatament la manera de treballar.

Mode desconnectat: una comanda, terminal enrere

aspire start

Aquesta és l’abreviatura de aspire run --detach. El vostre AppHost s’inicia en segon pla i recupereu el terminal immediatament. Sense pestanyes addicionals. Sense multiplexor de terminals. Només la teva indicació, llest per començar.

Gestionant el que s’està executant

Aquesta és la qüestió: executar-se en segon pla només és útil si realment podeu gestionar el que hi ha. Aspire 13.2 ofereix un conjunt complet d’ordres CLI per exactament això:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Això converteix l’Aspire CLI en un gestor de processos adequat. Podeu iniciar diversos AppHosts, comprovar el seu estat, seguir els seus registres i tancar-los, tot des d’una única sessió de terminal.

Combina-ho amb el mode aïllat

El mode separat es combina de manera natural amb el mode aïllat. Voleu executar dues instàncies del mateix projecte en segon pla sense conflictes de ports?

aspire start --isolated
aspire start --isolated

Cadascun obté ports aleatoris, secrets separats i el seu propi cicle de vida. Utilitzeu aspire ps per veure tots dos, aspire stop per matar el que hàgiu acabat.

Per què això és enorme per als agents de codificació

Aquí és on es posa realment interessant. Un agent de codificació que treballa al vostre terminal ara pot:

Inicieu l’aplicació amb aspire start
Consulta el seu estat amb aspire describe
Comproveu els registres amb aspire logs per diagnosticar problemes
Atureu-ho amb aspire stop quan estigui acabat

Tot sense perdre la sessió del terminal. Abans del mode desconnectat, un agent que executava el vostre AppHost es bloquejaria fora del seu propi terminal. Ara pot començar, observar, iterar i netejar, exactament com voldríeu que funcionés un agent autònom.

L’equip d’Aspire es va inclinar en això. L’execució de aspire agent init configura un fitxer d’habilitats d’Aspire que ensenya als agents aquestes ordres. Així, eines com l’agent de codificació de Copilot poden gestionar les vostres càrregues de treball d’Aspire des de la caixa.

Tancant

El mode desconnectat és una actualització del flux de treball disfressada com una simple bandera. Atureu el canvi de context entre terminals, els agents deixen de bloquejar-se i les noves ordres CLI us ofereixen una visibilitat real del que s’està executant. És pràctic, és net i fa que el cicle de desenvolupament diari sigui notablement més suau.

Llegiu la publicació completa per obtenir tots els detalls i agafeu Aspire 13.2 amb aspire update --self.

El clúster de pins finalment arriba als mapes.NET MAUI: una propietat, zero dolor

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Coneixes aquell moment en què carregues un mapa amb cent agulles i tot es converteix en una taca il·legible? Sí, aquesta ha estat l’experiència de.NET MAUI Maps fins ara. No més.

David Ortinau acaba d’anunciar que.NET MAUI 11 Preview 3 inclou pins agrupats fora de la caixa a Android i iOS/Mac Catalyst. I la millor part: activar-lo és ridículament senzill.

Una propietat per governar-les totes

<maps:Map IsClusteringEnabled="True" />

Això és tot. Els pins propers s’agrupen en grups amb una insígnia de recompte. Apropa i s’amplien. Allunya el zoom i es col·lapsen. El tipus de comportament que els usuaris esperen de qualsevol mapa modern, i ara ho obteniu amb una única propietat.

Grups de agrupació independents

Aquí és on es posa interessant. No tots els pins s’han d’agrupar. Les cafeteries i els parcs són coses diferents, i el vostre mapa ho hauria de saber.

La propietat ClusteringIdentifier us permet separar els pins en grups independents:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Pins amb el mateix grup d’identificadors junts. Els diferents identificadors formen clústers independents fins i tot quan estan geogràficament propers. Sense identificador? Grup per defecte. Net i previsible.

Gestió de les aixetes de clúster

Quan un usuari toca un clúster, obteniu un esdeveniment ClusterClicked amb tot el que necessiteu:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Els arguments de l’esdeveniment us proporcionen Pins (els pins del clúster), Location (el centre geogràfic) i Handled (establert a true si voleu anul·lar el zoom predeterminat). Senzill, pràctic, exactament el que esperaries.

Val la pena conèixer els detalls de la plataforma

A Android, la agrupació en clúster utilitza un algorisme personalitzat basat en quadrícula que recalcula els canvis de zoom, sense dependències externes. A iOS i Mac Catalyst, aprofita el suport natiu MKClusterAnnotation de MapKit, que significa animacions fluides i natives de la plataforma.

Aquest és un d’aquests casos en què l’equip de MAUI va fer la trucada correcta: recolzeu-vos a la plataforma on tingui sentit.

Per què això és important

La agrupació de pins ha estat una de les funcions més sol·licitades a.NET MAUI (issue #11811), i per una bona raó. Tota aplicació que mostra ubicacions en un mapa (seguiment de lliurament, localitzadors de botigues, béns immobles) ho necessita. Anteriorment, havíeu de crear-lo vosaltres mateixos o treure una biblioteca de tercers. Ara està incorporat.

Per als desenvolupadors de.NET que creem aplicacions mòbils multiplataforma, aquest és el tipus de millora de la qualitat de vida que fa que MAUI sigui una opció realment pràctica per a escenaris amb mapes pesats.

Comença

Instal·leu .NET 11 Preview 3 i actualitzeu la càrrega de treball.NET MAUI. La mostra de mapes inclou una nova pàgina de clúster amb la qual podeu jugar immediatament.

Aneu a construir alguna cosa amb ell i deixeu que els vostres mapes finalment respiren.

Manteniment de.NET d'abril de 2026: pegats de seguretat que hauríeu d'aplicar avui

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Les actualitzacions de servei d’abril de 2026 per a.NET i.NET Framework ja estan fora, i aquesta inclou solucions de seguretat que voldreu aplicar aviat. Sis CVE pegats, incloses dues vulnerabilitats d’execució de codi remota (RCE).

Què està pegat

Aquí teniu el resum ràpid:

CVE	Tipus	Afecta
CVE-2026-26171	Bypass de les funcions de seguretat	.NET 10, 9, 8 +.NET Framework
CVE-2026-32178	Execució de codi remota	.NET 10, 9, 8 +.NET Framework
CVE-2026-33116	Execució de codi remota	.NET 10, 9 i 8
CVE-2026-32203	Denegació de servei	.NET 10, 9, 8 +.NET Framework
CVE-2026-23666	Denegació de servei	.NET Framework 3.0–4.8.1
CVE-2026-32226	Denegació de servei	.NET Framework 2.0–4.8.1

Els dos CVE RCE (CVE-2026-32178 i CVE-2026-33116) afecten la gamma més àmplia de versions.NET i haurien de ser la prioritat.

Versions actualitzades

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Tots estan disponibles a través dels canals habituals: dotnet.microsoft.com, imatges de contenidors a MCR i gestors de paquets de Linux.

Què fer

Actualitzeu els vostres projectes i pipelines CI/CD a les últimes versions de pedaços. Si utilitzeu contenidors, traieu les imatges més recents. Si esteu a.NET Framework, consulteu les Notes de la versió de.NET Framework per trobar els pedaços corresponents.

Per a aquells que executen.NET 10 en producció (és la versió actual), 10.0.6 és una actualització obligatòria. El mateix per a.NET 9.0.15 i.NET 8.0.26 si esteu en aquestes pistes LTS. Dues vulnerabilitats RCE no són una cosa que posposeu.

L'Azure MCP Server 2.0 s'acaba de caure: l'automatització del núvol agent autoallotjada és aquí

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

Si darrerament heu estat creant alguna cosa amb MCP i Azure, probablement ja sabeu que l’experiència local funciona bé. Connecteu un servidor MCP, deixeu que el vostre agent d’IA parli amb els recursos d’Azure, seguiu endavant. Però, en el moment que necessiteu compartir aquesta configuració amb un equip? Allà va ser on les coses es van complicar.

Ja no. Servidor MCP d’Azure acaba d’aconseguir 2.0 estable, i la funció de titular és exactament el que els equips empresarials han demanat: suport del servidor MCP remot autoallotjat.

Què és Azure MCP Server?

Actualització ràpida. Azure MCP Server implementa l’especificació Model Context Protocol i exposa les capacitats d’Azure com a eines estructurades i detectables que els agents d’IA poden invocar. Penseu en això com un pont estandarditzat entre el vostre agent i Azure: subministrament, desplegament, supervisió, diagnòstic, tot mitjançant una interfície coherent.

Les xifres parlen per si soles: 276 eines MCP en 57 serveis Azure. Això és una cobertura seriosa.

El gran problema: desplegaments remots autoallotjats

Aquí està la cosa. Executar MCP localment a la vostra màquina està bé per a desenvolupament i experiments. Però en un escenari d’equip real, necessiteu:

Accés compartit per a desenvolupadors i sistemes d’agents interns
Configuració centralitzada (context de l’arrendatari, valors predeterminats de subscripció, telemetria)
Xarxa empresarial i límits polítics
Integració en pipelines CI/CD

Azure MCP Server 2.0 aborda tot això. Podeu implementar-lo com a servei intern gestionat de manera centralitzada amb transport basat en HTTP, autenticació adequada i govern coherent.

Per a l’autenticació, obteniu dues opcions sòlides:

Identitat gestionada: quan s’executa al costat de Microsoft Foundry
Flux en nom de (OBO): delegació d’OpenID Connect que crida a les API d’Azure mitjançant el context de l’usuari iniciat

Aquest flux OBO és especialment interessant per als desenvolupadors de.NET. Vol dir que els vostres fluxos de treball d’agent poden funcionar amb els permisos reals de l’usuari, no amb un compte de servei amb privilegis excessius. Principi del mínim privilegi, integrat.

Enduriment de la seguretat

Això no és només una versió de funcions, també és una de seguretat. La versió 2.0 afegeix:

Validació de punt final més forta
Proteccions contra patrons d’injecció en eines orientades a la consulta
Controls d’aïllament més estrictes per a entorns de desenvolupament

Si voleu exposar MCP com a servei compartit, aquestes garanties són importants. Molts.

On el pots utilitzar?

La història de la compatibilitat del client és àmplia. Azure MCP Server 2.0 funciona amb:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agents CLI: GitHub Copilot CLI, Claude Code
Autònom: servidor local per a configuracions senzilles
Control remot autoallotjat: la nova estrella de la 2.0

A més, hi ha suport sobirà al núvol per al govern d’Azure dels Estats Units i Azure operat per 21Vianet, que és fonamental per als desplegaments regulats.

Per què això és important per als desenvolupadors de.NET

Si esteu creant aplicacions agents amb.NET, ja sigui el nucli semàntic, el Microsoft Agent Framework o la vostra pròpia orquestració, Azure MCP Server 2.0 us ofereix una manera preparada per a la producció de permetre que els vostres agents interactuïn amb la infraestructura Azure. No hi ha embolcalls REST personalitzats. No hi ha patrons d’integració específics del servei. Només MCP.

Combinat amb l’API fluida per a aplicacions MCP que va caure fa uns dies, l’ecosistema.NET MCP està madurant ràpidament.

Primers passos

Tria el teu camí:

GitHub Repo — codi font, documents, tot
Imatge Docker — desplegament en contenidors
Extensió de codi VS — Integració IDE
Guia d’allotjament personal: la funció insígnia 2.0

Tancant

Azure MCP Server 2.0 és exactament el tipus d’actualització d’infraestructura que no sembla cridaner en una demostració, però que ho canvia tot a la pràctica. MCP remot autoallotjat amb autenticació adequada, reforç de la seguretat i suport sobirà del núvol significa que MCP està preparat per a equips reals que creen fluxos de treball reals a l’Azure. Si heu estat esperant el senyal “preparat per a l’empresa”, això és tot.

.NET Aspire 13.2 vol ser el millor amic del vostre agent d'IA

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Coneixeu aquell moment en què el vostre agent de codificació d’IA escriu un codi sòlid, us emocioneu i després es desfà completament intentant executar la cosa? Conflictes de ports, processos fantasma, variables d’entorn incorrectes: de sobte, el vostre agent està cremant fitxes per resoldre problemes d’inici en lloc de crear funcions.

L’equip d’Aspire acaba de publicar una publicació molt atenta sobre exactament aquest problema, i la seva resposta és convincent: Aspire 13.2 està dissenyat no només per a humans, sinó per a agents d’IA.

El problema és real

Els agents d’IA són increïbles per escriure codi. Però enviar una aplicació de pila completa que funcioni implica molt més que generar fitxers. Heu d’iniciar els serveis en l’ordre correcte, gestionar ports, establir variables d’entorn, connectar bases de dades i obtenir comentaris quan les coses es trenquin. Ara mateix, la majoria d’agents gestionen tot això mitjançant prova i error: executant ordres, llegint la sortida d’error, tornant-ho a provar.

Superposem instruccions de Markdown, habilitats personalitzades i indicacions per intentar guiar-les, però són imprevisibles, no es poden compilar i costen fitxes només per analitzar-les. L’equip d’Aspire va clavar la visió bàsica: els agents necessiten compiladors i API estructurades, no més Markdown.

Aspira com a infraestructura d’agents

Això és el que aporta Aspire 13.2 a la taula de desenvolupament agent:

La vostra pila sencera en codi escrit. L’AppHost defineix la vostra topologia completa: API, frontend, base de dades, memòria cau, en TypeScript o C# compilable:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agent pot llegir-ho per entendre la topologia de l’aplicació, afegir recursos, connectar connexions i crear per verificar. El compilador li indica immediatament si alguna cosa no funciona. Sense endevinar, sense prova i error amb fitxers de configuració.

Una comanda per governar-los tots. En lloc d’agents que fan malabars amb docker compose up, npm run dev i scripts d’inici de bases de dades, tot és només aspire start. Tots els recursos s’inicien en l’ordre correcte, als ports adequats, amb la configuració correcta. Els processos de llarga durada tampoc pengen l’agent: Aspire els gestiona.

Mode aïllat per a agents paral·lels. Amb --isolated, cada execució d’Aspire té els seus propis ports aleatoris i secrets d’usuari separats. Hi ha diversos agents treballant en els arbres de treball de git? No xocaran. Això és enorme per a eines com els agents de fons de VS Code que fan girar entorns paral·lels.

Ulls d’agent a través de la telemetria. Aquí és on es fa realment potent. L’Aspire CLI exposa dades completes d’OpenTelemetry durant el desenvolupament: traces, mètriques, registres estructurats. El vostre agent no només llegeix la sortida de la consola i espera el millor. Pot rastrejar una sol·licitud fallida entre serveis, perfilar punts finals lents i identificar exactament on es trenquen les coses. Això és observabilitat de grau de producció en el bucle de desenvolupament.

L’analogia del para-xocs de bitlles

L’equip d’Aspire utilitza una gran analogia: penseu en Aspire com a para-xocs de la pista de bitlles per als agents d’IA. Si l’agent no és perfecte (i no ho serà), els para-xocs eviten que llanci boles de canaló. La definició de pila evita la configuració incorrecta, el compilador detecta errors, la CLI gestiona la gestió del procés i la telemetria proporciona el bucle de retroalimentació.

Combineu-ho amb alguna cosa com Playwright CLI i el vostre agent pot utilitzar la vostra aplicació: fent clic a través dels fluxos, comprovant el DOM, veient coses trencades a la telemetria, arreglant el codi, reiniciant i provant de nou. Construir, executar, observar, arreglar. Aquest és el bucle de desenvolupament autònom que hem estat perseguint.

Primers passos

Nou a Aspire? Instal·leu la CLI des de get.aspire.dev i seguiu la guia d’inici.

Ja fas servir Aspire? Executeu aspire update --self per obtenir 13.2 i, a continuació, indiqueu el vostre agent de codificació preferit al vostre repositori. Potser us sorprendrà quant s’avança amb les baranes d’Aspire al seu lloc.

Tancant

Aspire 13.2 ja no és només un marc d’aplicacions distribuïdes, sinó que s’està convertint en una infraestructura d’agent essencial. Les definicions de pila estructurades, l’inici d’un sol comandament, les execucions paral·leles aïllades i la telemetria en temps real ofereixen als agents d’IA exactament el que necessiten per passar d’escriure codi a enviar aplicacions.

Llegiu la publicació completa de l’equip d’Aspire per veure tots els detalls i vídeos de demostració.

Connecteu els vostres servidors MCP a les funcions d'Azure amb els agents de Foundry: aquí teniu com

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Aquí hi ha una cosa que m’encanta de l’ecosistema MCP: creeu el vostre servidor una vegada i funciona a tot arreu. VS Code, Visual Studio, Cursor, ChatGPT: cada client MCP pot descobrir i utilitzar les vostres eines. Ara, Microsoft afegeix un altre consumidor a aquesta llista: agents de Foundry.

Lily Ma de l’equip d’Azure SDK va publicar una guia pràctica sobre la connexió de servidors MCP desplegats a Azure Functions amb agents de Microsoft Foundry. Si ja teniu un servidor MCP, això és pur valor afegit, no cal reconstruir-lo.

Per què aquesta combinació té sentit

Azure Functions us ofereix una infraestructura escalable, una autenticació integrada i una facturació sense servidor per allotjar servidors MCP. Microsoft Foundry us ofereix agents d’IA que poden raonar, planificar i prendre accions. Connectar les dues significa que les vostres eines personalitzades (consultar una base de dades, trucar a una API empresarial, executar una lògica de validació) esdevenen capacitats que els agents d’IA empresarials poden descobrir i utilitzar de manera autònoma.

El punt clau: el vostre servidor MCP es manté igual. Només esteu afegint Foundry com un altre consumidor. Les mateixes eines que funcionen a la configuració de VS Code ara alimenten un agent d’IA amb el qual interactuen el vostre equip o clients.

Opcions d’autenticació

Aquí és on la publicació realment afegeix valor. Quatre mètodes d’autenticació segons el vostre escenari:

Mètode	Cas d’ús
Basat en clau (per defecte)	Desenvolupament o servidors sense autenticació Entra
Entrada de Microsoft	Producció amb identitats gestionades
Transmissió d’identitat OAuth	Producció on cada usuari s’autentica individualment
No autenticat	Desenvolupament/proves o dades públiques només

Per a la producció, el camí recomanat és Microsoft Entra amb la identitat de l’agent. El pas d’identitat d’OAuth és per quan el context de l’usuari importa: l’agent demana als usuaris que iniciïn sessió i cada sol·licitud porta el testimoni propi de l’usuari.

Configurant-lo

El flux d’alt nivell:

Implementeu el vostre servidor MCP a Azure Functions: mostres disponibles per a .NET, Python, TypeScript i Java
Activa l’autenticació MCP integrada a l’aplicació de funcions
Obteniu l’URL del vostre punt final — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Afegiu el servidor MCP com a eina a Foundry: aneu al vostre agent al portal, afegiu una eina MCP nova, proporcioneu el punt final i les credencials.

A continuació, proveu-ho al parc infantil de l’Agent Builder enviant un missatge que activaria una de les vostres eines.

La meva opinió

La història de la composició aquí s’està fent molt forta. Creeu el vostre servidor MCP una vegada a.NET (o Python, TypeScript, Java), implementeu-lo a Azure Functions i tots els clients compatibles amb MCP el podran utilitzar: eines de codificació, aplicacions de xat i ara agents d’IA empresarials. Aquest és un patró “Escriu una vegada, utilitza a tot arreu” que realment funciona.

Per als desenvolupadors de.NET específicament, l’extensió MCP d’Azure Functions ho fa senzill. Definiu les vostres eines com a Azure Functions, les implementeu i disposeu d’un servidor MCP de nivell de producció amb tota la seguretat i escala que ofereix Azure Functions.

Tancant

Si teniu eines MCP que s’executen a Azure Functions, connectar-les als agents de Foundry és una victòria ràpida: les vostres eines personalitzades es converteixen en capacitats d’IA empresarial amb una autenticació adequada i sense canvis de codi al propi servidor.

Llegiu la guia completa per obtenir instruccions pas a pas sobre cada mètode d’autenticació i consulteu la documentació detallada per a les configuracions de producció.

El mode aïllat d'Aspire soluciona el malson del conflicte del port per al desenvolupament paral·lel

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Si alguna vegada has provat d’executar dues instàncies del mateix projecte al mateix temps, saps el dolor. El port 8080 ja està en ús. S’ha pres el port 17370. Matar alguna cosa, reiniciar, fer malabars amb les variables d’entorn: és un assassí de la productivitat.

Aquest problema empitjora, no millora. Els agents d’IA creen arbres de treball git per treballar de manera independent. Els agents de fons generen entorns separats. Els desenvolupadors comproven el mateix repositori dues vegades per a les branques de funcions. Cadascun d’aquests escenaris toca el mateix mur: dues instàncies de la mateixa aplicació lluitant pels mateixos ports.

Aspire 13.2 soluciona això amb una sola bandera. James Newton-King de l’equip d’Aspire va escriure tots els detalls, i és una d’aquestes característiques de “per què no vam tenir això abans”.

La correcció: `--isolated`

aspire run --isolated

Això és tot. Cada cursa obté:

Ports aleatoris: no hi ha més col·lisions entre instàncies
Secrets d’usuari aïllats: les cadenes de connexió i les claus API es mantenen separades per instància

No hi ha reasignació manual del port. Sense malabars amb variables d’entorn. Cada cursa obté un entorn fresc i lliure de col·lisions automàticament.

Escenaris reals on això brilla

Múltiples pagaments. Tens una branca de funcions en un directori i una correcció d’errors en un altre:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Tots dos funcionen sense conflictes. El tauler mostra què s’està executant i on.

Agents de fons a VS Code. Quan l’agent de fons de Copilot Chat crea un arbre de treball git per treballar amb el vostre codi de manera independent, pot ser que hagi d’executar l’Aspire AppHost. Sense --isolated, això és una col·lisió de port amb el vostre arbre de treball principal. Amb ell, ambdues instàncies només funcionen.

L’habilitat d’Aspire que s’envia amb aspire agent init indica automàticament als agents que utilitzin --isolated quan treballen en arbres de treball. Per tant, l’agent de fons de Copilot hauria de gestionar-ho des de la caixa.

Proves d’integració juntament amb el desenvolupament. Necessites fer proves amb un AppHost en directe mentre continues creant funcions? El mode aïllat dóna a cada context els seus propis ports i configuració.

Com funciona sota el capó

Quan passeu --isolated, la CLI genera un ID d’instància únic per a l’execució. Això provoca dos comportaments:

Aleatoria de ports: en lloc d’unir-se a ports previsibles definits a la configuració de l’AppHost, el mode aïllat tria els ports disponibles aleatòriament per a tot: el tauler de control, els punts finals del servei, tot això. El descobriment de serveis s’ajusta automàticament, de manera que els serveis es troben entre ells independentment dels ports on aterren.
Aïllament secret: cada execució aïllada obté el seu propi magatzem de secrets d’usuari, clau per l’ID de la instància. Les cadenes de connexió i les claus API d’una execució no es filtren a una altra.

El vostre codi no necessita cap canvi. El descobriment de serveis d’Aspire resol els punts finals en temps d’execució, de manera que tot es connecta correctament independentment de l’assignació del port.

Quan utilitzar-lo

Utilitzeu --isolated quan executeu diverses instàncies del mateix AppHost simultàniament, tant si es tracta de desenvolupament paral·lel, proves automatitzades, agents d’IA o arbres de treball de git. Per al desenvolupament d’una sola instància on preferiu ports previsibles, aspire run normal encara funciona bé.

Tancant

El mode aïllat és una petita característica que resol un problema real i cada cop més comú. A mesura que el desenvolupament assistit per IA ens empeny cap a fluxos de treball més paral·lels (múltiples agents, múltiples arbres de treball, múltiples contextos), la capacitat de fer girar una altra instància sense lluitar pels ports és essencial.

Llegiu la publicació completa per obtenir tots els detalls tècnics i proveu-ho amb aspire update --self per obtenir 13.2.

L'avaluació de la modernització de GitHub Copilot és la millor eina de migració que encara no feu servir

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Migrar una aplicació.NET Framework heretada a.NET moderna és una d’aquestes tasques que tothom sap que hauria de fer, però ningú vol començar. Mai és només “canviar el marc objectiu”. Són les API que van desaparèixer, paquets que ja no existeixen, models d’allotjament que funcionen d’una manera completament diferent i un milió de petites decisions sobre què contener, què reescriure i què deixar en pau.

Jeffrey Fritz acaba de publicar una immersió profunda en l’avaluació de la modernització de GitHub Copilot, i sincerament? Aquesta és la millor eina de migració que he vist per a.NET. No a causa de la generació de codi, això és ara l’aposta de la taula. Pel document d’avaluació que elabora.

No és només un motor de suggeriments de codi

L’extensió VS Code segueix un model Avaluar → Planificar → Executar. La fase d’avaluació analitza tota la vostra base de codi i produeix un document estructurat que ho recull tot: què cal canviar, quins recursos d’Azure proveir, quin model de desplegament utilitzar. Tot el que hi ha a baix (infraestructura com a codi, contenidors, manifestos de desplegament) depèn del que troba l’avaluació.

L’avaluació s’emmagatzema a .github/modernize/assessment/ del vostre projecte. Cada execució produeix un informe independent, de manera que creeu un historial i podeu fer un seguiment de com evoluciona la vostra postura de migració a mesura que solucioneu els problemes.

Dues maneres de començar

Avaluació recomanada: el camí ràpid. Trieu entre dominis seleccionats (actualització de Java/.NET, preparació al núvol, seguretat) i obteniu resultats significatius sense tocar la configuració. Ideal per a una primera mirada a on es troba la teva aplicació.

Avaluació personalitzada: el camí objectiu. Configureu exactament què voleu analitzar: càlcul objectiu (App Service, AKS, Container Apps), sistema operatiu objectiu, anàlisi de contenidors. Trieu diversos objectius d’Azure per comparar els enfocaments de migració de manera conjunta.

Aquesta visió de comparació és realment útil. Una aplicació amb 3 problemes obligatoris per a App Service pot tenir 7 per a AKS. Veure tots dos ajuda a impulsar la decisió d’allotjament abans de comprometre’s amb una ruta de migració.

El desglossament del problema és accionable

Cada problema ve amb un nivell de criticitat:

Obligatori: s’ha de solucionar o la migració falla
Potencial: pot afectar la migració, necessita el judici humà
Opcional: millores recomanades, no bloquejaran la migració

I cada problema enllaça amb fitxers i números de línia afectats, proporciona una descripció detallada del que està malament i per què és important per a la vostra plataforma objectiu, ofereix passos concrets de correcció (no només “arreglar-ho”) i inclou enllaços a documentació oficial.

Podeu lliurar problemes individuals als desenvolupadors i aquests tenen tot el que necessiten per actuar. Aquesta és la diferència entre una eina que us diu “hi ha un problema” i una que us indica com resoldre’l.

Els camins d’actualització coberts

Específicament per a.NET: -.NET Framework →.NET 10

ASP.NET → ASP.NET Core

Cada camí d’actualització té regles de detecció que coneixen quines API s’han eliminat, quins patrons no tenen cap equivalent directe i quins problemes de seguretat necessiten atenció.

Per als equips que gestionen diverses aplicacions, també hi ha una CLI que admet avaluacions per lots multirepositori: cloneu tots els repositoris, avalueu-los tots, obteniu informes per aplicació i una visualització de cartera agregada.

La meva opinió

Si esteu asseguts en aplicacions heretades de.NET Framework (i siguem reals, la majoria dels equips empresarials ho són), aquesta és l’eina per començar. Només el document d’avaluació val la pena el temps: converteix un vague “hauríem de modernitzar” en una llista concreta i prioritzada d’elements de treball amb camins clars.

El flux de treball col·laboratiu també és intel·ligent: exporteu avaluacions, compartiu amb el vostre equip, importeu-les sense tornar-les a executar. Revisions d’arquitectura on els que prenen les decisions no són els que executen les eines? Coberta.

Tancant

L’avaluació de la modernització de GitHub Copilot transforma la migració.NET d’un projecte aterridor i indefinit a un procés estructurat i rastrejable. Comenceu amb una avaluació recomanada per veure on us trobeu i, a continuació, utilitzeu avaluacions personalitzades per comparar els objectius d’Azure i crear el vostre pla de migració.

Llegiu el tutorial complet i agafeu l’extensió del codi VS per provar-ho a la vostra pròpia base de codi.

Les aplicacions MCP obtenen una API fluida: creeu interfícies d'usuari d'eines d'IA rica a.NET amb tres passos

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Les eines MCP són excel·lents per oferir capacitats als agents d’IA. Però, què passa si la vostra eina ha de mostrar alguna cosa a l’usuari: un tauler, un formulari, una visualització interactiva? Aquí és on entren les aplicacions MCP i són molt més fàcils de crear.

Lilian Kasem de l’equip de l’SDK d’Azure va presentar la nova API de configuració fluida per a les aplicacions MCP a.NET Azure Functions, i és el tipus de millora de l’experiència dels desenvolupadors que us fa preguntar-vos per què no sempre va ser tan senzill.

Què són les aplicacions MCP?

Les aplicacions MCP amplien el protocol de context del model deixant que les eines portin les seves pròpies vistes d’interfície d’usuari, actius estàtics i controls de seguretat. En lloc de només retornar text, la vostra eina MCP pot representar experiències HTML completes (taulers interactius, visualitzacions de dades, formularis de configuració), tot això invocable pels agents d’IA i presentat als usuaris pels clients MCP.

El problema va ser que el cablejat de tot això manualment requeria conèixer íntimament les especificacions MCP: ui:// URI, tipus de mime especials, coordinació de metadades entre eines i recursos. No és difícil, però complicat.

L’API fluida en tres passos

Pas 1: defineix la teva funció. Només una eina MCP estàndard d’Azure Functions:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Pas 2: promocioneu-lo a una aplicació MCP. A l’inici del vostre programa:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Pas 3: afegiu la vostra vista HTML. Creeu assets/hello-app.html amb la interfície d’usuari que necessiteu.

Això és tot. L’API fluida gestiona tota la fontaneria d’especificacions MCP: genera la funció de recursos sintètics, estableix el tipus de mime correcte, injecta les metadades que connecten l’eina a la seva vista.

La superfície de l’API està ben dissenyada

Algunes coses que m’agraden molt:

Les fonts de visualització són flexibles. Podeu publicar HTML des de fitxers al disc o inserir recursos directament al vostre conjunt per a desplegaments autònoms:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP es pot redactar. Llista de permisos explícita que els orígens de la teva aplicació necessita, seguint els principis de privilegis mínims. Truqueu a WithCsp diverses vegades i els orígens s’acumulen:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Control de visibilitat. Podeu fer que una eina només sigui visible per al LLM, només per a la interfície d’usuari de l’amfitrió o ambdues. Voleu una eina que només representi la interfície d’usuari i que el model no l’hagi de cridar? Fàcil:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Primers passos

Afegeix el paquet de previsualització:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Si ja esteu creant eines MCP amb Azure Functions, això és només una actualització del paquet. El inici ràpid de les aplicacions MCP és el millor lloc per començar si sou nou al concepte.

Tancant

Les aplicacions MCP són un dels desenvolupaments més interessants de l’espai d’eines d’IA: eines que no només * fan coses * sinó que poden * mostrar coses * als usuaris. L’API fluida elimina la complexitat del protocol i us permet centrar-vos en allò que importa: la lògica de l’eina i la seva interfície d’usuari.

Llegiu la publicació completa per obtenir la referència completa de l’API i els exemples.

C# 15 obté tipus d'unió, i són exactament el que hem estat demanant

Emiliano Montesdeoca — Sun, 05 Apr 2026 00:00:00 +0000

Aquest és el que estava esperant. C# 15 introdueix la paraula clau union: unions discriminades adequades amb una concordança exhaustiva de patrons forçada pel compilador. Si alguna vegada has envejat els sindicats discriminats de F# o les enumeracions de Rust, saps exactament per què això importa.

Bill Wagner va publicar la immersió profunda al bloc.NET, i sincerament? El disseny és net, pràctic i molt C#. Permeteu-me explicar-vos què hi ha realment aquí i per què és una cosa més gran del que pot semblar a primera vista.

El problema que resolen els sindicats

Abans de C# 15, retornar “un dels diversos tipus possibles” d’un mètode sempre era un compromís:

object — sense restriccions, sense ajuda del compilador, llançament defensiu a tot arreu
Interfícies de marcador: millor, però qualsevol pot implementar-les. El compilador mai pot considerar el conjunt complet
Classes base abstractes: el mateix problema, a més els tipus necessiten un avantpassat comú

Cap d’aquests us ofereix el que realment voleu: un conjunt tancat de tipus on el compilador garanteix que heu gestionat tots els casos. Això és el que fan els sindicats.

La sintaxi és molt senzilla

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Una línia. Pet pot contenir un Cat, un Dog o un Bird. Les conversions implícites es generen automàticament:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

I aquí està la màgia: el compilador imposa una concordança exhaustiva:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

No cal descartar _. El compilador sap que aquest commutador cobreix tots els casos possibles. Si més tard afegiu un quart tipus a la unió, cada expressió de commutació que no la gestioni produeix un avís. Casos que falten capturats en temps de compilació, no en temps d’execució.

On això es fa pràctic

L’exemple Pet és bonic, però aquí és on els sindicats realment brillen en codi real.

Respostes de l’API que retornen diferents formes

public union ApiResult<T>(T, ApiError, ValidationFailure);

Ara tots els consumidors es veuen obligats a gestionar l’èxit, l’error i el fracàs de validació. No hi ha més errors “m’he oblidat de comprovar el cas d’error”.

Valor únic o col·lecció

El patró OneOrMore<T> mostra com els sindicats poden tenir un cos amb mètodes auxiliars:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Les persones que trucen passen el formulari que sigui convenient:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Composició de tipus no relacionats

Aquesta és la característica assassina de les jerarquies tradicionals. Podeu unir tipus que no tenen res en comú: string i Exception, int i IEnumerable<T>. No es necessita cap avantpassat comú.

Unions personalitzades per a biblioteques existents

Aquí teniu una opció de disseny intel·ligent: qualsevol classe o estructura amb un atribut [Union] es reconeix com a tipus d’unió, sempre que segueixi el patró bàsic (constructors públics per a tipus de casos i una propietat Value). Les biblioteques com OneOf que ja proporcionen tipus d’unió poden optar al suport del compilador sense reescriure els seus elements interns.

Per a escenaris sensibles al rendiment amb tipus de valors, les biblioteques poden implementar un patró d’accés que no sigui boxing amb mètodes HasValue i TryGetValue.

La imatge més gran

Els tipus d’unió formen part d’una història d’exhaustivitat més àmplia que arriba a C#:

Tipus d’unió: concordança exhaustiva sobre un conjunt tancat de tipus (disponible ara a la vista prèvia)
Jerarquies tancades — El modificador closed impedeix classes derivades fora del conjunt definidor (proposat)
Enumeracions tancades: impedeix la creació de valors diferents dels membres declarats (proposat)

En conjunt, aquestes tres funcions donaran a C# un dels sistemes de concordança de patrons segurs de tipus més complets en qualsevol llenguatge convencional.

Prova-ho avui

Els tipus d’unió estan disponibles a.NET 11 Preview 2:

Instal·leu .NET 11 Preview SDK
Orienta net11.0 al teu projecte
Establiu <LangVersion>preview</LangVersion>

Una advertència: a la vista prèvia 2, haureu de declarar UnionAttribute i IUnion al vostre projecte, ja que encara no estan en temps d’execució. Agafeu RuntimePolyfill.cs del dipòsit de documents o afegiu això:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Tancant

Els tipus d’unió són una d’aquestes característiques que us fan preguntar-vos com ens ho hem passat sense ells. Coincidència exhaustiva forçada pel compilador, sintaxi neta, suport genèric i integració amb la concordança de patrons existents: és tot el que hem estat demanant, fet de la manera C#.

Proveu-los a.NET 11 Preview 2, trenca coses i compartiu els vostres comentaris a GitHub. Aquesta és una vista prèvia i l’equip de C# escolta activament. Els vostres casos de punta i els vostres comentaris sobre el disseny donaran forma a la versió final.

Per obtenir la referència completa de l’idioma, consulteu els documents de tipus unió i l’especificació de la funció.

Aspire 13.2 envia una CLI de Docs, i el vostre agent d'IA també la pot utilitzar

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

Coneixeu aquell moment en què esteu endinsat en un Aspire AppHost, connectant integracions i heu de comprovar exactament quins paràmetres espera la integració de Redis? Feu una pestanya alternativa al vostre navegador, busqueu aspire.dev, mireu els documents de l’API i torneu al vostre editor. Context perdut. Flux trencat.

Aspire 13.2 només ha enviat una solució per això. La CLI aspire docs us permet cercar, navegar i llegir la documentació oficial d’Aspire directament des del vostre terminal. I com que està recolzat per serveis reutilitzables, els agents i les habilitats d’IA poden utilitzar les mateixes ordres per buscar documents en lloc d’al·lucinar API que no existeixen.

El problema que això resol realment

David Pine ho clava a la publicació original: els agents d’IA van ser terribles per ajudar els desenvolupadors a crear aplicacions Aspire. Recomanarien dotnet run en lloc de aspire run, fer referència a learn.microsoft.com per als documents que viuen a aspire.dev, suggerir paquets NuGet obsolets i, el meu favorit personal, al·lucinar API que no existeixen.

Per què? Com que Aspire era específic de.NET molt més temps del que ha estat políglot, i els LLM treballen amb dades de formació anteriors a les últimes funcions. Quan doneu a un agent d’IA la possibilitat de buscar realment els documents actuals, deixa d’endevinar i comença a ser útil.

Tres ordres, zero pestanyes del navegador

La CLI és molt senzilla:

Llista tots els documents

aspire docs list

Retorna totes les pàgines de documentació disponibles a aspire.dev. Necessites una sortida llegible per màquina? Afegeix --format Json.

Cerca un tema

aspire docs search "redis"

Cerca tant títols com contingut amb una puntuació de rellevància ponderada. El mateix motor de cerca que impulsa l’eina de documentació internament. Obteniu resultats classificats amb títols, slugs i puntuacions de rellevància.

Llegeix una pàgina sencera (o només una secció)

aspire docs get redis-integration

Transmet la pàgina completa com a reducció al terminal. Necessites només una secció?

aspire docs get redis-integration --section "Add Redis resource"

Precisió quirúrgica. Sense desplaçament per 500 línies. Només la part que necessiteu.

L’angle de l’agent d’IA

Aquí és on és interessant per als desenvolupadors que construïm amb eines d’IA. Les mateixes ordres aspire docs funcionen com a eines per als agents d’IA, mitjançant habilitats, servidors MCP o embolcalls CLI senzills.

En comptes que el vostre assistent d’IA creï les API d’Aspire basades en dades d’entrenament obsoletes, pot trucar a aspire docs search "postgres", trobar els documents oficials d’integració, llegir la pàgina adequada i oferir-vos l’enfocament documentat. Documentació actual en temps real, no la que el model va memoritzar fa sis mesos.

L’arquitectura darrere d’això és intencionada. L’equip d’Aspire va crear serveis reutilitzables (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) en lloc d’una integració única. Això vol dir que el mateix motor de cerca funciona per a humans al terminal, agents d’IA al vostre editor i automatització al vostre pipeline CI.

Escenaris del món real

Cerques ràpides del terminal: Teniu tres fitxers de profunditat i necessiteu paràmetres de configuració de Redis. Dues ordres, noranta segons, tornen a treballar:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Desenvolupament assistit per IA: la vostra habilitat VS Code inclou les ordres CLI. Demaneu “Afegeix una base de dades PostgreSQL al meu AppHost” i l’agent cerca els documents reals abans de respondre. Sense al·lucinacions.

Validació CI/CD: el vostre pipeline valida les configuracions d’AppHost amb la documentació oficial mitjançant programació. --format Json emet les canonades netament a jq i altres eines.

Bases de coneixement personalitzades: crear la teva pròpia eina d’IA? Introduïu la sortida JSON estructurada directament a la vostra base de coneixement:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Sense raspat web. No hi ha claus API. Les mateixes dades estructurades que les eines de documents utilitza internament.

La documentació sempre està en directe

Aquesta és la part que més agraeixo. La CLI no baixa cap instantània: consulta aspire.dev amb la memòria cau basada en ETag. En el moment en què s’actualitzen els documents, la vostra CLI i qualsevol habilitat incorporada al damunt ho reflecteixen. No hi ha còpies obsoletes, no “però el wiki va dir…” moments.

Tancant

aspire docs és una d’aquestes petites característiques que resol un problema real de manera neta. Els humans tenen accés a la documentació nativa del terminal. Els agents d’IA tenen una manera de deixar d’endevinar i començar a fer referència a documents reals. I tot està recolzat per la mateixa font de veritat.

Si esteu creant amb.NET Aspire i encara no heu provat la CLI, executeu aspire docs search "your-topic-here" i mireu com us sembla. A continuació, considereu incloure aquestes ordres en qualsevol habilitat d’IA o configuració d’automatització que feu servir; els vostres agents us ho agrairan.

Fes una ullada a La immersió profunda de David Pine sobre com es van reunir les eines de documents i la referència oficial de la CLI per a tots els detalls.

Microsoft Agent Framework Hits 1.0: això és el que realment importa per als desenvolupadors de.NET

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

Si heu estat seguint el viatge de l’Agent Framework des dels primers dies del nucli semàntic i de l’AutoGen, aquest és significatiu. Microsoft Agent Framework només accedir a la versió 1.0: API estables, preparades per a la producció, compromís de suport a llarg termini. Està disponible tant per a.NET com per a Python, i està realment preparat per a càrregues de treball reals.

Permeteu-me reduir el soroll de l’anunci i centrar-me en allò que importa si esteu creant aplicacions basades en IA amb.NET.

La versió curta

Agent Framework 1.0 unifica el que abans era Semantic Kernel i AutoGen en un únic SDK de codi obert. Abstracció d’un agent. Un motor d’orquestració. Diversos proveïdors d’IA. Si heu estat rebotant entre el nucli semàntic per a patrons empresarials i AutoGen per a fluxos de treball multiagent de grau de recerca, podeu aturar-vos. Aquest és l’SDK ara.

Començar és gairebé injustament senzill

Aquí hi ha un agent que treballa a.NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Això és tot. Un grapat de línies i teniu un agent d’IA que s’executa contra Azure Foundry. L’equivalent de Python és igualment concís. Afegiu eines de funció, converses de diversos torns i transmissió a mesura que avanceu: la superfície de l’API augmenta sense ser estrany.

Orquestració multiagent: aquest és el veritable negoci

Els agents únics estan bé per a les demostracions, però els escenaris de producció solen necessitar coordinació. Agent Framework 1.0 s’envia amb patrons d’orquestració provats en batalla directament de Microsoft Research i AutoGen:

Seqüencial: els agents processen per ordre (escriptor → revisor → editor)
Simultània: es distribueix a diversos agents en paral·lel, convergeix els resultats
Handoff: un agent delega a un altre segons la intenció
Xat de grup: diversos agents discuteixen i convergeixen en una solució
Magentic-One: el patró multiagent de grau de recerca de MSR

Tots admeten la transmissió en temps real, els punts de control, les aprovacions humanes en el bucle i la pausa/reprèn. La part del punt de control és crucial: els fluxos de treball de llarga durada sobreviuen als reinicis del procés. Per als desenvolupadors de.NET que hem creat fluxos de treball duradors amb Azure Functions, això ens sembla familiar.

Les característiques que més importen

Aquí teniu la meva llista del que val la pena saber:

Enganxs de middleware. Saps com ASP.NET Core té canalitzacions de middleware? Mateix concepte, però per a l’execució de l’agent. Intercepteu totes les etapes (afegiu seguretat de contingut, registre, polítiques de compliment) sense tocar les indicacions de l’agent. Així és com podeu preparar els agents per a l’empresa.

Memòria connectable. Historial de conversa, estat clau-valor persistent, recuperació basada en vectors. Trieu el vostre backend: Foundry Agent Service, Mem0, Redis, Neo4j o enrotlleu el vostre. La memòria és el que converteix una trucada LLM sense estat en un agent que realment recorda el context.

Agents YAML declaratius. Definiu les instruccions, les eines, la memòria i la topologia d’orquestració del vostre agent en fitxers YAML controlats per versions. Carregueu i executeu amb una única trucada a l’API. Això és un canvi de joc per als equips que volen repetir el comportament de l’agent sense tornar a desplegar el codi.

Compatibilitat amb A2A i MCP. MCP (Model Context Protocol) permet als agents descobrir i invocar eines externes de manera dinàmica. A2A (protocol d’agent a agent) permet la col·laboració entre temps d’execució: els vostres agents.NET poden coordinar-se amb els agents que s’executen en altres marcs. El suport A2A 1.0 arribarà aviat.

Les funcions de previsualització val la pena veure-les

Algunes funcions s’envien com a previsualització a la versió 1.0: funcionals, però les API poden evolucionar:

DevUI: un depurador local basat en navegador per visualitzar l’execució de l’agent, els fluxos de missatges i les trucades d’eines en temps real. Penseu en Application Insights, però per al raonament dels agents.
GitHub Copilot SDK i Claude Code SDK: utilitzeu Copilot o Claude com a arnès d’agent directament des del vostre codi d’orquestració. Escriu un agent capaç de codificar juntament amb els altres agents en el mateix flux de treball.
Agent Harness: un temps d’execució local personalitzable que ofereix als agents accés a l’intèrpret d’ordres, al sistema de fitxers i als bucles de missatgeria. Penseu en agents de codificació i patrons d’automatització.
Habilitats: paquets de capacitats de domini reutilitzables que ofereixen als agents capacitats estructurades de manera immediata.

Migració des del nucli semàntic o AutoGen

Si teniu codi Semàntic Kernel o AutoGen, hi ha assistents de migració dedicats que analitzen el vostre codi i generen plans de migració pas a pas. La guia de migració del nucli semàntic i la guia de migració d’AutoGen us acompanyen tot.

Si heu estat als paquets RC, l’actualització a la 1.0 és només un augment de la versió.

Tancant

Agent Framework 1.0 és la fita de producció que els equips empresarials estaven esperant. API estables, suport per a diversos proveïdors, patrons d’orquestració que funcionen realment a escala i rutes de migració tant del nucli semàntic com d’AutoGen.

El marc és totalment de codi obert a GitHub, i podeu començar avui mateix amb dotnet add package Microsoft.Agents.AI. Consulteu la guia d’inici ràpid i les mostres per embrutar-vos les mans.

Si heu estat esperant el senyal “Segur per utilitzar en producció”, això és tot.

azd ara us permet executar i depurar agents d'IA localment: aquí teniu el que va canviar el març de 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Set llançaments en un mes. Això és el que va impulsar l’equip de l’Azure Developer CLI (azd) el març de 2026, i la funció de titular és la que estava esperant: un bucle local d’execució i depuració per als agents d’IA.

PC Chan va publicar el resum complet i, tot i que hi ha moltes coses, permeteu-me filtrar-ho fins al que realment importa per als desenvolupadors de.NET que creen aplicacions basades en IA.

Executeu i depureu agents d’IA sense desplegar-los

Aquest és el gran. La nova extensió azure.ai.agents afegeix un conjunt d’ordres que us ofereixen una experiència de bucle interior adequada per als agents d’IA:

azd ai agent run: inicia el vostre agent localment
azd ai agent invoke: li envia missatges (locals o desplegats)
azd ai agent show: mostra l’estat i la salut del contenidor
azd ai agent monitor: transmet els registres dels contenidors en temps real

Abans d’això, provar un agent d’IA significava desplegar-lo a Microsoft Foundry cada vegada que feies un canvi. Ara podeu iterar localment, provar el comportament del vostre agent i només implementar-lo quan estigueu preparat. Si heu estat creant agents amb Microsoft Agent Framework o Semantic Kernel, això canvia el vostre flux de treball diari.

L’ordre d’invocació funciona amb agents locals i desplegats, la qual cosa significa que podeu utilitzar el mateix flux de treball de prova independentment d’on s’executi l’agent. Aquest és el tipus de detall que us estalvia mantenir dos conjunts de scripts de prova.

GitHub Copilot arma el vostre projecte azd

azd init ara ofereix una opció “Configura amb GitHub Copilot (vista prèvia)”. En lloc de respondre manualment les sol·licituds sobre l’estructura del vostre projecte, un agent de Copilot us encarrega la configuració. Comprova si hi ha un directori de treball brut abans de modificar res i demana el consentiment de l’eina del servidor MCP per endavant.

Quan una ordre falla, azd ara ofereix una resolució de problemes assistida per IA: trieu una categoria (explica, orienta, soluciona problemes o salta), deixeu que l’agent suggereixi una solució i torneu-ho a provar, tot sense sortir del terminal. Per a configuracions d’infraestructures complexes, això suposa un estalvi de temps real.

Feines de l’aplicació de contenidors i millores en el desplegament

Algunes funcions de desplegament que cal destacar:

Fines d’aplicacions de contenidors: azd ara desplega Microsoft.App/jobs mitjançant la configuració existent host: containerapp. La vostra plantilla de bíceps determina si l’objectiu és una aplicació de contenidor o una feina, sense cap configuració addicional.
Temps d’espera de desplegament configurables: nova marca --timeout a azd deploy i un camp deployTimeout a azure.yaml. Ja no cal endevinar el límit predeterminat de 1200 segons.
Recurs de compilació remota: quan la compilació remota d’ACR falla, azd torna automàticament a la compilació local de Docker/Podman.
Validació local de preflight: els paràmetres de bíceps es validen localment abans de desplegar-se, capturant els paràmetres que falten sense un viatge d’anada i tornada a Azure.

Polit de l’experiència del desenvolupador

Algunes millores més petites que sumen:

Detecció automàtica de pnpm/fils per a projectes JS/TS
Compatibilitat amb pyproject.toml per a l’embalatge de Python
Directoris de plantilles locals — azd init --template ara accepta camins del sistema de fitxers per a la iteració fora de línia
Millors missatges d’error en mode --no-prompt: tots els valors que falten es reporten alhora amb ordres de resolució
Variables d’entorn de compilació injectades a tots els subprocessos de creació de marcs (.NET, Node.js, Java, Python)

Aquesta última és subtil però important: la vostra compilació.NET ara té accés a les variables d’entorn azd, la qual cosa significa que podeu fer una injecció de configuració en temps de compilació sense scripts addicionals.

Tancant

El bucle de depuració de l’agent d’IA local és l’estrella d’aquesta versió, però l’acumulació de millores en el desplegament i la poliment DX fa que azd se senti més madur que mai. Si esteu desplegant aplicacions.NET a Azure, especialment agents d’IA, aquesta actualització val la pena instal·lar-la.

Comproveu les notes completes de la versió per a cada detall o comenceu amb instal·lació d’azd.

El tauler de control de l'Aspire 13.2 acaba de tenir una API de telemetria i ho canvia tot

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Si heu estat creant aplicacions distribuïdes amb.NET Aspire, ja sabeu que el tauler és el millor de tota l’experiència. Tots els vostres rastres, registres i mètriques en un sol lloc: sense Jaeger extern, sense configuració de Seq, sense moments “deixa’m comprovar l’altre terminal”.

Aspire 13.2 l’acaba de millorar significativament. James Newton-King va anunciar l’actualització, i sincerament? Només l’exportació de telemetria i les funcions de l’API mereixen l’actualització.

Exporta la telemetria com una persona sensata

Aquest és l’escenari que tots hem viscut: esteu depurant un problema distribuït, finalment el reproduïu després de vint minuts de configuració i ara heu de compartir el que va passar amb el vostre equip. Abans? Captures de pantalla. Copia i enganxa ID de traça. L’embolic habitual.

Aspire 13.2 afegeix un diàleg adequat Gestiona els registres i la telemetria on podeu:

Esborra tota la telemetria (útil abans d’un intent de reproducció)
Exporteu la telemetria seleccionada a un fitxer ZIP en format estàndard OTLP/JSON
Torneu a importar aquest ZIP a qualsevol tauler de control d’Aspire més tard

Aquesta última part és la característica assassina. Reproduïu un error, exporteu la telemetria, l’adjunteu al vostre element de treball i el vostre company d’equip pot importar-lo al seu propi tauler per veure exactament el que heu vist. No més “pots reproduir-lo a la teva màquina?”

Les traces, els intervals i els registres individuals també reben una opció “Exporta JSON” als seus menús contextuals. Necessites compartir un rastre específic? Feu clic amb el botó dret, copieu JSON i enganxeu-lo a la vostra descripció de PR. Fet.

L’API de telemetria és el veritable canvi de joc

Això és el que m’emociona més. El tauler ara exposa una API HTTP a /api/telemetry per consultar dades de telemetria amb programació. Punts finals disponibles:

GET /api/telemetry/resources: llista els recursos amb telemetria
GET /api/telemetry/spans: la consulta s’estén amb filtres
GET /api/telemetry/logs: registres de consultes amb filtres
GET /api/telemetry/traces — llista traces
GET /api/telemetry/traces/{traceId}: obteniu tots els intervals d’un rastre específic

Tot torna en format OTLP JSON. Això impulsa les noves ordres CLI aspire agent mcp i aspire otel, però la implicació real és més gran: ara podeu crear eines, scripts i integracions d’agents d’IA que consulten directament la telemetria de la vostra aplicació.

Imagineu un agent de codificació d’IA que pugui mirar les vostres traces distribuïdes reals mentre es depura. Això ja no és hipotètic: això és el que permet aquesta API.

La telemetria GenAI es fa pràctica

Si esteu creant aplicacions basades en IA amb Semantic Kernel o Microsoft.Extensions.AI, apreciareu el visualitzador de telemetria GenAI millorat. Aspire 13.2 afegeix:

Descripcions d’eines d’IA representades com a Markdown
Un botó dedicat GenAI a la pàgina de traces per accedir ràpidament a traces d’IA
Millor gestió d’errors per a JSON GenAI truncat o no estàndard
Navegació fent clic per ressaltar entre definicions d’eines

La publicació del bloc esmenta que el xat de VS Code Copilot, la CLI de Copilot i l’OpenCode admeten la configuració d’un OTEL_EXPORTER_OTLP_ENDPOINT. Apunteu-los al tauler de control d’Aspire i podreu veure literalment els vostres agents d’IA pensar en temps real mitjançant la telemetria. Aquesta és una experiència de depuració que no trobareu enlloc més.

Tancant

Aspire 13.2 fa que el tauler de control sigui “una bona interfície d’usuari de depuració” a una “plataforma d’observabilitat programable”. Només el flux de treball d’exportació/importació estalvia temps real en la depuració distribuïda i l’API de telemetria obre la porta als diagnòstics assistits per IA.

Si ja esteu a Aspire, actualitzeu-lo. Si no ho feu, aquesta és una bona raó per consultar aspire.dev i veure de què es tracta.

L'actualització de març de Visual Studio us permet crear agents de pilot personalitzats, i l'eina find_symbol és una gran cosa

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Visual Studio acaba de rebre la seva actualització Copilot més important fins ara. Mark Downie va anunciar el llançament de març, i el títol és agents personalitzats, però sincerament, l’eina find_symbol soterrada més avall podria ser la característica que canviï més el vostre flux de treball.

Permeteu-me desglossar el que hi ha realment aquí.

Agents de Copilot personalitzats al vostre dipòsit

Voleu que Copilot segueixi els estàndards de codificació del vostre equip, executi el vostre pipeline de compilació o consulti els vostres documents interns? Ara pots construir exactament això.

Els agents personalitzats es defineixen com a fitxers .agent.md que deixeu anar a .github/agents/ al vostre repositori. Cada agent té accés complet a la consciència de l’espai de treball, la comprensió del codi, les eines, el model preferit i les connexions MCP a serveis externs. Apareixen al selector d’agents al costat dels agents integrats.

Aquest és el mateix patró que VS Code ha donat suport, i és fantàstic veure que Visual Studio es posa al dia. Per als equips que ja han creat agents per a VS Code, els vostres fitxers .agent.md haurien de funcionar en ambdós IDE (tot i que els noms d’eines poden variar, així que proveu-los).

El repositori awesome-copilot té configuracions d’agents contribuïts per la comunitat que podeu utilitzar com a punts de partida.

Habilitats d’agent: paquets d’instruccions reutilitzables

Les habilitats es recullen automàticament de .github/skills/ al vostre repositori o ~/.copilot/skills/ al vostre perfil. Cada habilitat és un fitxer SKILL.md seguint l’especificació d’habilitats de l’agent.

Penseu en les habilitats com a experiència modular que podeu combinar i combinar. És possible que tingueu una habilitat per a les convencions de l’API, una altra per als vostres patrons de prova i una altra per al vostre flux de treball de desplegament. Quan s’activa una habilitat, apareix al xat perquè sàpigues que s’està aplicant.

Si heu estat utilitzant habilitats a VS Code, ara funcionen de la mateixa manera a Visual Studio.

find_symbol: navegació conscient de l’idioma per als agents

Aquí és on les coses es posen realment interessants. La nova eina find_symbol ofereix al mode d’agent de Copilot una navegació real de símbols basada en el servei d’idiomes. En lloc de cercar el vostre codi com a text, l’agent pot:

Trobeu totes les referències a un símbol al vostre projecte
Informació de tipus d’accés, declaracions i metadades d’abast
Navegueu pels llocs de trucades amb coneixement complet de l’idioma

Què significa això a la pràctica: quan demaneu a Copilot que refactori un mètode o actualitzeu una signatura de paràmetres en llocs de trucada, realment pot veure l’estructura del vostre codi. No més situacions “l’agent va canviar el mètode però va perdre tres llocs de trucades”.

Els llenguatges admesos inclouen C#, C++, Razor, TypeScript i qualsevol cosa amb una extensió LSP compatible. Per als desenvolupadors de.NET, aquesta és una millora massiva: les bases de codi C# amb jerarquies i interfícies de tipus profundes es beneficien enormement de la navegació conscient dels símbols.

Proves de perfil amb Copilot

Ara hi ha una ordre Perfil amb Copilot al menú contextual de l’Explorador de proves. Seleccioneu una prova, feu clic al perfil i l’agent de perfils l’executa automàticament i analitza el rendiment, combinant l’ús de la CPU i les dades d’instrumentació per oferir informació útil.

No més configurar manualment sessions de perfilador, executar la prova, exportar resultats i intentar llegir un gràfic de flama. L’agent fa l’anàlisi i us diu què és lent i per què. Actualment només.NET, cosa que té sentit donada la profunda integració de diagnòstic.NET de Visual Studio.

Consells de rendiment durant la depuració en directe

L’optimització del rendiment ara es produeix mentre depureu, no després. A mesura que passeu pel codi, Visual Studio mostra el temps d’execució i els senyals de rendiment en línia. Veus una línia lenta? Feu clic al Consell de rendiment i demaneu a Copilot suggeriments d’optimització allà mateix.

L’agent de perfils captura automàticament les dades del temps d’execució (temps transcorregut, ús de la CPU, comportament de la memòria) i Copilot les utilitza per identificar els punts calents. Això manté el treball de rendiment com a part del vostre flux de depuració en lloc d’una tasca separada que continueu posposant.

Corregiu les vulnerabilitats de NuGet des de l’Explorador de solucions

Quan es detecta una vulnerabilitat en un paquet NuGet, ara veuràs una notificació amb un enllaç Corregir amb GitHub Copilot directament a l’Explorador de solucions. Feu clic i Copilot analitza la vulnerabilitat, recomana les actualitzacions de paquets adequades i les implementa.

Per als equips que lluiten per mantenir les dependències actualitzades (que és bàsicament per a tothom), això elimina la fricció de “Sé que hi ha una vulnerabilitat, però esbrinar la ruta d’actualització correcta és un projecte en si mateix”.

Tancant

Els agents personalitzats i les habilitats són el titular, però find_symbol és l’èxit dormint: canvia fonamentalment la precisió que pot ser Copilot quan es refactoritza el codi.NET. Combinada amb la integració de perfils en directe i les correccions de vulnerabilitats, aquesta actualització fa que les funcions d’IA de Visual Studio se sentin realment pràctiques en lloc de preparar-se per a la demostració.

Baixeu Visual Studio 2026 Insiders per provar-ho tot.

KubeCon Europe 2026: què haurien de preocupar-se realment als desenvolupadors.NET

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Coneixes aquesta sensació quan cau una publicació d’anunci massiva i t’estàs desplaçant per ella pensant “genial, però què canvia això realment per a mi”? Soc jo cada temporada de la KubeCon.

Microsoft acaba de publicar el seu resum complet de KubeCon Europe 2026, escrit pel mateix Brendan Burns, i sincerament? Aquí hi ha substància real. No només inclouen les caselles de selecció, sinó també el tipus de millores operatives que canvien la manera d’executar les coses en producció.

Permeteu-me desglossar el que realment importa per als desenvolupadors de.NET.

mTLS sense l’impost de malla de servei

Això és el que passa amb les malles de servei: tothom vol les garanties de seguretat, ningú vol la sobrecàrrega operativa. AKS finalment està tancant aquesta bretxa.

Azure Kubernetes Application Network us ofereix TLS mutu, autorització conscient de l’aplicació i telemetria de trànsit, sense desplegar una malla plena de sidecars. Combinat amb Cilium mTLS a Advanced Container Networking Services, obteniu una comunicació xifrada de pod a pod mitjançant certificats X.509 i SPIRE per a la gestió d’identitats.

Què significa això a la pràctica: les vostres API ASP.NET Core parlen amb treballadors en segon pla, els vostres serveis gRPC es trucen entre ells, tot xifrat i verificat per la identitat a nivell de xarxa, sense canvis en el codi de l’aplicació. Això és enorme.

Per als equips que migren des de ingress-nginx, també hi ha Application Routing with Meshless Istio amb suport complet de l’API de Kubernetes Gateway. Sense sidecars. Basat en estàndards. I van enviar eines ingress2gateway per a la migració incremental.

Observabilitat de la GPU que no és una idea posterior

Si utilitzeu una inferència d’IA juntament amb els vostres serveis.NET (i siguem sincers, qui no comença a fer-ho?), probablement heu arribat al punt cec de supervisió de la GPU. Obtindreu grans taulers de CPU/memòria i després… res per a les GPU sense una fontaneria d’exportació manual.

AKS ara mostra les mètriques de la GPU de manera nativa a Prometheus i Grafana gestionats. Mateixa pila, mateixos taulers de comandament, mateix canal d’alertes. Sense exportadors personalitzats, ni agents de tercers.

Al costat de la xarxa, van afegir visibilitat per flux per al trànsit HTTP, gRPC i Kafka amb una experiència d’Azure Monitor amb un sol clic. IP, ports, càrregues de treball, direcció del flux, decisions polítiques, tot en taulers integrats.

I aquesta és la que m’ha fet fer una doble presa: xarxa de contenidors agent afegeix una interfície d’usuari web on podeu fer preguntes en llenguatge natural sobre l’estat de la xarxa del vostre clúster. “Per què el pod X no arriba al servei Y?” → diagnòstics de només lectura de la telemetria en directe. Això és realment útil a les 2 del matí.

Xarxes entre clústers que no requereixen un doctorat

Històricament, Kubernetes multiclúster ha estat una experiència de “porta la teva pròpia cola de xarxa”. Azure Kubernetes Fleet Manager ara s’envia xarxes entre clústers mitjançant la malla de clúster de Cilium gestionada:

Connectivitat unificada entre clústers AKS
Registre global de serveis per a la descoberta entre clústers
Configuració gestionada de manera centralitzada, no repetida per clúster

Si utilitzeu microserveis.NET en diferents regions per a la seva resiliència o compliment, això substitueix una gran quantitat de fontaneria personalitzada fràgil. El servei A a l’oest d’Europa pot descobrir i trucar al servei B a l’est dels EUA a través de la malla, amb polítiques d’encaminament i seguretat coherents.

Actualitzacions que no requereixen valentia

Siguem sincers: les actualitzacions de Kubernetes en producció són estressants. “Actualitzar i esperar” ha estat l’estratègia de facto per a massa equips, i és el principal motiu pel qual els clústers es queden endarrerits en les versions.

Dues noves capacitats canvien això:

Les actualitzacions del grup d’agents blau-verd creen un grup de nodes paral·lels amb la nova configuració. Valideu el comportament, canvieu el trànsit gradualment i manteniu un camí de retrocés net. No més mutacions in situ als nodes de producció.

La recuperació de l’agrupació d’agents us permet revertir una agrupació de nodes a la seva versió anterior de Kubernetes i a la imatge de node després d’una actualització de costat, sense haver de reconstruir el clúster.

En conjunt, finalment donen als operadors un control real sobre el cicle de vida de l’actualització. Per als equips.NET, això és important perquè la velocitat de la plataforma controla directament la rapidesa amb què podeu adoptar nous temps d’execució, pedaços de seguretat i capacitats de xarxa.

Les càrregues de treball d’IA s’estan convertint en ciutadans de primer nivell de Kubernetes

El treball de codi obert amunt és igual d’important. L’assignació dinàmica de recursos (DRA) acaba de passar a GA a Kubernetes 1.36, fent que la programació de la GPU sigui una funció adequada de primera classe en lloc d’una solució alternativa.

Alguns projectes que val la pena veure:

Projecte	Què fa
AI Runway	API comuna de Kubernetes per a la inferència: implementeu models sense conèixer els K8, amb el descobriment d’HuggingFace i les estimacions de costos
HolmesGPT	Resolució de problemes d’agent per als nadius del núvol: ara un projecte Sandbox CNCF
Dalec	La imatge de contenidor declarativa es construeix amb la generació SBOM: menys CVE en l’etapa de creació

La direcció és clara: la vostra API.NET, la vostra capa d’orquestració del nucli semàntic i les vostres càrregues de treball d’inferència s’han d’executar en un model de plataforma coherent. Hi arribem.

Per on començaria aquesta setmana

Si esteu avaluant aquests canvis per al vostre equip, aquí teniu la meva llista de prioritats honesta:

Observabilitat primer: activeu les mètriques de la GPU i els registres de flux de xarxa en un clúster que no sigui de producte. Mira què t’has perdut.
Proveu les actualitzacions blau-verd: proveu el flux de treball de retrocés abans de la propera actualització del clúster de producció. Generar confiança en el procés.
Pilota de xarxes conscients de la identitat: trieu una ruta de servei interna i activeu mTLS amb Cilium. Mesureu la sobrecàrrega (spoiler: és mínim).
Avalueu el gestor de flotes: si executeu més de dos clústers, la xarxa entre clústers es compensa amb una cola personalitzada reduïda.

Petits experiments, feedback ràpid. Aquest és sempre el moviment.

Tancant

Els anuncis de KubeCon poden ser aclaparadors, però aquest lot realment mou l’agulla dels equips.NET a AKS. Millor seguretat de xarxes sense sobrecàrrega de malla, observabilitat real de la GPU, actualitzacions més segures i bases d’infraestructura d’IA més sòlides.

Si ja esteu a AKS, aquest és un bon moment per endurir la vostra línia de base operativa. I si teniu previst traslladar les càrregues de treball.NET a Kubernetes, la plataforma s’acaba de preparar molt més per a la producció.

El servei d'agents de Foundry és GA: el que realment importa per als constructors d'agents.NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Siguem sincers: construir un prototip d’agent d’IA és la part fàcil. La part difícil és que tot sigui després: posar-lo en producció amb un aïllament adequat de la xarxa, fer avaluacions que realment signifiquen alguna cosa, gestionar els requisits de compliment i no trencar les coses a les 2 del matí.

El Foundry Agent Service acaba de passar a GA, i aquest llançament està centrat en aquest buit de “tot després”.

Creat a partir de l’API Responses

Aquí teniu el titular: el servei d’agent de Foundry de nova generació es basa en l’API de respostes d’OpenAI. Si ja esteu creant amb aquest protocol de cable, migrar a Foundry és un canvi de codi mínim. Què obteniu: seguretat empresarial, xarxes privades, Entra RBAC, seguiment complet i avaluació, a més de la vostra lògica d’agent existent.

L’arquitectura és oberta intencionadament. No esteu bloquejat a un proveïdor de models ni a un marc d’orquestració. Utilitzeu DeepSeek per a la planificació, OpenAI per a la generació, LangGraph per a l’orquestració: el temps d’execució gestiona la capa de coherència.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Si veniu del paquet azure-ai-agents, ara els agents són operacions de primera classe a AIProjectClient a azure-ai-projects. Deixeu anar el pin autònom i utilitzeu get_openai_client() per generar respostes.

Xarxes privades: s’ha eliminat el bloquejador empresarial

Aquesta és la característica que desbloqueja l’adopció empresarial. Foundry ara admet xarxes privades d’extrem a extrem amb BYO VNet:

Sense sortida pública: el trànsit d’agents no toca mai l’Internet pública
Injecció de contenidor/subxarxa a la vostra xarxa per a la comunicació local
Connectivitat d’eines inclosa: els servidors MCP, Azure AI Search i els agents de dades de Fabric operen per camins privats

Aquest darrer punt és crític. No només les trucades d’inferència es mantenen privades: totes les trucades d’invocació i recuperació d’eines també es mantenen dins dels límits de la vostra xarxa. Per als equips que operen sota polítiques de classificació de dades que prohibeixen l’encaminament extern, això és el que faltava.

Autenticació MCP feta correctament

Les connexions del servidor MCP ara admeten l’espectre complet de patrons d’autenticació:

Mètode d’autenticació	Quan s’ha d’utilitzar
Basat en claus	Accés compartit senzill per a eines internes de tota l’organització
Entra la identitat de l’agent	servei a servei; l’agent s’autentica com ell mateix
Entra a la identitat gestionada	Aïllament per projecte; cap gestió de credencials
Passthrough d’identitat OAuth	Accés delegat per l’usuari; agent actua en nom dels usuaris

OAuth Identity Passthrough és l’interessant. Quan els usuaris han de concedir a un agent accés a les seves dades personals (el seu OneDrive, la seva organització de Salesforce, una API de SaaS definida per l’usuari), l’agent actua en nom seu amb els fluxos d’OAuth estàndard. No hi ha cap identitat de sistema compartida que pretengui ser tothom.

Voice Live: veu a veu sense la fontaneria

Afegir veu a un agent solia significar unir STT, LLM i TTS: tres serveis, tres salts de latència, tres superfícies de facturació, tot sincronitzat a mà. Voice Live ho col·lapsa en una única API gestionada amb:

Activitat de veu semàntica i detecció de final de torn (comprèn el significat, no només el silenci)
Supressió de soroll del costat del servidor i cancel·lació d’eco
Suport d’intrusió (els usuaris poden interrompre la resposta mitjana)

Les interaccions de veu passen pel mateix temps d’execució de l’agent que el text. Els mateixos avaluadors, els mateixos rastres, la mateixa visibilitat de costos. Per a escenaris d’assistència al client, servei de camp o accessibilitat, això substitueix el que abans requeria una canalització d’àudio personalitzada.

Avaluacions: des de la casella de selecció fins al seguiment continu

Aquí és on Foundry es pren seriosament sobre la qualitat de la producció. El sistema d’avaluació té ara tres capes:

Avaluadors fora de la caixa: coherència, rellevància, fonamentació, qualitat de recuperació, seguretat. Connecta’t a un conjunt de dades o trànsit en directe i recupera les puntuacions.
Avaluadors personalitzats: codifiqueu la vostra pròpia lògica empresarial, estàndards de to i regles de compliment específiques del domini.
Avaluació contínua: Foundry mostra el trànsit de producció en directe, executa la vostra suite d’avaluadors i mostra els resultats mitjançant taulers de control. Establiu alertes d’Azure Monitor per quan cau la connexió a terra o incompliment dels llindars de seguretat.

Tot es publica a Azure Monitor Application Insights. Qualitat de l’agent, salut de la infraestructura, cost i telemetria d’aplicacions, tot en un sol lloc.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Sis noves regions per als agents allotjats

Els agents allotjats ara estan disponibles a l’est dels EUA, al nord del centre dels EUA, a Suècia al centre, al sud-est asiàtic, al Japó oriental i més. Això és important per als requisits de residència de les dades i per comprimir la latència quan el vostre agent s’executa a prop de les seves fonts de dades.

Per què això és important per als desenvolupadors de.NET

Tot i que les mostres de codi de l’anunci de GA són Python primer, la infraestructura subjacent és independent del llenguatge, i l’SDK.NET per a azure-ai-projects segueix els mateixos patrons. L’API Responses, el marc d’avaluació, la xarxa privada, l’autenticació MCP, tot això està disponible a.NET.

Si heu estat esperant que els agents d’IA passin de “demo fantàstica” a “Puc enviar-ho a la feina”, aquest llançament de GA és el senyal. Les xarxes privades, l’autenticació adequada, l’avaluació contínua i el seguiment de la producció són les peces que faltaven.

Tancant

El servei d’agent de Foundry ja està disponible. Instal·leu l’SDK, obriu el portal i comenceu a crear. La guia d’inici ràpid us porta de zero a un agent en execució en qüestió de minuts.

Per obtenir la informació tècnica completa amb totes les mostres de codi, consulteu l’anunci de GA.

Respostes de fons a Microsoft Agent Framework: no hi ha més ansietat de temps d'espera

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Si heu creat alguna cosa amb models de raonament com l’o3 o el GPT-5.2, coneixeu el dolor. El vostre agent comença a pensar en una tasca complexa, el client s’asseu allà esperant i en algun lloc entre “això està bé” i “s’ha estavellat?” la vostra connexió s’esgota. Tota aquesta feina? Desaparegut.

Microsoft Agent Framework acaba d’enviar respostes de fons i, sincerament, aquesta és una d’aquestes característiques que haurien d’haver existit des del primer dia.

El problema amb el bloqueig de trucades

En un patró de sol·licitud-resposta tradicional, el vostre client es bloqueja fins que l’agent acabi. Això funciona bé per a tasques ràpides. Però quan demaneu a un model de raonament que faci una investigació profunda, una anàlisi en diversos passos o que generi un informe de 20 pàgines? Esteu mirant els minuts del rellotge de paret. Durant aquesta finestra:

Les connexions HTTP es poden esgotar
Els blips de xarxa maten tota l’operació
El vostre usuari mira un spinner preguntant-se si està passant alguna cosa

Les respostes de fons donen la volta a això.

Com funcionen les fitxes de continuació

En lloc de bloquejar, inicieu la tasca de l’agent i recupereu un token de continuació. Penseu-ho com un bitllet de reclamació en un taller de reparacions: no us quedeu al taulell esperant, torneu quan estigui llest.

El flux és senzill:

Envieu la vostra sol·licitud amb AllowBackgroundResponses = true
Si l’agent admet el processament en segon pla, obtindreu un testimoni de continuació
Enquesta sobre el teu horari fins que el testimoni torni null; això vol dir que el resultat està preparat

Aquí teniu la versió de.NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Poll until complete
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Si l’agent completa immediatament (tasques senzilles, models que no necessiten processament en segon pla), no es retorna cap testimoni de continuació. El vostre codi només funciona, no cal cap manipulació especial.

Transmissió amb currículum: la veritable màgia

Les enquestes estan bé per als escenaris de foc i oblit, però què passa quan voleu progrés en temps real? Les respostes en segon pla també admeten la transmissió amb la represa integrada.

Cada actualització en streaming porta el seu propi testimoni de continuació. Si la vostra connexió cau a la meitat del flux, repreneu exactament on ho vau deixar:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simulate a network interruption
}

// Resume from exactly where we left off
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

L’agent continua processant el costat del servidor independentment del que passi amb el vostre client. Això és una tolerància a fallades integrada sense que escriviu la lògica de reintent o els interruptors.

Quan s’ha d’utilitzar realment

No totes les trucades d’agent necessiten respostes en segon pla. Per completar-les ràpidament, esteu afegint complexitat sense cap motiu. Però aquí és on brillen:

Tasques de raonament complexes: anàlisi en diversos passos, investigació profunda, qualsevol cosa que faci pensar realment a un model de raonament
Generació llarga de contingut: informes detallats, documents de diverses parts, anàlisis exhaustives
Xarxes poc fiables: clients mòbils, desplegaments perifèrics, VPN corporatives descabellades
Patrons UX asíncrons: envieu una tasca, aneu a fer una altra cosa, torneu per obtenir resultats

Per als desenvolupadors de.NET que creem aplicacions empresarials, aquesta última és especialment interessant. Penseu en una aplicació Blazor en què un usuari sol·licita un informe complex: desactiveu la tasca de l’agent, els mostreu un indicador de progrés i deixeu que continuï treballant. Sense gimnàstica WebSocket, sense infraestructura de cua personalitzada, només un testimoni i un bucle d’enquesta.

Tancant

Les respostes de fons estan disponibles ara tant a.NET com a Python mitjançant Microsoft Agent Framework. Si esteu creant agents que fan alguna cosa més complexa que les simples preguntes i respostes, val la pena afegir-ho al vostre conjunt d’eines. El patró de testimoni de continuació manté les coses senzilles alhora que resol un problema de producció molt real.

Consulteu la documentació completa per obtenir la referència completa de l’API i més exemples.

VS Code 1.112: Què haurien de preocupar-se realment als desenvolupadors de.NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 acaba d’aterrar, i sincerament? Aquest és diferent si passeu els vostres dies a la terra.NET. Hi ha moltes coses a les notes oficials de la versió, però permeteu-me que us estalviï una mica de desplaçament i que em concentri en allò que realment ens importa.

Copilot CLI acaba de ser molt més útil

El gran tema d’aquest llançament és autonomia de l’agent, donant més espai a Copilot per fer les seves coses sense que facis de cangur a cada pas.

Direcció i cua de missatges

Coneixes aquell moment en què Copilot CLI està a mig camí d’una tasca i t’adones que t’has oblidat d’esmentar alguna cosa? Abans, calia esperar. Ara només podeu enviar missatges mentre una sol·licitud encara s’està executant, ja sigui per dirigir la resposta actual o posar en cua les instruccions de seguiment.

Això és enorme per a aquelles tasques més llargues de bastida dotnet en què esteu veient Copilot configura un projecte i penseu “oh, espera, també necessito MassTransit”.

Nivells de permís

Aquest és el que m’emociona més. Les sessions de Copilot CLI ara admeten tres nivells de permís:

Permisos predeterminats: el flux habitual on les eines demanen confirmació abans d’executar-se
Evita les aprovacions: s’aprova tot automàticament i torna a provar els errors
Pilot automàtic: és totalment autònom: aprova les eines, respon a les seves pròpies preguntes i continua fins que es fa la tasca

Si esteu fent alguna cosa com la bastida d’una nova API ASP.NET Core amb Entity Framework, migracions i una configuració de Docker, el mode Autopilot significa que descriu el que voleu i aneu a prendre un cafè. Ho descobrirà.

Podeu habilitar el pilot automàtic amb la configuració chat.autopilot.enabled.

Previsualitza els canvis abans de la delegació

Quan delegueu una tasca a Copilot CLI, es crea un arbre de treball. Abans, si teníeu canvis no compromesos, havíeu de comprovar el control de fonts per veure què es veuria afectat. Ara, la vista de xat mostra els canvis pendents abans de decidir si els voleu copiar, moure o ignorar-los.

Poca cosa, però us salva d’aquell “espera, què he posat en escena?” moment.

Depura les aplicacions web sense sortir de VS Code

El navegador integrat ara admet depuració completa. Podeu establir punts d’interrupció, passar pel codi i inspeccionar variables, tot dins de VS Code. No més canviar a Edge DevTools.

Hi ha un nou tipus de depuració editor-browser i si ja teniu configuracions de llançament de msedge o chrome, la migració és tan senzilla com canviar el camp type al vostre launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Per als desenvolupadors de Blazor, això és un canvi de joc. Ja esteu executant dotnet watch al terminal; ara la vostra depuració també es manté a la mateixa finestra.

El navegador també va obtenir nivells de zoom independents (finalment), menús contextuals adequats del clic dret i el zoom es recorda per lloc web.

Sandboxing del servidor MCP

Aquest és més important del que podríeu pensar. Si utilitzeu servidors MCP (potser n’heu configurat un de personalitzat per als vostres recursos d’Azure o consultes de base de dades), s’han executat amb els mateixos permisos que el vostre procés de VS Code. Això significa un accés complet al vostre sistema de fitxers, xarxa, tot.

Ara els podeu sorrar. Al teu mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Quan un servidor amb caixa de sorra necessita accés a alguna cosa que no té, VS Code us demana que atorgueu permís. Molt millor que l’enfocament “Espero que ningú faci res estrany”.

Nota: Sandboxing està disponible per ara a macOS i Linux. Arriba el suport de Windows, però escenaris remots com WSL funcionen.

Descobriment de personalitzacions de Monorepo

Si esteu treballant en un monorepo (i siguem sincers, moltes solucions empresarials.NET acaben com una), això resol un veritable problema.

Anteriorment, si obríeu una subcarpeta del vostre repositori, VS Code no trobaria les vostres habilitats copilot-instructions.md, AGENTS.md o personalitzades a l’arrel del dipòsit. Ara, amb la configuració chat.useCustomizationsInParentRepositories, puja a l’arrel .git i ho descobreix tot.

Això significa que el vostre equip pot compartir instruccions de l’agent, fitxers de sol·licitud i eines personalitzades en tots els projectes en un monorepo sense que tothom hagi d’obrir la carpeta arrel.

/resolució de problemes per a la depuració de l’agent

Alguna vegada has configurat instruccions o habilitats personalitzades i t’has preguntat per què no les recullen? La nova habilitat /troubleshoot llegeix els registres de depuració de l’agent i us diu què va passar: quines eines s’han utilitzat o s’han omès, per què les instruccions no s’han carregat i què està causant respostes lentes.

Activa-ho amb:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

A continuació, només cal escriure /troubleshoot why is my custom skill not loading? al xat.

També podeu exportar i importar aquests registres de depuració ara, la qual cosa és ideal per compartir amb el vostre equip quan alguna cosa no funciona com s’esperava.

Compatibilitat amb imatges i fitxers binaris

Els agents ara poden llegir fitxers d’imatge del disc i fitxers binaris de manera nativa. Els fitxers binaris es presenten en format hexdump i les sortides d’imatge (com les captures de pantalla del navegador integrat) es mostren en una vista de carrusel.

Per als desenvolupadors de.NET, penseu: enganxeu una captura de pantalla d’un error de la interfície d’usuari al xat i feu que l’agent entengui què passa, o feu que analitzi la sortida d’una representació de component Blazor.

Referències de símbols automàtiques

Petita millora de la qualitat de vida: quan copieu un nom de símbol (una classe, un mètode, etc.) i l’enganxeu al xat, ara VS Code el converteix automàticament en una referència #sym:Name. Això proporciona a l’agent un context complet sobre aquest símbol sense que hàgiu d’afegir-lo manualment.

Si voleu text sense format, feu servir Ctrl+Shift+V.

Els connectors ara es poden activar/desactivar

Abans, desactivar un servidor o connector MCP significava desinstal·lar-lo. Ara podeu activar-los i desactivar-los, tant a nivell global com per espai de treball. Feu clic amb el botó dret a la vista Extensions o a la vista Personalitzacions i ja heu acabat.

Els connectors de npm i pypi també es poden actualitzar automàticament ara, tot i que primer demanaran l’aprovació, ja que les actualitzacions signifiquen executar codi nou a la vostra màquina.

Tancant

VS Code 1.112 està clarament empenyent l’experiència de l’agent: més autonomia, millor depuració, seguretat més estricta. Per als desenvolupadors de.NET, la depuració integrada del navegador i les millores de Copilot CLI són les característiques més destacades.

Si encara no heu provat d’executar una sessió CLI Copilot completa en mode Autopilot per a un projecte.NET, aquesta versió és un bon moment per començar. Només recordeu establir els vostres permisos i deixar-ho cuinar.

Descarregueu VS Code 1.112 o actualitzeu-ho des de VS Code mitjançant Ajuda > Comproveu actualitzacions.

Dotnet | The .NET Blog

Hooks d'azd en Python, TypeScript i .NET: adéu als scripts de shell

Hooks, breument

Com funciona la detecció

Detalls importants per llenguatge

Python

JavaScript i TypeScript

.NET

Configuració per executor

Per què importa per a desenvolupadors .NET

Conclusió

Windows App Dev CLI v0.3: F5 des del terminal i automatització de UI per a agents

winapp run: F5 des de qualsevol lloc

Nou paquet NuGet: dotnet run per a apps empaquetades

winapp ui: UI Automation des de la línia de comandes

Altres novetats

Com obtenir-ho

Deixeu de fer de cangur al vostre terminal: el mode desconnectat d'Aspire canvia el flux de treball

Mode desconnectat: una comanda, terminal enrere

Gestionant el que s’està executant

Combina-ho amb el mode aïllat

Per què això és enorme per als agents de codificació

Tancant

El clúster de pins finalment arriba als mapes.NET MAUI: una propietat, zero dolor

Una propietat per governar-les totes

Grups de agrupació independents

Gestió de les aixetes de clúster

Val la pena conèixer els detalls de la plataforma

Per què això és important

Comença

Manteniment de.NET d'abril de 2026: pegats de seguretat que hauríeu d'aplicar avui

Què està pegat

Versions actualitzades

Què fer

L'Azure MCP Server 2.0 s'acaba de caure: l'automatització del núvol agent autoallotjada és aquí

Què és Azure MCP Server?

El gran problema: desplegaments remots autoallotjats

Enduriment de la seguretat

On el pots utilitzar?

Per què això és important per als desenvolupadors de.NET

Primers passos

Tancant

.NET Aspire 13.2 vol ser el millor amic del vostre agent d'IA

El problema és real

Aspira com a infraestructura d’agents

L’analogia del para-xocs de bitlles

Primers passos

Tancant

Connecteu els vostres servidors MCP a les funcions d'Azure amb els agents de Foundry: aquí teniu com

Per què aquesta combinació té sentit

Opcions d’autenticació

Configurant-lo

La meva opinió

Tancant

El mode aïllat d'Aspire soluciona el malson del conflicte del port per al desenvolupament paral·lel

La correcció: --isolated

Escenaris reals on això brilla

Com funciona sota el capó

Quan utilitzar-lo

Tancant

L'avaluació de la modernització de GitHub Copilot és la millor eina de migració que encara no feu servir

No és només un motor de suggeriments de codi

Dues maneres de començar

El desglossament del problema és accionable

Els camins d’actualització coberts

La meva opinió

Tancant

Les aplicacions MCP obtenen una API fluida: creeu interfícies d'usuari d'eines d'IA rica a.NET amb tres passos

Què són les aplicacions MCP?

L’API fluida en tres passos

La superfície de l’API està ben dissenyada

Primers passos

Tancant

C# 15 obté tipus d'unió, i són exactament el que hem estat demanant

El problema que resolen els sindicats

La sintaxi és molt senzilla

On això es fa pràctic

Respostes de l’API que retornen diferents formes

Valor únic o col·lecció

Composició de tipus no relacionats

La correcció: `--isolated`