AI Foundry | The .NET Blog

Azure SDK April 2026: AI Foundry 2.0 and What .NET Developers Should Know

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

Monthly SDK releases are often easy to skip. This one has a few things worth paying attention to — especially if you’re building with AI Foundry, Cosmos DB in Java, or doing infrastructure provisioning from .NET code.

Azure.AI.Projects 2.0.0 — Breaking Changes That Make Sense

The Azure.AI.Projects NuGet package reaches stable 2.0.0 with some significant architectural changes. If you’re already using the preview, here’s what changed:

Namespace splits: Evaluations moved to Azure.AI.Projects.Evaluation, memory operations moved to Azure.AI.Projects.Memory. Your using statements will need updating.
Renamed types: Insights → ProjectInsights, Schedules → ProjectSchedules, Evaluators → ProjectEvaluators, Trigger → ScheduleTrigger
Naming conventions: Boolean properties now follow the Is* convention consistently

These are the kinds of breaking changes that hurt once and then feel right forever. If you’ve been building on the preview, update your imports and let the compiler point you to the rest.

The good news: it’s stable. You can actually rely on this API now.

Cosmos DB Java: Critical Security Fix (RCE)

This one is serious. The Java Cosmos DB library (azure-cosmos) version 4.79.0 includes a critical security fix for a Remote Code Execution vulnerability (CWE-502).

The issue was Java deserialization in CosmosClientMetadataCachesSnapshot, AsyncCache, and DocumentCollection. The fix replaces Java deserialization with JSON-based serialization, eliminating the entire class of deserialization attacks.

If you have any Java services using Azure Cosmos DB, update to 4.79.0 immediately. This isn’t optional.

New Provisioning Libraries for .NET

A wave of stable Provisioning libraries hit 1.0.0 this month — these are the libraries that let you define Azure infrastructure in C# code rather than ARM templates or Bicep:

Several more are in beta.1, covering API Management, Batch, Compute, Monitor, MySQL, and Security Center. If you’re doing infrastructure-as-code from .NET — particularly with Aspire deployments — these libraries are your entry point.

Azure AI Agents Java: 2.0.0 GA

The Java Azure AI Agents library also reaches general availability this month. The key breaking changes:

Several enum types converted to ExpandableStringEnum-based classes (more flexible for new values)
*Param model classes renamed to *Parameter
MCPToolConnectorId → McpToolConnectorId (consistent casing)
New convenience overload for beginUpdateMemories

Wrapping up

The headline for .NET developers this month is Azure.AI.Projects 2.0.0 hitting stable — if you’re building with AI Foundry, now’s the time to pin to stable and update your imports. For Java shops using Cosmos DB, the security update is urgent.

Full release notes at aka.ms/azsdk/releases. Original post: Azure SDK Release (April 2026).

68 Minutes a Day Re-Explaining Code to Copilot? There's a Fix for That

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

You know that moment when your Copilot session hits /compact and the agent completely forgets what you were doing? You spend the next five minutes re-explaining the file structure, the failing test, the three approaches you already tried. Then it happens again. And again.

Desi Villanueva timed it: 68 minutes per day — just on re-orientation. Not writing code. Not reviewing PRs. Just catching the AI up on things it already knew.

Turns out there’s a concrete reason this happens, and a concrete fix.

The Context Window Lie

Your agent ships with a big number on the box. 200K tokens. Sounds massive. In practice it’s a ceiling, not a guarantee.

Here’s the actual math:

200K total context
Minus ~65K for MCP tools loaded at startup (~33%)
Minus ~10K for instruction files like AGENTS.md or copilot-instructions.md

That leaves you with roughly 125K before you type a word. And it gets worse — LLMs don’t degrade gracefully as context fills up. They hit a wall at around 60% capacity. The model starts losing things mentioned 30 turns ago, contradicts earlier responses, hallucinates file names it stated confidently 10 minutes prior. The industry calls this the “lost in the middle” problem.

Effective limit: 45K tokens before quality degrades. That’s maybe 20-30 turns of active conversation before the agent starts drifting. Which is why you’re hitting /compact every 45 minutes — not because you’ve filled 200K tokens, but because the model is already rotting at 120K.

The Compaction Tax

Every /compact costs you flow state. You’re deep in a debugging session. Shared context built up over 30 minutes. The agent knows the file structure, the failing test, the hypothesis. Then the warning hits.

Ignore it → agent gets progressively dumber, hallucinates old state
Run /compact → agent has a 2-paragraph summary of a 30-minute investigation

Either way you lose. Either way you’re narrating your own project back to it like a new hire on day one.

The cruel part? The memory already exists. Copilot CLI writes every session to a local SQLite database at ~/.copilot/session-store.db — every file touched, every turn, every checkpoint. It’s all sitting on disk. The agent just can’t read it.

auto-memory: A Recall Layer, Not a Memory System

That’s the key insight behind auto-memory: don’t build a new memory system — build a read-only query layer over the one that already exists.

pip install auto-memory

~1,900 lines of Python. Zero dependencies. Installs in 30 seconds.

Instead of flooding the context with grep results, you give the agent surgical access to what actually matters:

Operation	Tokens	What you get
`grep -r "auth" src/`	~5,000–10,000	500 results, most irrelevant
`find . -name "*.py"`	~2,000	Every Python file, no context
Agent re-orientation	~2,000	You explaining what it should know
`auto-memory files --json --limit 10`	~50	The 10 files you touched yesterday

That’s a 200x improvement. The agent skips the archaeological dig and goes straight to what matters.

The recommended flow: when you’re approaching 50-70% context usage, run /clear and then prompt with “review last sessions we discussed topic X”. Instead of burning 12K tokens on blind searches, auto-memory pulls the relevant context in 50.

Why This Matters for .NET Developers

If you’re using GitHub Copilot CLI for .NET work — scaffolding services, debugging EF Core queries, iterating on Blazor components — the context rot problem hits just as hard. Complex solutions with multiple projects, shared libraries, and deep call chains are exactly the kind of codebase where the agent loses track fastest.

The install guide walks through pointing Copilot CLI at it. It’s a one-time setup.

Honestly? 68 minutes a day back in your pocket is not a minor quality-of-life tweak. That’s almost 6 hours a week.

Wrapping up

Context rot is a real architectural constraint, not a bug that will get patched. auto-memory works around it by giving your agent a cheap, precise recall mechanism instead of expensive, noisy re-exploration. If you’re doing serious AI-assisted development with GitHub Copilot CLI, it’s worth the 30-second install.

Check it out: auto-memory on GitHub. Original post by Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.