{"authors":[{"name":"Martin Stühmer","url":"https://daily-devops.net/authors/martin/"},{"name":"Jendrik Brack","url":"https://daily-devops.net/authors/jendrik/"}],"description":"Recent content in .NET Aspire and Distributed Apps on Daily DevOps \u0026 .NET","favicon":"https://daily-devops.net/images/logo_hu_6465d873dfa490cf.png","feed_url":"https://daily-devops.net/tags/aspire/feed.json","home_page_url":"https://daily-devops.net/tags/aspire/","icon":"https://daily-devops.net/images/logo_hu_5926de77762241ba.png","items":[{"authors":[{"name":"Martin Stühmer","url":"https://daily-devops.net/authors/martin/"}],"content_html":"\u003cp\u003eLet\u0026rsquo;s be honest about 2025: no runtime breakthroughs, no language revolutions. Nothing that\u0026rsquo;ll make the keynote highlight reels. What we got instead was something the ecosystem desperately needed—tooling that finally stopped lying about complexity.\u003c/p\u003e\n\u003cp\u003eThe wins came from admitting reality. Distributed systems aren\u0026rsquo;t simple, and tools that pretend otherwise just create delayed failures. Async execution semantics matter, whether your abstraction acknowledges them or not. Infrastructure dependencies aren\u0026rsquo;t implementation details you can mock away without consequences. In 2025, the tools that delivered value made all of this explicit, testable, impossible to ignore.\u003c/p\u003e\n\u003cp\u003eBut alongside that technical progress, we also saw the cracks widen. Open source sustainability, corporate consumption patterns, ecosystem trust—these structural tensions didn\u0026rsquo;t get resolved. If anything, they became harder to ignore. And they\u0026rsquo;re shaping our tooling choices just as much as any technical consideration.\u003c/p\u003e\n\u003cp\u003eHere\u0026rsquo;s what actually mattered this year.\u003c/p\u003e\n\n\n\n\n\u003ch2 id=\"making-complexity-visible-not-optional\"\u003e\u003ca href=\"/posts/dotnet-2025-year-in-review/#making-complexity-visible-not-optional\" title=\"Making Complexity Visible, Not Optional\"\u003eMaking Complexity Visible, Not Optional\u003c/a\u003e\u003c/h2\u003e\n\u003cp\u003eThe pattern I kept seeing in 2025: tools that actually mattered forced you to deal with reality instead of pretending it away. Topology. Concurrency. Dependency lifecycles. Infrastructure behavior. The messy stuff we\u0026rsquo;ve been hiding behind \u0026ldquo;convenience\u0026rdquo; layers for years, just postponing production incidents.\u003c/p\u003e\n\u003cp\u003eAspire, TUnit, Testcontainers. Three different problems. One consistent theme: show me what\u0026rsquo;s actually happening.\u003c/p\u003e\n\u003cp\u003e.NET Aspire: Beyond the Azure Narrative\u003c/p\u003e\n\u003cp\u003eMost people look at Aspire and see Azure tooling. That\u0026rsquo;s reading it wrong. It\u0026rsquo;s worth correcting because it misses what actually changed in 2025.\u003c/p\u003e\n\u003cp\u003eI watched teams use Aspire in ways that had nothing to do with Azure. Polyglot systems where only the orchestration layer was .NET. Existing containerized services that got wired in without rewrites. Self-hosted infrastructure, alternative cloud providers, Docker on a developer\u0026rsquo;s laptop. Hybrid setups where Aspire was just the coordination layer, not the runtime.\u003c/p\u003e\n\u003cp\u003eWhat makes this work is that Aspire isn\u0026rsquo;t really about deployment targets. It\u0026rsquo;s about making system intent explicit.\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-csharp\" data-lang=\"csharp\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"kt\"\u003evar\u003c/span\u003e \u003cspan class=\"n\"\u003ebuilder\u003c/span\u003e \u003cspan class=\"p\"\u003e=\u003c/span\u003e \u003cspan class=\"n\"\u003eDistributedApplication\u003c/span\u003e\u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eCreateBuilder\u003c/span\u003e\u003cspan class=\"p\"\u003e(\u003c/span\u003e\u003cspan class=\"n\"\u003eargs\u003c/span\u003e\u003cspan class=\"p\"\u003e);\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"kt\"\u003evar\u003c/span\u003e \u003cspan class=\"n\"\u003epostgres\u003c/span\u003e \u003cspan class=\"p\"\u003e=\u003c/span\u003e \u003cspan class=\"n\"\u003ebuilder\u003c/span\u003e\u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eAddPostgres\u003c/span\u003e\u003cspan class=\"p\"\u003e(\u003c/span\u003e\u003cspan class=\"s\"\u003e\u0026#34;db\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e);\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"kt\"\u003evar\u003c/span\u003e \u003cspan class=\"n\"\u003eapi\u003c/span\u003e \u003cspan class=\"p\"\u003e=\u003c/span\u003e \u003cspan class=\"n\"\u003ebuilder\u003c/span\u003e\u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eAddProject\u003c/span\u003e\u003cspan class=\"p\"\u003e\u0026lt;\u003c/span\u003e\u003cspan class=\"n\"\u003eProjects\u003c/span\u003e\u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eApi\u003c/span\u003e\u003cspan class=\"p\"\u003e\u0026gt;(\u003c/span\u003e\u003cspan class=\"s\"\u003e\u0026#34;api\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e)\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e                 \u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eWithReference\u003c/span\u003e\u003cspan class=\"p\"\u003e(\u003c/span\u003e\u003cspan class=\"n\"\u003epostgres\u003c/span\u003e\u003cspan class=\"p\"\u003e);\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"n\"\u003ebuilder\u003c/span\u003e\u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eBuild\u003c/span\u003e\u003cspan class=\"p\"\u003e().\u003c/span\u003e\u003cspan class=\"n\"\u003eRun\u003c/span\u003e\u003cspan class=\"p\"\u003e();\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eLook at this code. Dependencies aren\u0026rsquo;t buried in appsettings files or injected through environment variables scattered across deployment scripts. They\u0026rsquo;re right there, versioned with your application code, reviewable in pull requests, enforced at composition time.\u003c/p\u003e\n\u003cp\u003eThe app model is your system topology as code. Aspire then \u0026ldquo;lowers\u0026rdquo; that high-level description into whatever you actually need—Kubernetes manifests, Bicep templates, Docker Compose files, whatever your target environment requires.\u003c/p\u003e\n\u003cp\u003eBut the thing that actually shifted conversations: observability gets baked in. With Aspire, OpenTelemetry isn\u0026rsquo;t a post-deployment retrofit. \u003ccode\u003eOTEL_SERVICE_NAME\u003c/code\u003e and \u003ccode\u003eOTEL_EXPORTER_OTLP_ENDPOINT\u003c/code\u003e are automatic. The dashboard shows you traces, logs, metrics during local dev—without the boilerplate.\u003c/p\u003e\n\u003cp\u003eWhen observability is structural instead of bolted-on, the entire conversation changes.\u003c/p\u003e\n\u003cp\u003eThat alignment—between how you describe your system, how it gets deployed, and how you observe it—is where Aspire delivered real value in 2025.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResources\u003c/strong\u003e: \u003ca href=\"https://github.com/dotnet/aspire\" target=\"_blank\" rel=\"noopener external noreferrer\"\u003eGitHub\u003c/a\u003e | \u003ca href=\"https://learn.microsoft.com/en-us/dotnet/aspire/\" target=\"_blank\" rel=\"noopener external noreferrer\"\u003eDocs\u003c/a\u003e\u003c/p\u003e\n\n\n\n\n\u003ch2 id=\"tunit-when-test-frameworks-hide-what-matters\"\u003e\u003ca href=\"/posts/dotnet-2025-year-in-review/#tunit-when-test-frameworks-hide-what-matters\" title=\"TUnit: When Test Frameworks Hide What Matters\"\u003eTUnit: When Test Frameworks Hide What Matters\u003c/a\u003e\u003c/h2\u003e\n\u003cp\u003eTUnit looks like cleaner syntax. It\u0026rsquo;s not. The actual value is in execution semantics that most frameworks just ignore because they don\u0026rsquo;t care about precision.\u003c/p\u003e\n\u003cp\u003eReal test suites fail constantly for reasons that have nothing to do with your code. Shared state between parameterized tests. Async forced into sync silently. Parallel runs creating race conditions that only show up in CI. Test fixtures hiding execution boundaries you never designed for. The list goes on.\u003c/p\u003e\n\u003cp\u003eMost frameworks allow tests with these problems. TUnit makes them hard to accidentally create.\u003c/p\u003e\n\u003cp\u003eTake a realistic scenario—testing behavior that depends on multiple runtime dimensions like feature flags and tenant configuration:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-csharp\" data-lang=\"csharp\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"kd\"\u003esealed\u003c/span\u003e \u003cspan class=\"k\"\u003eclass\u003c/span\u003e \u003cspan class=\"nc\"\u003eFeatureFlagTests\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"na\"\u003e    [Test]\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e    \u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"kd\"\u003easync\u003c/span\u003e \u003cspan class=\"n\"\u003eTask\u003c/span\u003e \u003cspan class=\"n\"\u003eRequest_is_processed_correctly\u003c/span\u003e\u003cspan class=\"p\"\u003e(\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"na\"\u003e        [Values(true, false)]\u003c/span\u003e \u003cspan class=\"kt\"\u003ebool\u003c/span\u003e \u003cspan class=\"n\"\u003efeatureEnabled\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"na\"\u003e        [Values(\u0026#34;Free\u0026#34;, \u0026#34;Premium\u0026#34;)]\u003c/span\u003e \u003cspan class=\"kt\"\u003estring\u003c/span\u003e \u003cspan class=\"n\"\u003etenantType\u003c/span\u003e\u003cspan class=\"p\"\u003e)\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e    \u003cspan class=\"p\"\u003e{\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e        \u003cspan class=\"k\"\u003eawait\u003c/span\u003e \u003cspan class=\"k\"\u003eusing\u003c/span\u003e \u003cspan class=\"nn\"\u003evar\u003c/span\u003e \u003cspan class=\"n\"\u003esystem\u003c/span\u003e \u003cspan class=\"p\"\u003e=\u003c/span\u003e \u003cspan class=\"k\"\u003eawait\u003c/span\u003e \u003cspan class=\"n\"\u003eTestSystem\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e            \u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eCreateAsync\u003c/span\u003e\u003cspan class=\"p\"\u003e(\u003c/span\u003e\u003cspan class=\"n\"\u003efeatureEnabled\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e \u003cspan class=\"n\"\u003etenantType\u003c/span\u003e\u003cspan class=\"p\"\u003e);\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e        \u003cspan class=\"kt\"\u003evar\u003c/span\u003e \u003cspan class=\"n\"\u003eresponse\u003c/span\u003e \u003cspan class=\"p\"\u003e=\u003c/span\u003e \u003cspan class=\"k\"\u003eawait\u003c/span\u003e \u003cspan class=\"n\"\u003esystem\u003c/span\u003e\u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eExecuteRequestAsync\u003c/span\u003e\u003cspan class=\"p\"\u003e();\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e        \u003cspan class=\"k\"\u003eawait\u003c/span\u003e \u003cspan class=\"n\"\u003eAssert\u003c/span\u003e\u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eThat\u003c/span\u003e\u003cspan class=\"p\"\u003e(\u003c/span\u003e\u003cspan class=\"n\"\u003eresponse\u003c/span\u003e\u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eIsSuccessful\u003c/span\u003e\u003cspan class=\"p\"\u003e).\u003c/span\u003e\u003cspan class=\"n\"\u003eIsTrue\u003c/span\u003e\u003cspan class=\"p\"\u003e();\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e    \u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eIn TUnit, each parameter combination runs in complete isolation. The async lifecycle is native—no hidden \u003ccode\u003eTask.Run()\u003c/code\u003e or \u003ccode\u003e.Result\u003c/code\u003e calls. Fixtures are explicit. Parallel execution doesn\u0026rsquo;t introduce coupling you didn\u0026rsquo;t ask for.\u003c/p\u003e\n\u003cp\u003eWhat this eliminates is that whole category of tests that pass locally, fail in CI, pass again when you re-run them, and fail on Tuesdays. You know the ones. The flaky tests that eat hours of investigation time because the failure mode has nothing to do with the business logic you\u0026rsquo;re testing.\u003c/p\u003e\n\u003cp\u003eIn production CI pipelines, I saw this translate to predictable parallel execution times, reduced variance across agents, and—most importantly—test failures that actually correlated with system behavior rather than execution artifacts.\u003c/p\u003e\n\u003cp\u003eTUnit makes execution boundaries explicit. That\u0026rsquo;s the real contribution.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResources\u003c/strong\u003e: \u003ca href=\"https://github.com/thomhurst/TUnit\" target=\"_blank\" rel=\"noopener external noreferrer\"\u003eGitHub\u003c/a\u003e\u003c/p\u003e\n\n\n\n\n\u003ch2 id=\"testcontainers-when-mocks-stop-being-enough\"\u003e\u003ca href=\"/posts/dotnet-2025-year-in-review/#testcontainers-when-mocks-stop-being-enough\" title=\"Testcontainers: When Mocks Stop Being Enough\"\u003eTestcontainers: When Mocks Stop Being Enough\u003c/a\u003e\u003c/h2\u003e\n\u003cp\u003eBy 2025, I stopped treating Testcontainers as optional. If you\u0026rsquo;re testing assumptions instead of real infrastructure, you\u0026rsquo;re setting yourself up for surprises in production.\u003c/p\u003e\n\u003cp\u003eIn-memory substitutes lie. You can\u0026rsquo;t test transaction isolation with SQLite. You can\u0026rsquo;t test Kafka\u0026rsquo;s partition rebalancing without Kafka. Message delivery semantics, startup timing, schema migrations—the real database handles all this differently than a polite fake.\u003c/p\u003e\n\u003cp\u003eTestcontainers lets you test actual infrastructure behavior:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-csharp\" data-lang=\"csharp\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"kt\"\u003evar\u003c/span\u003e \u003cspan class=\"n\"\u003ekafka\u003c/span\u003e \u003cspan class=\"p\"\u003e=\u003c/span\u003e \u003cspan class=\"k\"\u003enew\u003c/span\u003e \u003cspan class=\"n\"\u003eKafkaBuilder\u003c/span\u003e\u003cspan class=\"p\"\u003e()\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e    \u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eWithCleanUp\u003c/span\u003e\u003cspan class=\"p\"\u003e(\u003c/span\u003e\u003cspan class=\"kc\"\u003etrue\u003c/span\u003e\u003cspan class=\"p\"\u003e)\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e    \u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eBuild\u003c/span\u003e\u003cspan class=\"p\"\u003e();\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"k\"\u003eawait\u003c/span\u003e \u003cspan class=\"n\"\u003ekafka\u003c/span\u003e\u003cspan class=\"p\"\u003e.\u003c/span\u003e\u003cspan class=\"n\"\u003eStartAsync\u003c/span\u003e\u003cspan class=\"p\"\u003e();\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eWhen these tests fail, they\u0026rsquo;re usually telling you about real production risks, not artifacts of your test harness.\u003c/p\u003e\n\u003cp\u003eConsider what this means for database testing. PostgreSQL handles concurrent transactions, deadlocks, constraint violations in ways that in-memory databases simply don\u0026rsquo;t. Kafka\u0026rsquo;s exactly-once semantics, partition assignment, consumer group rebalancing—you need the actual broker to test any of this meaningfully.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve watched too many teams ship code that works fine against mocks and breaks immediately in production. Connection pool exhaustion. Deadlocks under load. Message ordering violations during partition reassignment. Schema migrations that work on SQLite but fail on Postgres because of type handling differences.\u003c/p\u003e\n\u003cp\u003eThese aren\u0026rsquo;t edge cases. They\u0026rsquo;re the default in real systems.\u003c/p\u003e\n\u003cp\u003eTestcontainers spins up real containers in your CI pipeline. Tests run against actual systems. Then the containers get cleaned up. The feedback loop stays fast. The confidence isn\u0026rsquo;t false.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResources\u003c/strong\u003e: \u003ca href=\"https://github.com/testcontainers/testcontainers-dotnet\" target=\"_blank\" rel=\"noopener external noreferrer\"\u003eGitHub\u003c/a\u003e\u003c/p\u003e\n\n\n\n\n\u003ch2 id=\"the-structural-problems-were-not-solving\"\u003e\u003ca href=\"/posts/dotnet-2025-year-in-review/#the-structural-problems-were-not-solving\" title=\"The Structural Problems We\u0026rsquo;re Not Solving\"\u003eThe Structural Problems We\u0026rsquo;re Not Solving\u003c/a\u003e\u003c/h2\u003e\n\u003cp\u003eThe tooling highlights tell one story. But 2025 also made it harder to ignore structural problems that aren\u0026rsquo;t getting better.\u003c/p\u003e\n\n\n\n\n\u003ch3 id=\"licensing-as-operational-dependency\"\u003e\u003ca href=\"/posts/dotnet-2025-year-in-review/#licensing-as-operational-dependency\" title=\"Licensing as Operational Dependency\"\u003eLicensing as Operational Dependency\u003c/a\u003e\u003c/h3\u003e\n\u003cp\u003eCommercializing open source dependencies isn\u0026rsquo;t new. What became clearer in 2025 were the operational costs that don\u0026rsquo;t appear in pricing discussions.\u003c/p\u003e\n\u003cp\u003eCI pipelines started failing during container builds because license checks couldn\u0026rsquo;t reach licensing servers. Dependency upgrades got blocked not for technical reasons but because legal teams needed weeks to review new license terms. Build systems became coupled to licensing infrastructure in ways nobody had planned for. Features fragmented across paid and unpaid tiers, forcing architectural decisions based on licensing rather than technical fit.\u003c/p\u003e\n\u003cp\u003eFrom an RCDA perspective, this is a risk profile change. When your build breaks because a license server is down, you\u0026rsquo;ve introduced a runtime dependency that wasn\u0026rsquo;t part of the original technical evaluation. The feedback cycle slows. Operational complexity increases. And most teams don\u0026rsquo;t see this coming until they\u0026rsquo;re already committed to the dependency.\u003c/p\u003e\n\n\n\n\n\u003ch3 id=\"the-consumption-contribution-imbalance\"\u003e\u003ca href=\"/posts/dotnet-2025-year-in-review/#the-consumption-contribution-imbalance\" title=\"The Consumption-Contribution Imbalance\"\u003eThe Consumption-Contribution Imbalance\u003c/a\u003e\u003c/h3\u003e\n\u003cp\u003eLarge organizations continued extracting value from open source while contributing little back. Internal forks maintained indefinitely. Bug fixes applied internally but never pushed upstream. Copyright violations discovered through community audits, not voluntary disclosure.\u003c/p\u003e\n\u003cp\u003eIs this malicious? Usually not. It\u0026rsquo;s legal risk management, procurement friction, organizational complexity. But the outcome remains the same: ecosystem fragmentation and maintainer burnout, while enterprises save millions on software they couldn\u0026rsquo;t build themselves.\u003c/p\u003e\n\u003cp\u003eThis isn\u0026rsquo;t sustainable. When consumption at scale doesn\u0026rsquo;t come with proportional contribution—whether that\u0026rsquo;s code, funding, security disclosures, or just documentation improvements—the ecosystem becomes extractive. Maintainers burn out. Critical libraries go unmaintained. Trust erodes.\u003c/p\u003e\n\u003cp\u003e2025 made this tension more visible. We still don\u0026rsquo;t have good answers.\u003c/p\u003e\n\n\n\n\n\u003ch2 id=\"what-2025-actually-taught-us\"\u003e\u003ca href=\"/posts/dotnet-2025-year-in-review/#what-2025-actually-taught-us\" title=\"What 2025 Actually Taught Us\"\u003eWhat 2025 Actually Taught Us\u003c/a\u003e\u003c/h2\u003e\n\u003cp\u003e2025 was the year .NET tooling stopped hiding what\u0026rsquo;s actually hard. Aspire made system intent explicit. TUnit made execution boundaries explicit. Testcontainers made infrastructure behavior explicit.\u003c/p\u003e\n\u003cp\u003eThe open source sustainability crisis? Still unresolved. Still worsening. And still being treated as someone else\u0026rsquo;s problem by many organizations extracting the most value. These aren\u0026rsquo;t abstract concerns—they shape which tools survive, which maintainers continue, which dependencies remain viable long-term.\u003c/p\u003e\n\u003cp\u003eHere\u0026rsquo;s the lesson: technical maturity and ecosystem health aren\u0026rsquo;t separate. Ignore sustainability problems and you eventually constrain technical progress. Build on foundations maintained by exhausted volunteers subsidizing enterprise infrastructure, and you\u0026rsquo;re building on uncertain ground.\u003c/p\u003e\n\u003cp\u003eThe tools that mattered were honest. They didn\u0026rsquo;t promise to make distributed systems simple. They didn\u0026rsquo;t pretend async execution doesn\u0026rsquo;t matter. They didn\u0026rsquo;t hide infrastructure behavior and hope you wouldn\u0026rsquo;t notice.\u003c/p\u003e\n\u003cp\u003eA mature ecosystem doesn\u0026rsquo;t have magic. It has tools that show you what\u0026rsquo;s happening so you can make real decisions instead of discovering the truth during an incident.\u003c/p\u003e\n\u003cp\u003eThe frameworks and libraries that\u0026rsquo;ll thrive going forward are the ones making system behavior transparent, testable, debuggable. Not the ones selling simplicity through opacity.\u003c/p\u003e\n\u003cp\u003e2025 taught us that honesty scales better than convenient abstractions that break under production load.\u003c/p\u003e\n","date_modified":"2026-05-26T10:22:03+02:00","date_published":"2025-12-30T17:00:00+01:00","id":"https://daily-devops.net/posts/dotnet-2025-year-in-review/","language":"en","summary":"No runtime revolutions—Aspire, TUnit, and Testcontainers won by making distributed systems visible. Plus .NET's open source sustainability crisis.","tags":["opensource","architecture","dotnet","csharp","aspire","testing","softwareengineering","technicaldebt"],"title":"2025 in Review: The Year .NET Stopped Lying to Itself","url":"https://daily-devops.net/posts/dotnet-2025-year-in-review/"}],"language":"en","title":".NET Aspire and Distributed Apps on Daily DevOps \u0026 .NET","version":"https://jsonfeed.org/version/1.1"}