Containers | The .NET Blog

.NET 10 Arriva con Ubuntu 26.04 LTS — Le Novità

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

È il giorno dell’Ubuntu LTS. Ubuntu 26.04 (Resolute Raccoon) è uscito oggi con .NET 10.

LTS su LTS — cinque anni di supporto per l’OS, in linea con la finestra di supporto a lungo termine di .NET 10.

Installa .NET 10 in due comandi

sudo apt update
sudo apt install dotnet-sdk-10.0

.NET è una delle toolchain ufficialmente supportate su Ubuntu — non un add-on di terze parti.

Container: aggiorna `-noble` a `-resolute`

sed -i "s/noble/resolute/g" Dockerfile

Native AOT: avvio in 3ms, binario da 1,4MB

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# binario nativo da 1,4MB, avvio in 3ms

Per carichi di lavoro cloud-native dove il tempo di cold-start conta — Functions, container, serverless — un vero cambio di gioco.

Hai bisogno di .NET 8 o 9?

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

Il post completo ha più dettagli.

Aspire 13.2: Supporto Bun, Contenitori Migliori e Meno Attrito nel Debug

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se stai costruendo backend .NET con frontend JavaScript in Aspire, la 13.2 è l’aggiornamento che migliora silenziosamente la tua giornata.

Bun è Ora di Prima Classe

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Se il tuo team usa già Bun, Aspire non ti costringe più a nuotare controcorrente.

Yarn Più Affidabile

Gli utenti Yarn ottengono meno errori misteriosi con withYarn() e addViteApp().

Miglioramenti ai Container

ImagePullPolicy.Never per usare l’immagine locale senza andare al registry. PostgreSQL 18+ con volumi di dati ora funziona correttamente.

Miglioramenti al Debug

DebuggerDisplayAttribute sui tipi core
Messaggi di errore migliori per WaitFor
BeforeResourceStartedEvent si attiva al momento giusto

Post originale di David Pine: Aspire 13.2: Bun Support and Container Enhancements.

Dove dovresti ospitare i tuoi agenti IA su Azure? Una guida decisionale pratica

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se stai costruendo agenti IA con .NET in questo momento, probabilmente hai notato qualcosa: ci sono molti modi per ospitarli su Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — e tutti sembrano ragionevoli finché non devi effettivamente sceglierne uno. Microsoft ha appena pubblicato una guida completa all’hosting di agenti IA su Azure che chiarisce tutto, e voglio analizzarla dalla prospettiva pratica di uno sviluppatore .NET.

Le sei opzioni a colpo d’occhio

Ecco come riassumerei il panorama:

Opzione	Ideale per	Gestisci tu
Container Apps	Controllo totale dei container senza complessità K8s	Osservabilità, stato, ciclo di vita
AKS	Compliance aziendale, multi-cluster, networking personalizzato	Tutto (è quello il punto)
Azure Functions	Task di agenti event-driven e di breve durata	Quasi niente — serverless vero
App Service	Agenti HTTP semplici, traffico prevedibile	Deploy, config di scaling
Foundry Agents	Agenti senza codice via portale/SDK	Quasi niente
Foundry Hosted Agents	Agenti con framework personalizzato e infra gestita	Solo il tuo codice agente

Le prime quattro sono compute general-purpose — puoi eseguire agenti su di esse, ma non sono state progettate per quello. Le ultime due sono native per agenti: comprendono conversazioni, chiamate a strumenti e cicli di vita degli agenti come concetti di prima classe.

Foundry Hosted Agents — il punto ideale per sviluppatori .NET di agenti

Questo è ciò che ha catturato la mia attenzione. I Foundry Hosted Agents si posizionano proprio nel mezzo: ottieni la flessibilità di eseguire il tuo codice (Semantic Kernel, Agent Framework, LangGraph — qualsiasi cosa) ma la piattaforma gestisce infrastruttura, osservabilità e gestione delle conversazioni.

Il pezzo chiave è l’Hosting Adapter — un sottile livello di astrazione che collega il tuo framework di agenti alla piattaforma Foundry. Per Microsoft Agent Framework, appare così:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Questa è tutta la tua storia di hosting. L’adapter gestisce traduzione di protocolli, streaming via server-sent events, cronologia delle conversazioni e tracing OpenTelemetry — tutto automaticamente. Nessun middleware personalizzato, nessun plumbing manuale.

Il deploy è genuinamente semplice

Ho fatto deploy di agenti su Container Apps prima e funziona, ma finisci per scrivere molto codice di collegamento per gestione dello stato e osservabilità. Con Hosted Agents e azd, il deploy è:

# Installare l'estensione agente IA
azd ext install azure.ai.agents

# Inizializzare da un template
azd ai agent init

# Costruire, pushare, fare deploy — fatto
azd up

Quel singolo azd up costruisce il tuo container, lo pusha su ACR, provisiona il progetto Foundry, fa deploy degli endpoint del modello e avvia il tuo agente. Cinque passaggi condensati in un solo comando.

Gestione conversazioni integrata

Questa è la parte che fa risparmiare più tempo in produzione. Invece di costruire il tuo store di stato delle conversazioni, gli Hosted Agents lo gestiscono nativamente:

# Creare una conversazione persistente
conversation = openai_client.conversations.create()

# Primo turno
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Secondo turno — il contesto è preservato
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Niente Redis. Niente session store Cosmos DB. Niente middleware personalizzato per la serializzazione dei messaggi. La piattaforma semplicemente se ne occupa.

Il mio framework decisionale

Dopo aver esaminato tutte e sei le opzioni, ecco il mio modello mentale rapido:

Hai bisogno di zero infrastruttura? → Foundry Agents (portale/SDK, niente container)
Hai codice agente personalizzato ma vuoi hosting gestito? → Foundry Hosted Agents
Hai bisogno di task agente event-driven e di breve durata? → Azure Functions
Hai bisogno di massimo controllo dei container senza K8s? → Container Apps
Hai bisogno di compliance rigorosa e multi-cluster? → AKS
Hai un agente HTTP semplice con traffico prevedibile? → App Service

Per la maggior parte degli sviluppatori .NET che costruiscono con Semantic Kernel o Microsoft Agent Framework, Hosted Agents è probabilmente il punto di partenza giusto. Ottieni scale-to-zero, OpenTelemetry integrato, gestione conversazioni e flessibilità di framework — senza gestire Kubernetes o montare il tuo stack di osservabilità.

Per concludere

Il panorama dell’hosting di agenti su Azure sta maturando velocemente. Se stai iniziando un nuovo progetto di agente IA oggi, considererei seriamente Foundry Hosted Agents prima di ricorrere a Container Apps o AKS per abitudine. L’infrastruttura gestita fa risparmiare tempo reale, e il pattern hosting adapter ti permette di mantenere la tua scelta di framework.

Dai un’occhiata alla guida completa di Microsoft e al repo Foundry Samples per esempi funzionanti.

azd ora permette di eseguire e debuggare agenti IA localmente — Ecco cosa è cambiato a marzo 2026

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Sette rilasci in un mese. È quello che il team dell’Azure Developer CLI (azd) ha pubblicato a marzo 2026, e la funzionalità principale è quella che stavo aspettando: un loop locale di esecuzione e debug per agenti IA.

PC Chan ha pubblicato il riepilogo completo, e anche se c’è molto contenuto, lasciatemi filtrare ciò che conta davvero per gli sviluppatori .NET che costruiscono app con IA.

Eseguire e debuggare agenti IA senza deploy

Questa è la novità principale. La nuova estensione azure.ai.agents aggiunge comandi che danno un’esperienza di inner-loop adeguata per gli agenti IA:

azd ai agent run — avvia il tuo agente localmente
azd ai agent invoke — gli invia messaggi (locale o in produzione)
azd ai agent show — mostra lo stato del container e la sua salute
azd ai agent monitor — trasmette i log del container in tempo reale

Prima, testare un agente IA significava fare deploy su Microsoft Foundry ogni volta che facevi un cambiamento. Ora puoi iterare localmente, testare il comportamento del tuo agente, e fare deploy solo quando sei pronto.

GitHub Copilot configura il tuo progetto azd

azd init ora offre un’opzione “Set up with GitHub Copilot (Preview)”. Invece di rispondere manualmente ai prompt, un agente Copilot genera la configurazione per te. Quando un comando fallisce, azd offre troubleshooting assistito dall’IA — tutto senza lasciare il terminale.

Container App Jobs e miglioramenti del deployment

Container App Jobs: azd ora fa deploy di Microsoft.App/jobs tramite la config esistente host: containerapp.
Timeout configurabili: Nuovo flag --timeout su azd deploy e campo deployTimeout in azure.yaml.
Fallback di build remoto: Quando il build ACR fallisce, azd passa automaticamente a Docker/Podman locale.
Validazione preflight locale: I parametri Bicep vengono validati localmente prima del deploy.

Miglioramenti DX

Rilevamento automatico pnpm/yarn per progetti JS/TS
Supporto pyproject.toml per Python
Directory template locali — azd init --template accetta percorsi del filesystem
Messaggi di errore migliori in modalità --no-prompt
Variabili d’ambiente di build iniettate in tutti i sottoprocessi di build (.NET, Node.js, Java, Python)

Per concludere

Il loop locale di debug per agenti IA è la star di questa release, ma l’accumulo di miglioramenti al deployment e alla DX rende azd più maturo che mai. Se fai deploy di app .NET su Azure — specialmente agenti IA — questo aggiornamento vale la pena.

Consulta le note di rilascio complete per tutti i dettagli.

Containers | The .NET Blog

.NET 10 Arriva con Ubuntu 26.04 LTS — Le Novità

Installa .NET 10 in due comandi

Container: aggiorna -noble a -resolute

Native AOT: avvio in 3ms, binario da 1,4MB

Hai bisogno di .NET 8 o 9?

Aspire 13.2: Supporto Bun, Contenitori Migliori e Meno Attrito nel Debug

Bun è Ora di Prima Classe

Yarn Più Affidabile

Miglioramenti ai Container

Miglioramenti al Debug

Dove dovresti ospitare i tuoi agenti IA su Azure? Una guida decisionale pratica

Le sei opzioni a colpo d’occhio

Foundry Hosted Agents — il punto ideale per sviluppatori .NET di agenti

Il deploy è genuinamente semplice

Gestione conversazioni integrata

Il mio framework decisionale

Per concludere

azd ora permette di eseguire e debuggare agenti IA localmente — Ecco cosa è cambiato a marzo 2026

Eseguire e debuggare agenti IA senza deploy

GitHub Copilot configura il tuo progetto azd

Container App Jobs e miglioramenti del deployment

Miglioramenti DX

Per concludere

Container: aggiorna `-noble` a `-resolute`