Developer-Tools | The .NET Blog

El Azure MCP Server Ara és un .mcpb — Instal·la'l sense Cap Runtime

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

Aquest post ha estat traduït automàticament. Per a la versió original, fes clic aquí.

Saps el que era molest de configurar servidors MCP? Necessitaves un runtime. Node.js per a la versió npm, Python per a pip/uvx, .NET SDK per a la variant dotnet.

L’Azure MCP Server acaba de canviar això. Ara està disponible com a .mcpb — un MCP Bundle — i la configuració és arrossegar i deixar anar.

Què és un MCP Bundle?

Pensa-hi com una extensió de VS Code (.vsix) o una extensió de navegador (.crx), però per a servidors MCP. Un fitxer .mcpb és un arxiu ZIP autònom que inclou el binari del servidor i totes les seves dependències.

Com instal·lar-lo

1. Descarrega el bundle per a la teva plataforma

Ves a la pàgina de GitHub Releases i descarrega el fitxer .mcpb per al teu OS i arquitectura.

2. Instal·la a Claude Desktop

La manera més fàcil: arrossega i deixa anar el fitxer .mcpb a la finestra de Claude Desktop mentre estàs a la pàgina de configuració d’Extensions. Revisa els detalls del servidor, fes clic a Instal·la i confirma.

3. Autentifica’t a Azure

az login

Per a començar

Descarrega: GitHub Releases
Repositori: aka.ms/azmcp

Consulta el post complet per a més detalls.

VS Code 1.118: Copilot CLI Obté Noms de Sessió, Insígnies de Model i TypeScript 7.0 Nightly

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

Aquest post ha estat traduït automàticament. Per a la versió original, fes clic aquí.

Visual Studio Code 1.118 és un llançament petit i enfocat — principalment millores de Copilot CLI.

Copilot CLI: les sessions ara tenen noms reals

Les APIs de títol de sessió del SDK de Copilot CLI s’utilitzen ara com a font de veritat. Les sessions mostren el nom real del SDK en lloc d’etiquetes auto-generades.

Canvia de sessió amb dreceres de teclat

L’app d’Agents ara té Ctrl+1, Ctrl+2, etc. per canviar ràpidament entre sessions.

Insígnies de model al xat

Les respostes de Copilot CLI al panell de xat ara mostren una insígnia de model per veure quin model ha gestionat cada sol·licitud.

Selecció automàtica de model a Copilot CLI

La selecció automàtica de model — anteriorment disponible en altres parts de Copilot — ara funciona també a l’agent Copilot CLI.

Opt-in a TypeScript 7.0 nightly

Ara pots optar per provar els nightly de TypeScript 7.0 directament des de la configuració de VS Code.

Consulta les notes de versió completes.

Foundry Toolboxes: Un únic endpoint per a totes les eines dels teus 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í.

Hi ha un problema que sembla avorrit fins que el pateixes de primera mà: la teva organització està construint múltiples agents d’IA, cadascun necessita eines, i cada equip les connecta des de zero. La mateixa integració de cerca web, la mateixa config d’Azure AI Search, la mateixa connexió al servidor MCP de GitHub — però en un altre repositori, per un altre equip, amb altres credencials i sense cap governança compartida.

Microsoft Foundry acaba de llançar Toolboxes en preview pública, i és una resposta directa a aquest problema.

Què és un Toolbox?

Un Toolbox és un bundle d’eines amb nom, reutilitzable, que defineixes una vegada a Foundry i exposes a través d’un únic endpoint compatible amb MCP. Qualsevol runtime d’agent que parli MCP pot consumir-lo — no estàs bloquejat a Foundry Agents.

La proposta és simple: build once, consume anywhere. Defineix les eines, configura l’autenticació de forma centralitzada, publica l’endpoint. Cada agent que necessiti les eines es connecta a l’endpoint i les obté totes.

Els quatre pilars (dos disponibles avui)

Pilar	Estat	Què fa
Discover	Pròximament	Troba eines aprovades sense buscar manualment
Build	Disponible avui	Agrupa eines en un bundle reutilitzable
Consume	Disponible avui	Un únic endpoint MCP exposa totes les eines
Govern	Pròximament	Auth centralitzada + observabilitat en totes les crides

Exemple pràctic

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Cerca documentació i respon a issues de GitHub.",
 tools=[
 {"type": "web_search", "description": "Cerca documentació pública"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Un cop publicat, Foundry et dona un endpoint unificat. Un punt de connexió, totes les eines.

No estàs bloquejat a Foundry Agents

Els Toolboxes es creen i gestionen a Foundry, però la superfície de consum és el protocol MCP obert. Pots usar-los des d’agents personalitzats amb Microsoft Agent Framework o LangGraph, GitHub Copilot i qualsevol runtime que parli MCP.

Per què importa ara

L’onada multi-agent està arribant a producció. Cada nou agent és una nova superfície per a configuració duplicada, credencials desfasades i comportament inconsistent. La base de Build + Consume és suficient per començar a centralitzar. Quan arribi el pilar Govern, tindràs una capa d’eines observable i controlada centralment per a tota la teva flota d’agents.

Conclusió

Això és aviat — preview pública, SDK Python primer. Però el model és sòlid i el disseny natiu MCP significa que funciona amb les eines que ja estàs construint. Fes una ullada a l’anunci oficial per començar.

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.

VS Code 1.117: Els agents s'estan guanyant les seves pròpies branques Git i això m'encanta

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

La línia entre “assistència IA” i “company de feina IA” cada cop és més fina. VS Code 1.117 acaba d’arribar i les notes completes de la versió venen carregades, però el missatge és clar: els agents s’estan convertint en ciutadans de primera classe del teu flux de treball de desenvolupament.

Això és el que realment importa.

El mode Autopilot finalment recorda la teva preferència

Abans, havies de reactivar Autopilot cada vegada que començaves una sessió nova. Molest. Ara el teu mode de permisos es manté entre sessions i pots configurar el valor per defecte.

L’Agent Host admet tres configuracions de sessió:

Per defecte — les eines demanen confirmació abans d’executar-se
Bypass — aprova automàticament tot
Autopilot — totalment autònom, respon les seves pròpies preguntes i continua fins que la tasca s’acaba

Si estàs preparant un projecte .NET nou amb migracions, Docker i CI, configura-ho una vegada en mode Autopilot i oblida-t’en. Aquesta preferència es manté.

Aïllament de worktree i Git per a sessions d’agents

Aquesta és la gran novetat. Les sessions d’agents ara admeten un aïllament complet de worktree i Git. Això vol dir que, quan un agent treballa en una tasca, obté la seva pròpia branca i el seu propi directori de treball. La teva branca principal queda intacta.

I encara millor: Copilot CLI genera noms de branca significatius per a aquestes sessions de worktree. Res de agent-session-abc123. Obtens alguna cosa que realment descriu el que l’agent està fent.

Per als desenvolupadors .NET que treballen amb diverses branques de funcionalitat o arreglen errors mentre corre una tasca llarga d’esqueletatge de projecte, això canvia les regles del joc. Pots tenir un agent construint els controladors de l’API en un worktree mentre tu depures un problema a la capa de serveis en un altre. Sense conflictes. Sense stash. Sense embolics.

Subagents i equips d’agents

El protocol Agent Host ara admet subagents. Un agent pot engegar altres agents per encarregar-los parts d’una tasca. Pensa-ho com delegar: el teu agent principal coordina i els agents especialitzats fan les peces concretes.

Això encara és una funcionalitat inicial, però el potencial per als fluxos de treball .NET és evident. Imagina un agent gestionant les teves migracions d’EF Core mentre un altre prepara els tests d’integració. Encara no hi som del tot, però el suport al protocol que arriba ara farà que les eines segueixin ràpidament.

La sortida del terminal s’inclou automàticament quan els agents envien entrada

Petita, però important. Quan un agent envia entrada al terminal, la sortida del terminal s’inclou automàticament al context. Abans, l’agent havia de fer un torn extra només per llegir què havia passat.

Si mai has vist un agent executar dotnet build, fallar i després fer una altra ronda només per llegir l’error, aquesta fricció desapareix. Ho veu de seguida i reacciona.

L’app d’Agents s’actualitza sola a macOS

L’aplicació d’Agents independent per a macOS ara s’actualitza sola. Ja no cal descarregar noves versions manualment. Simplement es manté al dia.

El que val la pena saber de la resta

Els hovers de package.json ara mostren tant la versió instal·lada com la més recent. Útil si gestiones eines npm al costat dels teus projectes .NET.
Les imatges als comentaris JSDoc es renderitzen correctament als hovers i a les completes.
Les sessions de Copilot CLI ara indiquen si s’han creat des de VS Code o externament, cosa útil quan saltes entre terminals.
Copilot CLI, Claude Code i Gemini CLI es reconeixen com a tipus de shell. L’editor sap què estàs executant.

La conclusió

VS Code 1.117 no és un llançament ple de funcions espectaculars. És infraestructura. L’aïllament de worktrees, els permisos persistents i els protocols de subagents són els blocs de construcció d’un flux de treball on els agents gestionen tasques reals en paral·lel sense trepitjar-se el codi.

Si estàs construint amb .NET i encara no t’has llançat al flux de treball agentic, sincerament, ara és el moment de començar.

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.

Docker Sandbox permet als agents Copilot refactoritzar el vostre codi sense posar en risc la vostra màquina

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

Si heu utilitzat el mode d’agent de Copilot per a qualsevol cosa més enllà de petites edicions, coneixeu el dolor. Cada escriptura de fitxers, cada ordre del terminal: un altre indicador de permís. Ara imagineu-ho fent servir 50 projectes. No és divertit.

L’equip d’Azure acaba de publicar una publicació sobre Docker Sandbox for GitHub Copilot agents, i sincerament, aquesta és una de les millores d’eines d’agents més pràctiques que he vist. Utilitza microVMs per oferir a Copilot un entorn totalment aïllat on es pot desenredar: instal·lar paquets, executar compilacions, executar proves, sense tocar el vostre sistema amfitrió.

Què us ofereix realment Docker Sandbox

La idea bàsica és senzilla: engegueu una microVM lleugera amb un entorn Linux complet, sincronitzeu-hi el vostre espai de treball i deixeu que l’agent Copilot operi lliurement a l’interior. Quan s’hagi acabat, torna a canviar la sincronització.

Això és el que fa que sigui més que “executar coses en un contenidor”:

Sincronització bidireccional de l’espai de treball que conserva camins absoluts. L’estructura del vostre projecte sembla idèntica dins del sandbox. No hi ha errors de compilació relacionats amb el camí.
Dimoni Docker privat que s’executa dins de la microVM. L’agent pot construir i executar contenidors sense muntar mai el sòcol Docker del vostre host. Això és un gran problema per a la seguretat.
Proxis de filtratge HTTP/HTTPS que controlen a què pot arribar l’agent a la xarxa. Tu decideixes quins registres i punts finals es permeten. Atacs a la cadena de subministrament d’un canalla npm install dins del sandbox? Bloquejat.
Mode YOLO — sí, així l’anomenen. L’agent s’executa sense sol·licituds de permís perquè literalment no pot danyar el vostre amfitrió. Tota acció destructiva està continguda.

Per què els desenvolupadors.NET haurien de preocupar-se

Penseu en el treball de modernització que tants equips s’enfronten ara mateix. Teniu una solució.NET Framework amb 30 projectes i l’heu de traslladar a.NET 9. Això són centenars de canvis de fitxers: fitxers de projecte, actualitzacions d’espais de noms, substitucions d’API, migracions NuGet.

Amb Docker Sandbox, podeu apuntar un agent Copilot a un projecte, deixar-lo refactoritzar lliurement dins de la microVM, executar dotnet build i dotnet test per validar i acceptar només els canvis que funcionen realment. No hi ha cap risc que accidentalment destrueixi el vostre entorn de desenvolupament local mentre experimenteu.

La publicació també descriu l’execució d’una flota d’agents paral·lels, cadascun en el seu propi sandbox, abordant diferents projectes simultàniament. Per a grans solucions.NET o arquitectures de microserveis, això suposa un estalvi de temps enorme. Un agent per servei, tots en funcionament aïllat, tots validats de manera independent.

L’angle de seguretat és important

Això és el que la majoria de la gent passa per alt: quan deixeu que un agent d’IA executi ordres arbitràries, hi confieu amb tota la vostra màquina. Docker Sandbox canvia aquest model. L’agent obté total autonomia dins d’un entorn d’ús. El servidor intermediari de xarxa garanteix que només es pot extreure de fonts aprovades. El vostre sistema de fitxers amfitrió, el dimoni Docker i les credencials no es toquen.

Per als equips amb requisits de compliment, i això és la majoria de les botigues.NET empresarials, aquesta és la diferència entre “no podem utilitzar IA agència” i “podem adoptar-la de manera segura”.

Per emportar

Docker Sandbox resol la tensió fonamental de la codificació agentica: els agents necessiten llibertat per ser útils, però la llibertat a la vostra màquina amfitriona és perillosa. Les microVM us ofereixen tots dos. Si esteu planejant qualsevol refactorització o modernització de.NET a gran escala, val la pena configurar-la ara. La combinació de la intel·ligència de codi de Copilot amb un entorn d’execució segur és exactament el que els equips de producció estaven esperant.

Les eines MCP d'Azure s'incorporen ara a Visual Studio 2022: no es requereix cap extensió

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

Si heu estat utilitzant les eines de l’Azure MCP a Visual Studio mitjançant l’extensió separada, ja coneixeu l’exercici: instal·leu el VSIX, reinicieu, espereu que no es trenqui, gestioneu els desajustos de versions. Aquesta fricció ha desaparegut.

Yun Jung Choi va anunciar que les eines d’Azure MCP ara s’envien directament com a part de la càrrega de treball de desenvolupament d’Azure a Visual Studio 2022. Sense extensió. No VSIX. No reinicia el ball.

Què significa realment això

A partir de la versió 17.14.30 de Visual Studio 2022, l’Azure MCP Server s’inclou amb la càrrega de treball de desenvolupament d’Azure. Si ja teniu aquesta càrrega de treball instal·lada, només cal que l’activeu a GitHub Copilot Chat i ja heu acabat.

Més de 230 eines en 45 serveis Azure, accessibles directament des de la finestra de xat. Enumereu els vostres comptes d’emmagatzematge, implementeu una aplicació ASP.NET Core, diagnostiqueu problemes del servei d’aplicacions, consulteu Log Analytics, tot sense obrir una pestanya del navegador.

Per què això importa més del que sembla

Això és el que passa amb les eines per a desenvolupadors: cada pas addicional és fricció i la fricció mata l’adopció. Tenir MCP com a extensió independent significava desajustos de versions, errors d’instal·lació i una cosa més a mantenir actualitzada. Incorporar-lo a la càrrega de treball significa:

Camí d’actualització únic mitjançant l’instal·lador de Visual Studio
Sense deriva de versió entre l’extensió i l’IDE
Sempre actual: el servidor MCP s’actualitza amb versions regulars de VS

Per als equips que s’estandarditzen a Azure, això és un gran problema. Instal·leu la càrrega de treball una vegada, activeu les eines i hi són per a cada sessió.

Què pots fer amb ell

Les eines cobreixen tot el cicle de vida del desenvolupament mitjançant Copilot Chat:

Aprendre: pregunteu sobre els serveis d’Azure, les pràctiques recomanades i els patrons d’arquitectura
Disseny i desenvolupament: obteniu recomanacions de servei, configureu el codi de l’aplicació
Desplega: proveïu recursos i implementeu-los directament des de l’IDE
Resolució de problemes: consulteu registres, comproveu l’estat dels recursos, diagnosticeu problemes de producció

Un exemple ràpid: escriviu això a Copilot Chat:

List my storage accounts in my current subscription.

Copilot truca a les eines d’Azure MCP darrere de les escenes, consulta les vostres subscripcions i retorna una llista amb format amb noms, ubicacions i SKU. No cal cap portal.

Com activar-lo

Actualització a Visual Studio 2022 17.14.30 o superior
Assegureu-vos que la càrrega de treball Desenvolupament d’Azure estigui instal·lada
Obriu GitHub Copilot Chat
Feu clic al botó Selecciona eines (la icona de dues claus)
Activa Servidor MCP d’Azure

Això és tot. Es manté activat durant les sessions.

Una advertència

Les eines estan desactivades de manera predeterminada: heu d’activar-les. I les eines específiques de VS 2026 no estan disponibles a VS 2022. La disponibilitat de les eines també depèn dels vostres permisos de subscripció a Azure, igual que el portal.

La imatge més gran

Això forma part d’una tendència clara: MCP s’està convertint en la forma estàndard d’aprofitar les eines de núvol en els IDE de desenvolupadors. Ja hem vist la versión estable d’Azure MCP Server 2.0 i les integracions MCP a VS Code i altres editors. Tenir-lo integrat al sistema de càrrega de treball de Visual Studio és la progressió natural.

Per als desenvolupadors de.NET que vivim a Visual Studio, això elimina un altre motiu per canviar de context al portal Azure. I sincerament, com menys canvis de pestanya, millor.

azd update: una comanda per controlar tots els vostres gestors de paquets

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

Sabeu que el missatge “Hi ha una versió nova d’azd disponible” que apareix cada poques setmanes? El que descarteu perquè no recordeu si vau instal·lar azd mitjançant winget, Homebrew o aquell script curl que vau executar fa sis mesos? Sí, finalment s’ha arreglat.

Microsoft acaba d’enviar azd update: una ordre única que actualitza l’Azure Developer CLI a la darrera versió, independentment de com l’haveu instal·lat originalment. Windows, macOS, Linux, no importa. Una ordre.

Com funciona

azd update

Això és tot. Si voleu un accés anticipat a noves funcions, podeu canviar a la creació diària d’insiders:

azd update --channel daily
azd update --channel stable

L’ordre detecta el vostre mètode d’instal·lació actual i utilitza el mecanisme d’actualització adequat sota el capó. No més “espera, he fet servir winget o choco en aquesta màquina?”

La petita captura

azd update s’envia a partir de la versió 1.23.x. Si teniu una versió anterior, haureu de fer una darrera actualització manual mitjançant el vostre mètode d’instal·lació original. Després d’això, azd update s’encarrega de tot el futur.

Comproveu la vostra versió actual amb azd version. Si necessiteu una instal·lació nova, els documents d’instal·lació us cobreixen.

Per què és important

Aquesta és una petita millora de la qualitat de vida, però per a aquells de nosaltres que utilitzem azd diàriament per desplegar agents d’IA i aplicacions Aspire a Azure, mantenir-se al dia significa menys moments “aquest error ja s’ha solucionat a la darrera versió”. Una cosa menys per pensar.

Llegiu l’anunci complet i la immersió més profunda de Jon Gallant per a més context.

.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ó.

Aquella configuració de Windows flotant de Visual Studio que no sabíeu (però hauríeu)

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

Si utilitzeu diversos monitors amb Visual Studio (i sincerament, qui no ho fa en aquests dies), probablement heu experimentat la molèstia: les finestres d’eines flotants desapareixen quan minimitzeu l’IDE principal, sempre es mantenen al capdavant de tota la resta i no apareixen com a botons separats de la barra de tasques. Funciona per a alguns fluxos de treball, però per a configuracions de diversos monitors és frustrant.

Mads Kristensen de l’equip de Visual Studio ha compartit una configuració poc coneguda que canvia completament el comportament de les finestres flotants. Un desplegable. Això és tot.

La configuració

Eines > Opcions > Entorn > Windows > Finestres flotants

El menú desplegable “Aquestes finestres flotants són propietat de la finestra principal” té tres opcions:

Cap — total independència. Cada finestra flotant té la seva pròpia entrada a la barra de tasques i es comporta com una finestra normal de Windows.
Tool Windows (per defecte): els documents floten lliurement, les finestres d’eines es mantenen lligades a l’IDE.
Finestres de documents i eines: comportament clàssic de Visual Studio, tot lligat a la finestra principal.

Per què “Cap” és el moviment per a les configuracions de diversos monitors

Estableix-lo a Cap i, de sobte, totes les teves finestres i documents d’eines flotants es comporten com aplicacions de Windows reals. Apareixen a la barra de tasques, es mantenen visibles quan minimitzeu la finestra principal de Visual Studio i deixen de forçar-se al davant de tot.

Combineu-ho amb PowerToys FancyZones i és un canvi de joc. Creeu dissenys personalitzats als vostres monitors, col·loqueu el vostre Explorador de solucions a una zona, depureu a una altra i codifiqueu fitxers allà on vulgueu. Tot es manté, tot és accessible de manera independent i el vostre espai de treball se sent organitzat en lloc de caòtic.

Recomanacions ràpides

Usuaris avançats amb monitors múltiples: s’estableix en Cap, s’acobla amb FancyZones
Flotants ocasionals: Tool Windows (per defecte) és un sòlid terme mitjà
Flux de treball tradicional: Documents i Windows Tool manté tot el clàssic

Consell professional: Ctrl + feu doble clic a la barra de títol de qualsevol finestra d’eina per flotar o acoblar-la a l’instant. No cal reiniciar després de canviar la configuració.

Tancant

És una d’aquestes configuracions “No em puc creure que no sabia sobre això”. Si alguna vegada les finestres flotants a Visual Studio us han molestat, aneu a canviar-ho ara mateix.

Llegiu la publicació completa per obtenir els detalls i les captures de pantalla.

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.

VS Code 1.116: l'aplicació d'agents obté la navegació per teclat i la finalització del context dels fitxers

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

VS Code 1.116 és la versió d’abril de 2026 i, tot i que és més lleuger que algunes actualitzacions recents, els canvis són enfocats i significatius, sobretot si feu servir l’aplicació Agents diàriament.

Aquí teniu el que va arribar, basat en les notes oficials de la versió.

Millores de l’aplicació d’agents

L’aplicació Agents continua madurant amb un poliment d’usabilitat que marca una diferència real en els fluxos de treball diaris:

Combinacions de tecles dedicades: ara podeu centrar la vista Canvis, l’arbre de fitxers dins de Canvis i la vista Personalitzacions de xat amb ordres dedicades i dreceres de teclat. Si heu fet clic per l’aplicació Agents per navegar, això ofereix fluxos de treball complets basats en el teclat.

Diàleg d’ajuda d’accessibilitat: prement Alt+F1 al quadre d’entrada del xat ara s’obre un diàleg d’ajuda d’accessibilitat que mostra les ordres i les combinacions de tecles disponibles. Els usuaris de lectors de pantalla també poden controlar la verbositat dels anuncis. Una bona accessibilitat beneficia a tothom.

Completacions de context de fitxer: escriviu # al xat de l’aplicació Agents per activar les finalitzacions de context de fitxer a l’abast del vostre espai de treball actual. Aquesta és una d’aquelles petites millores de qualitat de vida que acceleren cada interacció; ja no cal escriure els camins complets dels fitxers quan es fa referència al codi.

CSS `@import` resolució d’enllaç

Una bona per als desenvolupadors d’interfície: ara VS Code resol les referències CSS @import que utilitzen camins node_modules. Podeu Ctrl+click mitjançant importacions com @import "some-module/style.css" quan utilitzeu agrupadors. Petit però elimina un punt de fricció en els fluxos de treball CSS.

Tancant

VS Code 1.116 tracta de perfeccionament, fent que l’aplicació Agents sigui més navegable, més accessible i més amigable amb el teclat. Si passeu molt de temps a l’aplicació Agents (i sospito que molts de nosaltres ho estem), aquests canvis s’acumulen.

Consulteu les notes completes de la versió per obtenir la llista completa.

VS Code 1.115: notificacions de terminal en segon pla, mode d'agent SSH i més

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 acaba de sortir i, tot i que és una versió més lleugera pel que fa a les funcions de titular, les millores relacionades amb l’agent són realment útils si treballeu amb assistents de codificació d’IA diàriament.

Permeteu-me destacar el que realment val la pena saber.

Els terminals de fons parlen amb els agents

Aquesta és la característica destacada. Els terminals de fons ara notifiquen automàticament als agents quan es completen les ordres, inclòs el codi de sortida i la sortida del terminal. Les sol·licituds d’entrada als terminals de fons també es detecten i s’envien a l’usuari.

Per què importa això? Si heu utilitzat el mode d’agent de Copilot per executar ordres de compilació o suites de proves en segon pla, coneixeu el dolor de “Ja s’ha acabat?” — Els terminals de fons eren essencialment de foc i oblidar. Ara l’agent rep una notificació quan el vostre dotnet build o dotnet test s’acabi, veu la sortida i pot reaccionar en conseqüència. És un petit canvi que fa que els fluxos de treball impulsats per agents siguin significativament més fiables.

També hi ha una nova eina send_to_terminal que permet als agents enviar ordres a terminals en segon pla amb la confirmació de l’usuari, solucionant el problema en què run_in_terminal amb un temps d’espera traslladaria els terminals a segon pla i els faria només de lectura.

Allotjament d’agent remot SSH

VS Code ara admet la connexió a màquines remotes mitjançant SSH, instal·lant automàticament la CLI i iniciant-la en mode d’amfitrió de l’agent. Això significa que les vostres sessions d’agent d’IA poden orientar-se directament a entorns remots, cosa que és útil per als desenvolupadors de.NET que creen i proveu en servidors Linux o màquines virtuals en núvol.

Edita el seguiment a les sessions d’agent

Les edicions de fitxers fetes durant les sessions de l’agent ara es fan un seguiment i es restauren, amb diferències, desfer/refer i restauració de l’estat. Si un agent fa canvis al vostre codi i alguna cosa va malament, podeu veure exactament què ha canviat i revertir-lo. Tranquil·litat per deixar que els agents modifiquin la vostra base de codi.

Coneixement de la pestanya del navegador i altres millores

Algunes addicions més de qualitat de vida:

Seguiment de pestanyes del navegador: ara el xat pot fer un seguiment i enllaçar amb les pestanyes del navegador obertes durant una sessió, de manera que els agents poden fer referència a les pàgines web que esteu mirant
Fitxer enganxat al terminal: enganxeu fitxers (incloses les imatges) al terminal amb Ctrl+V, arrossegueu i deixeu anar o feu clic amb el botó dret.
Cobertura de prova al minimapa: ara els indicadors de cobertura de prova es mostren al minimapa per obtenir una visió visual ràpida
Pinch-to-zoom a Mac: el navegador integrat admet gestos de pessigar-to-zoom
Drets de Copilot a Sessions: la barra d’estat mostra la informació d’ús a la vista Sessions
Favicon a Anar al fitxer: les pàgines web obertes mostren favicons a la llista de selecció ràpida

Tancant

VS Code 1.115 és una versió incremental, però les millores de l’agent (notificacions de terminal en segon pla, allotjament d’agents SSH i seguiment d’edició) afegeixen una experiència notablement més fluida per al desenvolupament assistit per IA. Si utilitzeu el mode d’agent de Copilot per a projectes.NET, aquests són els tipus de correccions de qualitat de vida que redueixen la fricció diàriament.

Consulteu les notes completes de la versió per a cada detall.

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.

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.

Azure DevOps finalment soluciona l'UX de l'editor de Markdown de què es va queixar tothom

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

Si utilitzeu Azure Boards, probablement haureu experimentat això: esteu llegint la descripció d’un element de treball, potser revisant els criteris d’acceptació i accidentalment feu doble clic. Boom: esteu en mode d’edició. No volies editar res. Només estaves llegint.

Dan Hellem va anunciar la correcció, i és un d’aquests canvis que sona minúscul però que en realitat elimina la fricció real del vostre flux de treball diari.

Què va canviar

L’editor Markdown per als camps de text d’elements de treball ara s’obre en mode de vista prèvia de manera predeterminada. Podeu llegir i interactuar amb el contingut (seguir enllaços, revisar el format) sense preocupar-vos d’entrar accidentalment al mode d’edició.

Quan realment voleu editar, feu clic a la icona d’edició a la part superior del camp. Quan hàgiu acabat, torneu al mode de previsualització explícitament. Simple, intencionat, previsible.

Això és tot. Aquest és el canvi.

Per què això importa més del que sembla

El fil de comentaris de la comunitat sobre això era llarg. El comportament de fer doble clic per editar es va introduir amb l’editor Markdown el juliol de 2025 i les queixes van començar gairebé immediatament. El problema no eren només les edicions accidentals, sinó que tota la interacció semblava impredictible. Mai no sabíeu si fer clic es llegiria o editaria.

Per als equips que fan planificació d’esprints, preparació de backlog o revisió de codi amb Azure Boards, aquest tipus de compostos de microfricció. Cada entrada accidental del mode d’edició és un canvi de context. Cada “espera, he canviat alguna cosa?” moment és una atenció perduda.

El nou valor predeterminat respecta el patró d’interacció més comú: llegiu els elements de treball amb molta més freqüència que no els editeu.

Estat de llançament

Això ja s’està implementant a un subconjunt de clients i s’ampliarà a tothom durant les properes dues o tres setmanes. Si encara no ho veus, aviat ho faràs.

Tancant

No totes les millores han de ser una característica de titular. De vegades, la millor actualització és simplement eliminar alguna cosa molesta. Aquest és un d’ells: una petita correcció d’UX que fa que Azure Boards se senti menys hostil a les persones que només volen llegir els seus elements de treball amb tranquil·litat.

Bookmark Studio aporta la navegació i l'ús compartit basats en ranures als marcadors de Visual Studio

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

Els marcadors a Visual Studio sempre han estat… bé. En establiu un, navegueu al següent, oblideu quin marcador és quin. Funcionen, però mai han estat el tipus de funció que podríeu dir poderosa.

Mads Kristensen acaba de publicar Bookmark Studio, una extensió experimental que omple exactament els buits que probablement us heu trobat si feu servir els marcadors amb regularitat.

Navegació basada en ranures

L’addició bàsica: ara les adreces d’interès es poden assignar a les ranures 1–9 i passar directament a Alt+Shift+1 a Alt+Shift+9. Les adreces d’interès noves obtenen automàticament la següent ranura disponible, de manera que, en la majoria dels casos, la navegació ràpida funciona sense cap configuració.

Sembla senzill, però canvia les adreces d’interès de “Tinc algunes adreces d’interès en algun lloc” a “L’espai 3 és el meu controlador de l’API, l’espai 5 és la capa de servei, l’espai 7 és la prova”. Aquest tipus de memòria espacial fa que la navegació sigui gairebé instantània durant les sessions de treball concentrades.

El gestor d’adreces d’interès

Una nova finestra d’eines mostra totes les vostres adreces d’interès en un sol lloc amb un filtratge per nom, fitxer, ubicació, color o ranura. Fes doble clic o navega amb el teclat per saltar a qualsevol marcador.

Si alguna vegada heu tingut més de cinc o sis adreces d’interès i heu perdut la pista de quins, només val la pena instal·lar l’extensió.

Organització amb etiquetes, colors i carpetes

Opcionalment, les adreces d’interès poden tenir etiquetes, colors i agrupar-se en carpetes. Res d’això és necessari: el vostre flux de treball de marcador actual continua funcionant. Però quan esteu depurant un problema complex o explorant una base de codi desconeguda, poder codificar amb colors i etiquetar les vostres adreces d’interès afegeix un context útil.

Totes les metadades s’emmagatzemen per solució, de manera que la vostra organització d’adreces d’interès persisteix entre les sessions.

Exporta i comparteix

Aquesta és la funció que no sabia que volia. Bookmark Studio us permet exportar les adreces d’interès com a text sense format, Markdown o CSV. Això vol dir que pots:

Incloeu camins d’adreces d’interès a les descripcions de la sol·licitud d’extracció
Compartiu la investigació amb els companys d’equip
Mou els conjunts d’adreces d’interès entre repositoris o branques

Els marcadors deixen de ser una eina de navegació en solitari i comencen a ser una manera de comunicar-se “aquí teniu el camí a través d’aquest codi”.

Adreces d’interès que fan un seguiment del moviment del codi

Bookmark Studio fa un seguiment de les adreces d’interès en relació al text al qual estan ancorats, de manera que no es desviïn cap a línies incorrectes mentre editeu. Si alguna vegada heu establert adreces d’interès durant una sessió de depuració i heu fet que tots apunten a les línies equivocades després d’un refactor, això ho soluciona.

Tancant

Bookmark Studio no reinventa res. Es necessita una funció que ha estat “prou bona” durant anys i la fa realment útil per al desenvolupament centrat. La navegació per ranures, el Gestor d’adreces d’interès i les capacitats d’exportació són els més destacats.

Agafeu-lo del Visual Studio Marketplace i proveu-ho.

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.

De l'ordinador portàtil a la producció: desplegament d'agents d'IA a Microsoft Foundry amb dues ordres

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

Coneixeu aquesta bretxa entre “funciona a la meva màquina” i “està desplegat i atén el trànsit”? Per als agents d’IA, aquesta bretxa ha estat dolorosament àmplia. Heu de subministrar recursos, desplegar models, connectar la identitat, configurar la supervisió, i això és abans que ningú pugui trucar al vostre agent.

L’Azure Developer CLI acaba de convertir-ho en un assumpte de dos comandaments.

El nou flux de treball `azd ai agent`

Permeteu-me explicar com és realment això. Teniu un projecte d’agent d’IA, diguem-ne un agent de consergeria d’hotel. Funciona localment. Voleu que funcioni a Microsoft Foundry.

azd ai agent init
azd up

Això és tot. Dues ordres. azd ai agent init arma la infraestructura com a codi al vostre dipòsit i azd up proveeix tot a Azure i publica el vostre agent. Obteniu un enllaç directe al vostre agent al portal de Foundry.

Què passa sota el capó

L’ordre init genera plantilles de bíceps reals i inspeccionables al vostre repositori:

Un Recurs de Foundry (contenidor de primer nivell)
Un Projecte de Foundry (on viu el vostre agent)
Configuració del model de desplegament (GPT-4o, etc.)
Identitat gestionada amb assignacions de rol RBAC adequades
azure.yaml per al mapa de serveis
agent.yaml amb metadades de l’agent i variables d’entorn

Aquí teniu la part clau: sou el propietari de tot això. Està versionat Bicep al teu repositori. Podeu inspeccionar-lo, personalitzar-lo i confirmar-lo juntament amb el vostre codi d’agent. Sense capses negres màgiques.

El bucle intern del desenvolupament

El que m’agrada molt és la història del desenvolupament local. Quan esteu iterant la lògica de l’agent, no voleu tornar a desplegar cada vegada que canvieu una sol·licitud:

azd ai agent run

Això inicia el vostre agent localment. Vinculeu-lo amb azd ai agent invoke per enviar sol·licituds de prova i teniu un bucle de comentaris ajustat. Edita el codi, reinicia, invoca, repeteix.

L’ordre invoke també és intel·ligent pel que fa a l’encaminament: quan s’executa un agent local, l’orienta automàticament. Quan no ho és, arriba al punt final remot.

Monitorització en temps real

Aquesta és la característica que em va vendre. Un cop desplegat el vostre agent:

azd ai agent monitor --follow

Cada sol·licitud i resposta que flueix pel vostre agent es transmet al vostre terminal en temps real. Per depurar problemes de producció, això és inestimable. Sense investigar l’analítica de registres, sense esperar que les mètriques s’agreguin; veuràs què està passant ara mateix.

El conjunt d’ordres complet

Aquí teniu la referència ràpida:

Comandament	Què fa
`azd ai agent init`	Armar un projecte d’agent de Foundry amb IaC
`azd up`	Proveïu els recursos d’Azure i implementeu l’agent
`azd ai agent invoke`	Envieu sol·licituds a l’agent local o remot
`azd ai agent run`	Executeu l’agent localment per al desenvolupament
`azd ai agent monitor`	Transmet els registres en temps real de l’agent publicat
`azd ai agent show`	Comproveu l’estat i l’estat de l’agent
`azd down`	Netegeu tots els recursos d’Azure

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

Tot i que la mostra de l’anunci està basada en Python, la història de la infraestructura és independent del llenguatge. El vostre agent.NET obté la mateixa bastida Bíceps, la mateixa configuració d’identitat gestionada, la mateixa canalització de monitorització. I si ja esteu utilitzant azd per a les vostres aplicacions.NET Aspire o implementacions d’Azure, això s’adapta perfectament al vostre flux de treball existent.

La bretxa de desplegament dels agents d’IA ha estat un dels punts de fricció més grans de l’ecosistema. Passar d’un prototip de treball a un punt final de producció amb una identitat, una xarxa i un seguiment adequats no hauria de requerir una setmana de treball DevOps. Ara requereix dues ordres i uns minuts.

Tancant

azd ai agent ja està disponible. Si heu postergat la implementació dels vostres agents d’IA perquè la configuració de la infraestructura us semblava massa feina, proveu-ho. Fes una ullada a la tutorial completa per veure el pas a pas complet, inclosa la integració de l’aplicació de xat frontal.

Developer-Tools | The .NET Blog

El Azure MCP Server Ara és un .mcpb — Instal·la'l sense Cap Runtime

Què és un MCP Bundle?

Com instal·lar-lo

Per a començar

VS Code 1.118: Copilot CLI Obté Noms de Sessió, Insígnies de Model i TypeScript 7.0 Nightly

Copilot CLI: les sessions ara tenen noms reals

Canvia de sessió amb dreceres de teclat

Insígnies de model al xat

Selecció automàtica de model a Copilot CLI

Opt-in a TypeScript 7.0 nightly

Foundry Toolboxes: Un únic endpoint per a totes les eines dels teus agents

Què és un Toolbox?

Els quatre pilars (dos disponibles avui)

Exemple pràctic

No estàs bloquejat a Foundry Agents

Per què importa ara

Conclusió

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

VS Code 1.117: Els agents s'estan guanyant les seves pròpies branques Git i això m'encanta

El mode Autopilot finalment recorda la teva preferència

Aïllament de worktree i Git per a sessions d’agents

Subagents i equips d’agents

La sortida del terminal s’inclou automàticament quan els agents envien entrada

L’app d’Agents s’actualitza sola a macOS

El que val la pena saber de la resta

La conclusió

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

Docker Sandbox permet als agents Copilot refactoritzar el vostre codi sense posar en risc la vostra màquina

Què us ofereix realment Docker Sandbox

Per què els desenvolupadors.NET haurien de preocupar-se

L’angle de seguretat és important

Per emportar

Les eines MCP d'Azure s'incorporen ara a Visual Studio 2022: no es requereix cap extensió

Què significa realment això

Per què això importa més del que sembla

Què pots fer amb ell

Com activar-lo

Una advertència

La imatge més gran

azd update: una comanda per controlar tots els vostres gestors de paquets

Com funciona

La petita captura

Per què és important

.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

Aquella configuració de Windows flotant de Visual Studio que no sabíeu (però hauríeu)

La configuració

Per què “Cap” és el moviment per a les configuracions de diversos monitors

Recomanacions ràpides

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

La correcció: `--isolated`

CSS `@import` resolució d’enllaç

El nou flux de treball `azd ai agent`