Containers | The .NET Blog

.NET 10 wird mit Ubuntu 26.04 LTS ausgeliefert — Was Neu Ist

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

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Es ist Ubuntu-LTS-Tag. Ubuntu 26.04 (Resolute Raccoon) ist heute erschienen und liefert wie jede Ubuntu-LTS die neueste .NET-LTS aus — in diesem Fall .NET 10.

LTS auf LTS — fünf Jahre Support für das OS, passend zum eigenen Langzeit-Support-Fenster von .NET 10.

.NET 10 in zwei Befehlen installieren

sudo apt update
sudo apt install dotnet-sdk-10.0

.NET ist einer der offiziell unterstützten Toolchains auf Ubuntu — kein Drittanbieter-Add-on.

Container: `-noble` zu `-resolute` aktualisieren

Die Migration ist einzeilig:

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

Alle bestehenden Image-Varianten — einschließlich Chiseled — sind verfügbar.

Native AOT: 3ms Start, 1,4MB Binary

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# artifacts/app/app — 1,4MB natives Binary
# real 0m0.003s

Für cloud-native Workloads, bei denen Kaltstart-Zeit wichtig ist — Functions, Container, Serverless — ein echter Gamechanger.

Benötigst du .NET 8 oder 9?

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

Der vollständige Beitrag enthält weitere Details zu cgroup v2, Post-Quanten-Kryptografie und Linux 7.0.

Aspire 13.2: Bun-Support, bessere Container und weniger Debug-Reibung

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

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Wenn du .NET-Backends mit JavaScript-Frontends in Aspire baust, ist 13.2 das Update, das deinen Alltag leise besser macht. Keine neuen Paradigmen. Nur solide Verbesserungen an Dingen, die leicht nervig waren.

Bun ist jetzt erstklassig

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

Wenn dein Team Bun bereits verwendet, zwingt Aspire dich nicht mehr gegen den Strom zu schwimmen.

Yarn wurde zuverlässiger

Yarn-Nutzer bekommen etwas mindestens genauso Wichtiges: weniger mysteriöse Fehler bei withYarn() mit addViteApp().

Container-Verbesserungen

Explizite Pull Policy

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

Perfekt für Workflows, wo du lokal Images baust und Compose genau dieses verwenden soll.

PostgreSQL 18+ funktioniert korrekt

PostgreSQL 18 änderte sein internes Verzeichnislayout, was das Volume-Mapping still brach. 13.2 behebt das.

Debugging-Verbesserungen

DebuggerDisplayAttribute auf Core-Typen — nützliche Werte statt tiefer Objektbäume
Bessere Fehlermeldungen für WaitFor
BeforeResourceStartedEvent feuert zum richtigen Zeitpunkt

Fazit

Aspire 13.2 ist ein fokussiertes Qualitäts-Release. Originalpost von David Pine: Aspire 13.2: Bun Support and Container Enhancements.

Wo solltest du deine KI-Agenten auf Azure hosten? Ein praktischer Entscheidungsleitfaden

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wenn du gerade KI-Agenten mit .NET baust, hast du wahrscheinlich etwas bemerkt: Es gibt viele Möglichkeiten, sie auf Azure zu hosten. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — und alle klingen vernünftig, bis du tatsächlich einen auswählen musst. Microsoft hat gerade einen umfassenden Leitfaden zum Azure KI-Agenten-Hosting veröffentlicht, der das klärt, und ich möchte ihn aus der praktischen Perspektive eines .NET-Entwicklers aufschlüsseln.

Die sechs Optionen auf einen Blick

So würde ich die Landschaft zusammenfassen:

Option	Am besten für	Du verwaltest
Container Apps	Volle Container-Kontrolle ohne K8s-Komplexität	Observability, State, Lifecycle
AKS	Enterprise-Compliance, Multi-Cluster, Custom Networking	Alles (das ist der Punkt)
Azure Functions	Event-getriebene, kurzlebige Agenten-Tasks	Kaum etwas — echtes Serverless
App Service	Einfache HTTP-Agenten, vorhersehbarer Traffic	Deployment, Scaling-Config
Foundry Agents	Code-optionale Agenten über Portal/SDK	Fast nichts
Foundry Hosted Agents	Custom-Framework-Agenten mit verwalteter Infra	Nur dein Agenten-Code

Die ersten vier sind General-Purpose Compute — du kannst Agenten darauf ausführen, aber sie wurden nicht dafür entwickelt. Die letzten zwei sind agenten-nativ: Sie verstehen Konversationen, Tool-Aufrufe und Agenten-Lifecycles als First-Class-Konzepte.

Foundry Hosted Agents — der Sweet Spot für .NET-Agenten-Entwickler

Das hat meine Aufmerksamkeit geweckt. Foundry Hosted Agents sitzen genau in der Mitte: Du bekommst die Flexibilität, deinen eigenen Code auszuführen (Semantic Kernel, Agent Framework, LangGraph — was auch immer), aber die Plattform kümmert sich um Infrastruktur, Observability und Konversationsmanagement.

Das Schlüsselstück ist der Hosting Adapter — eine dünne Abstraktionsschicht, die dein Agenten-Framework mit der Foundry-Plattform verbindet. Für Microsoft Agent Framework sieht das so aus:

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

Das ist deine gesamte Hosting-Geschichte. Der Adapter übernimmt Protokollübersetzung, Streaming über Server-Sent Events, Konversationsverlauf und OpenTelemetry-Tracing — alles automatisch. Keine Custom Middleware, kein manuelles Plumbing.

Deployment ist wirklich einfach

Ich habe vorher Agenten auf Container Apps deployed und es funktioniert, aber man schreibt am Ende viel Glue-Code für State Management und Observability. Mit Hosted Agents und azd sieht das Deployment so aus:

# KI-Agenten-Extension installieren
azd ext install azure.ai.agents

# Von einer Vorlage initialisieren
azd ai agent init

# Bauen, pushen, deployen — fertig
azd up

Dieses einzelne azd up baut deinen Container, pusht ihn zu ACR, provisioniert das Foundry-Projekt, deployed Model-Endpoints und startet deinen Agenten. Fünf Schritte in einem Befehl zusammengefasst.

Integriertes Konversationsmanagement

Das ist der Teil, der in der Produktion am meisten Zeit spart. Anstatt deinen eigenen Konversations-State-Store zu bauen, handhaben Hosted Agents das nativ:

# Eine persistente Konversation erstellen
conversation = openai_client.conversations.create()

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

# Zweite Runde — Kontext bleibt erhalten
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Kein Redis. Kein Cosmos DB Session Store. Keine Custom Middleware für Nachrichtenserialisierung. Die Plattform kümmert sich einfach darum.

Mein Entscheidungsframework

Nachdem ich alle sechs Optionen durchgegangen bin, hier mein schnelles mentales Modell:

Brauchst du null Infrastruktur? → Foundry Agents (Portal/SDK, keine Container)
Hast du Custom-Agenten-Code, willst aber verwaltetes Hosting? → Foundry Hosted Agents
Brauchst du event-getriebene, kurzlebige Agenten-Tasks? → Azure Functions
Brauchst du maximale Container-Kontrolle ohne K8s? → Container Apps
Brauchst du strikte Compliance und Multi-Cluster? → AKS
Hast du einen einfachen HTTP-Agenten mit vorhersehbarem Traffic? → App Service

Für die meisten .NET-Entwickler, die mit Semantic Kernel oder Microsoft Agent Framework bauen, sind Hosted Agents wahrscheinlich der richtige Startpunkt. Du bekommst Scale-to-Zero, integriertes OpenTelemetry, Konversationsmanagement und Framework-Flexibilität — ohne Kubernetes zu verwalten oder deinen eigenen Observability-Stack aufzubauen.

Zum Abschluss

Die Agenten-Hosting-Landschaft auf Azure reift schnell. Wenn du heute ein neues KI-Agenten-Projekt startest, würde ich Foundry Hosted Agents ernsthaft in Betracht ziehen, bevor du aus Gewohnheit zu Container Apps oder AKS greifst. Die verwaltete Infrastruktur spart echte Zeit, und das Hosting-Adapter-Pattern lässt dich deine Framework-Wahl behalten.

Schau dir den vollständigen Leitfaden von Microsoft und das Foundry Samples Repo für funktionierende Beispiele an.

azd ermöglicht jetzt lokales Ausführen und Debuggen von KI-Agenten — Das hat sich im März 2026 geändert

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Sieben Releases in einem Monat. Das hat das Azure Developer CLI (azd)-Team im März 2026 veröffentlicht, und das Hauptfeature ist genau das, worauf ich gewartet habe: ein lokaler Run-and-Debug-Loop für KI-Agenten.

PC Chan hat die vollständige Zusammenfassung veröffentlicht, und obwohl es viel gibt, lass mich das auf das filtern, was für .NET-Entwickler, die KI-gestützte Apps bauen, wirklich wichtig ist.

KI-Agenten ausführen und debuggen ohne Deployment

Das ist das große Ding. Die neue azure.ai.agents-Extension fügt Befehle hinzu, die dir eine ordentliche Inner-Loop-Erfahrung für KI-Agenten geben:

azd ai agent run — startet deinen Agenten lokal
azd ai agent invoke — sendet Nachrichten (lokal oder deployed)
azd ai agent show — zeigt Container-Status und Health
azd ai agent monitor — streamt Container-Logs in Echtzeit

Vorher bedeutete das Testen eines KI-Agenten jedes Mal ein Deployment zu Microsoft Foundry. Jetzt kannst du lokal iterieren, das Verhalten testen und erst deployen, wenn du bereit bist. Wenn du Agenten mit dem Microsoft Agent Framework oder Semantic Kernel baust, ändert das deinen täglichen Workflow.

Der invoke-Befehl funktioniert sowohl gegen lokale als auch deployed Agenten, was bedeutet, dass du den gleichen Test-Workflow verwenden kannst, egal wo der Agent läuft.

GitHub Copilot richtet dein azd-Projekt ein

azd init bietet jetzt eine “Set up with GitHub Copilot (Preview)"-Option. Statt manuell Prompts über deine Projektstruktur zu beantworten, scaffoldet ein Copilot-Agent die Konfiguration für dich. Wenn ein Befehl fehlschlägt, bietet azd jetzt KI-gestützte Fehlerbehebung: Kategorie wählen, den Agenten einen Fix vorschlagen lassen und wiederholen — alles ohne das Terminal zu verlassen.

Container App Jobs und Deployment-Verbesserungen

Container App Jobs: azd deployed jetzt Microsoft.App/jobs über die bestehende host: containerapp-Konfiguration.
Konfigurierbare Deployment-Timeouts: Neues --timeout-Flag und deployTimeout-Feld in azure.yaml.
Remote-Build-Fallback: Bei fehlgeschlagenem ACR-Build fällt azd automatisch auf lokalen Docker/Podman-Build zurück.
Lokale Preflight-Validierung: Bicep-Parameter werden lokal validiert, bevor deployed wird.

DX-Verbesserungen

Automatische pnpm/yarn-Erkennung für JS/TS-Projekte
pyproject.toml-Unterstützung für Python
Lokale Template-Verzeichnisse — azd init --template akzeptiert jetzt Dateisystem-Pfade
Bessere Fehlermeldungen im --no-prompt-Modus
Build-Umgebungsvariablen in alle Framework-Build-Subprozesse injiziert (.NET, Node.js, Java, Python)

Zusammenfassung

Der lokale KI-Agenten-Debug-Loop ist der Star dieses Releases, aber die Gesamtheit an Deployment-Verbesserungen und DX-Polish macht azd reifer als je zuvor. Wenn du .NET-Apps auf Azure deployst — besonders KI-Agenten — lohnt sich dieses Update.

Schau dir die vollständigen Release Notes für alle Details an.