Containers | The .NET Blog

.NET 10 Ships with Ubuntu 26.04 LTS — Here's What's New

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

It’s Ubuntu LTS day. Ubuntu 26.04 (Resolute Raccoon) launched today, and as with every Ubuntu LTS, it ships with the latest .NET LTS — in this case, .NET 10.

If you deploy .NET apps on Linux, this is the release cycle you care about. LTS on LTS — five years of support for the OS, matching .NET 10’s own long-term support window.

Install .NET 10 in two commands

sudo apt update
sudo apt install dotnet-sdk-10.0

That’s it. .NET is one of the officially supported toolchains on Ubuntu — not a third-party add-on. Microsoft and Canonical work together to make sure it works on day one.

Try it immediately

Here’s the thing I love about this: you can pull an ubuntu:resolute container image and be running C# in under a minute.

docker run --rm -it ubuntu:resolute
apt update
apt install -y dotnet-sdk-10.0
dotnet run - << 'EOF'
using System.Runtime.InteropServices;
Console.WriteLine($"Hello {RuntimeInformation.OSDescription} from .NET {RuntimeInformation.FrameworkDescription}");
EOF

That dotnet run - with a heredoc is a file-based app pattern — no project file, no directory, just C# piped to stdin. Honest, if you haven’t tried file-based apps yet, it’s worth a look.

Containers: update `-noble` to `-resolute`

The new container images use the resolute tag. Migration is a one-liner:

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

All existing image flavors — including Chiseled — are available. The Chiseled images are still my go-to for production: minimal attack surface, no shell, no package manager, just the runtime. Update the tag and rebuild.

Native AOT: 3ms startup, 1.4MB binary

Ubuntu 26.04 ships a dedicated AOT package:

apt install -y dotnet-sdk-aot-10.0 clang

Here’s what you get when you publish a simple app:

dotnet publish app.cs
# artifacts/app/app — 1.4MB native binary

Startup time:

real 0m0.003s

3 milliseconds. For a full ASP.NET Core web service, the self-contained binary is around 13MB. That’s a completely self-contained deployable with no runtime dependency whatsoever.

For cloud-native workloads where cold-start time matters — Functions, containers, serverless — this is a legitimate game changer.

What changed in Ubuntu 26.04 that affects .NET

Three things worth knowing:

Linux 7.0 — The .NET team will start Linux 7.0 testing once they get 26.04 VMs in the lab. No breaking changes expected, but they’ll verify.
Post-quantum cryptography — Ubuntu 26.04 introduces PQC support, and .NET 10 added post-quantum cryptography APIs as well. Good alignment.
cgroup v1 removed — Ubuntu 26.04 drops cgroup v1. .NET added cgroup v2 support years ago, so this is a non-event. But if you’re on an older runtime, double-check.

Need .NET 8 or 9?

Those are available via the dotnet-backports PPA:

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

Support is “best-effort” — not the same guarantee as the LTS package in the main archive — but the packages are there and they work.

Wrapping up

Every two years, the Ubuntu LTS + .NET LTS alignment gives you a solid, long-support foundation for production workloads. Ubuntu 26.04 with .NET 10 is that foundation for the next cycle.

If you’re containerizing .NET apps, update your Dockerfiles. If you’re deploying on bare metal or VMs, apt install dotnet-sdk-10.0 and you’re done.

Read the full post from Richard Lander for the complete installation walkthrough and container details.

Aspire 13.2 Gets Bun, Better Containers, and Less Debugging Friction

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

If you’ve been building .NET backends with JavaScript frontends in Aspire, 13.2 is the kind of update that quietly makes your day better. No splashy new paradigms. Just solid improvements to things that were mildly annoying.

Let’s walk through what actually landed.

Bun is Now a First-Class Citizen

The headline feature: Bun support for Vite apps in Aspire. One fluent call, done.

// TypeScript AppHost
const builder = await createBuilder();

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

await builder.build().run();

If your team already uses Bun — which you might, given its dramatically faster install times and startup — Aspire no longer makes you fight against the grain. Previously, Aspire assumed npm and you had to work around it. Now .withBun() is a first-class option alongside .withYarn() and the default npm behavior.

Why does this matter? Because JavaScript tooling speed directly affects your inner dev loop. If your frontend takes 30 seconds to install dependencies every time you spin up a fresh environment, that adds up. Bun cuts that dramatically.

The C# AppHost equivalents are documented at aspire.dev if you prefer authoring in C# — all the same patterns apply.

Yarn Got More Reliable

Bun gets the spotlight, but Yarn users get something arguably more impactful: fewer mysterious failures. Aspire 13.2 improves reliability for withYarn() with addViteApp().

These kinds of fixes don’t sound exciting until you’ve spent 20 minutes debugging why your Yarn-backed frontend resource wouldn’t start. Consider it fixed.

Container Publishing You Can Actually Reason About

Two container improvements worth knowing:

Explicit Pull Policy

Docker Compose publishing now supports PullPolicy, including a Never option:

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

const builder = await createBuilder();
await builder.addDockerComposeEnvironment("compose");

const worker = await builder.addContainer("worker", "myorg/worker:latest")
 .withImagePullPolicy(ImagePullPolicy.Never);

await builder.build().run();

This is the “please use the image I already built and leave the registry out of it” workflow. Super useful when iterating locally on images you’re building and publishing manually, or when your CI produces an image and you want Compose to use exactly that one without sneaking in a remote pull.

PostgreSQL 18+ Volumes Work Again

PostgreSQL 18 changed its internal data directory layout. This broke volume mapping in Aspire silently — your data volume would be set up but persistence wouldn’t actually work correctly. 13.2 fixes this.

const postgres = await builder.addPostgres("postgres")
 .withDataVolume({ isReadOnly: false });

If you’re running PostgreSQL 18 or later with a data volume, upgrade to Aspire 13.2 and don’t think about it again.

Debugging Quality-of-Life Improvements

A few things that make stepping through an AppHost session less frustrating:

DebuggerDisplayAttribute on core types — DistributedApplication, resources, endpoint expressions now show useful values in the debugger instead of requiring you to drill into object trees
Better WaitFor failure messages — when resources fail to start, the error context is actually helpful now
BeforeResourceStartedEvent fires at the right time — only when a resource is actually starting, not on unrelated state transitions
launchSettings.json is more resilient — less chance of a malformed setting corrupting your dev startup

None of these are individually earth-shattering, but collectively they remove friction from the debugging experience. If you’ve ever had to drill three levels deep into an Aspire resource object to figure out what endpoint it was using, the debugger display improvement alone is worth the update.

Wrapping up

Aspire 13.2 is a focused quality release. Bun support is the headline, but the container and debugging improvements are what will make your day-to-day work smoother. Worth updating — especially if you’re on PostgreSQL 18 with data volumes.

Full details in the original post by David Pine and the Aspire 13.2 what’s new docs.

Where Should You Host Your AI Agents on Azure? A Practical Decision Guide

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

If you’re building AI agents with .NET right now, you’ve probably noticed something: there are a lot of ways to host them on Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — and they all sound reasonable until you actually need to pick one. Microsoft just published a comprehensive guide to Azure AI agent hosting that clears this up, and I want to break it down from a practical .NET developer perspective.

The six options at a glance

Here’s how I’d summarize the landscape:

Option	Best for	You manage
Container Apps	Full container control without K8s complexity	Observability, state, lifecycle
AKS	Enterprise compliance, multi-cluster, custom networking	Everything (that’s the point)
Azure Functions	Event-driven, short-running agent tasks	Not much — true serverless
App Service	Simple HTTP agents, predictable traffic	Deployment, scaling config
Foundry Agents	Code-optional agents via portal/SDK	Almost nothing
Foundry Hosted Agents	Custom framework agents with managed infra	Your agent code only

The first four are general-purpose compute — you can run agents on them, but they weren’t designed for it. The last two are agent-native: they understand conversations, tool calls, and agent lifecycles as first-class concepts.

Foundry Hosted Agents — the sweet spot for .NET agent developers

Here’s what caught my attention. Foundry Hosted Agents sit right in the middle: you get the flexibility of running your own code (Semantic Kernel, Agent Framework, LangGraph — whatever) but the platform handles infrastructure, observability, and conversation management.

The key piece is the Hosting Adapter — a thin abstraction layer that bridges your agent framework to the Foundry platform. For Microsoft Agent Framework, it looks like this:

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()

That’s your entire hosting story. The adapter handles protocol translation, streaming via server-sent events, conversation history, and OpenTelemetry tracing — all automatically. No custom middleware, no manual plumbing.

Deploying is genuinely simple

I’ve deployed agents to Container Apps before and it works, but you end up writing a lot of glue code for state management and observability. With Hosted Agents and azd, the deployment is:

# Install the AI agent extension
azd ext install azure.ai.agents

# Init from a template
azd ai agent init

# Build, push, deploy — done
azd up

That single azd up builds your container, pushes it to ACR, provisions the Foundry project, deploys model endpoints, and starts your agent. Five steps collapsed into one command.

Built-in conversation management

This is the part that saves the most time in production. Instead of building your own conversation state store, Hosted Agents handle it natively:

# Create a persistent conversation
conversation = openai_client.conversations.create()

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

# Second turn — context is preserved
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

No Redis. No Cosmos DB session store. No custom middleware for message serialization. The platform just handles it.

My decision framework

After going through all six options, here’s my quick mental model:

Do you need zero infrastructure? → Foundry Agents (portal/SDK, no containers)
Do you have custom agent code but want managed hosting? → Foundry Hosted Agents
Do you need event-driven, short-lived agent tasks? → Azure Functions
Do you need maximum container control without K8s? → Container Apps
Do you need strict compliance and multi-cluster? → AKS
Do you have a simple HTTP agent with predictable traffic? → App Service

For most .NET developers building with Semantic Kernel or Microsoft Agent Framework, Hosted Agents is likely the right starting point. You get scale-to-zero, built-in OpenTelemetry, conversation management, and framework flexibility — without managing Kubernetes or wiring up your own observability stack.

Wrapping up

The agent hosting landscape on Azure is maturing fast. If you’re starting a new AI agent project today, I’d seriously consider Foundry Hosted Agents before reaching for Container Apps or AKS out of habit. The managed infrastructure saves real time, and the hosting adapter pattern lets you keep your framework choice.

Check out the full guide from Microsoft and the Foundry Samples repo for working examples.

azd Now Lets You Run and Debug AI Agents Locally — Here's What Changed in March 2026

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

Seven releases in one month. That’s what the Azure Developer CLI (azd) team pushed in March 2026, and the headline feature is the one I’ve been waiting for: a local run-and-debug loop for AI agents.

PC Chan published the full roundup, and while there’s a lot in there, let me filter it down to what actually matters for .NET developers building AI-powered apps.

Run and debug AI agents without deploying

This is the big one. The new azure.ai.agents extension adds a set of commands that give you a proper inner-loop experience for AI agents:

azd ai agent run — starts your agent locally
azd ai agent invoke — sends messages to it (local or deployed)
azd ai agent show — displays container status and health
azd ai agent monitor — streams container logs in real time

Before this, testing an AI agent meant deploying to Microsoft Foundry every time you made a change. Now you can iterate locally, test your agent’s behavior, and only deploy when you’re ready. If you’ve been building agents with the Microsoft Agent Framework or Semantic Kernel, this changes your daily workflow.

The invoke command works against both local and deployed agents, which means you can use the same testing workflow regardless of where the agent is running. That’s the kind of detail that saves you from maintaining two sets of test scripts.

GitHub Copilot scaffolds your azd project

azd init now offers a “Set up with GitHub Copilot (Preview)” option. Instead of manually answering prompts about your project structure, a Copilot agent scaffolds the configuration for you. It checks for a dirty working directory before modifying anything and asks for MCP server tool consent upfront.

When a command fails, azd now offers AI-assisted troubleshooting: pick a category (explain, guidance, troubleshoot, or skip), let the agent suggest a fix, and retry — all without leaving the terminal. For complex infrastructure setups, that’s a real time saver.

Container App Jobs and deployment improvements

A few deployment features worth noting:

Container App Jobs: azd now deploys Microsoft.App/jobs through the existing host: containerapp config. Your Bicep template determines whether the target is a Container App or a Job — no extra setup.
Configurable deployment timeouts: New --timeout flag on azd deploy and a deployTimeout field in azure.yaml. No more guessing the default 1200-second limit.
Remote build fallback: When remote ACR build fails, azd falls back to local Docker/Podman build automatically.
Local preflight validation: Bicep parameters get validated locally before deploying, catching missing params without a round-trip to Azure.

Developer experience polish

Some smaller improvements that add up:

Automatic pnpm/yarn detection for JS/TS projects
pyproject.toml support for Python packaging
Local template directories — azd init --template now accepts filesystem paths for offline iteration
Better error messages in --no-prompt mode — all missing values reported at once with resolution commands
Build environment variables injected into all framework build subprocesses (.NET, Node.js, Java, Python)

That last one is subtle but important: your .NET build now has access to azd environment variables, which means you can do build-time configuration injection without extra scripting.

Wrapping up

The local AI agent debugging loop is the star of this release, but the accumulation of deployment improvements and DX polish makes azd feel more mature than ever. If you’re deploying .NET apps to Azure — especially AI agents — this update is worth the install.

Check the full release notes for every detail, or get started with azd install.

Containers | The .NET Blog

.NET 10 Ships with Ubuntu 26.04 LTS — Here's What's New

Install .NET 10 in two commands

Try it immediately

Containers: update -noble to -resolute

Native AOT: 3ms startup, 1.4MB binary

What changed in Ubuntu 26.04 that affects .NET

Need .NET 8 or 9?

Wrapping up

Aspire 13.2 Gets Bun, Better Containers, and Less Debugging Friction

Bun is Now a First-Class Citizen

Yarn Got More Reliable

Container Publishing You Can Actually Reason About

Explicit Pull Policy

PostgreSQL 18+ Volumes Work Again

Debugging Quality-of-Life Improvements

Wrapping up

Where Should You Host Your AI Agents on Azure? A Practical Decision Guide

The six options at a glance

Foundry Hosted Agents — the sweet spot for .NET agent developers

Deploying is genuinely simple

Built-in conversation management

My decision framework

Wrapping up

azd Now Lets You Run and Debug AI Agents Locally — Here's What Changed in March 2026

Run and debug AI agents without deploying

GitHub Copilot scaffolds your azd project

Container App Jobs and deployment improvements

Developer experience polish

Wrapping up

Containers: update `-noble` to `-resolute`