About Vibe Coding ...
.NET MAUI Community Standup: Inspect, Record, Create: .NET MAUI Meets GitHub Copilot Canvas 🤝
Join us with Dominik Titl for a look at a new developer tool that brings inspection, layout analyzers, test recording, and GitHub Copilot Canvas together for .NET MAUI. See how developers and Copilot can inspect and interact with running apps, create repeatable tests from those interactions, and use captured evidence to diagnose failures, all through a shared experience in Visual Studio Code, GitHub Copilot Canvas, or any modern browser. 🎙️ Featuring: David Ortinau (@davidortinau), Gerald Versluis (@jfversluis), Dominik Titl (@morning4coffe) 🔗 Links: DevFlow overview: https://aka.ms/dotnet/Dev-Flow Inspector Setup: https://aka.ms/dotnetmaui/inspector-setup https://www.theurlist.com/maui-standup-september26 #dotnetmaui #copilot #canvas
Meet Your Claw: A Harness in Three Lines of C#
One call to AsHarnessAgent gives us the whole agentic loop. From there we add the first three abilities: a custom get_stock_price tool, the built-in web search for market news, and planning with a todo list plus plan and execute modes. That is enough to turn a vague request like “review my watchlist and suggest something to add” into a tracked, step-by-step plan. We wire the agent to a Microsoft Foundry chat client, run it in the shared harness console, and set up the companion repo so everyone starts on the same SDK version. 📌 This event is part of a series. Learn more here: https://aka.ms/FMTA/series 🔗 Learn more by exploring the resource: https://aka.ms/AgentHarness #MicrosoftReactor #LearnConnectBuild [eventID:27514]
Let's Learn .NET: Let's Learn GitHub Copilot SDK
Join this beginner-friendly livestream to learn how to build agentic applications with the GitHub Copilot SDK for .NET, without implementing the agent loop yourself. Unlike calling a model API directly, the SDK gives your application programmatic access to Copilot’s agent runtime, including conversation management, planning, tool orchestration, streaming events, and session state. During the session, we’ll explore clients, sessions, prompts, and the agent runtime. You’ll learn how to create multi-turn conversations, stream responses in real time, expose application functions as tools, connect external capabilities through MCP servers, and control agent behavior with hooks and permission handlers. We’ll also help you understand when to use the Copilot SDK instead of the interactive Copilot CLI: use the CLI for developer tasks in the terminal, and use the SDK when you want to embed Copilot’s agentic capabilities in your own application or service. No prior experience with the GitHub Copilot SDK is required. 🎙️ Featuring: James Montemagno (@JamesMontemagno), Matt Soucoup (@codemillmatt) #dotnet #githubcopilot # copilotsdk
Test what you ship: MSTest and Native AOT
<p>MSTest source generation lets test projects use the same Native AOT and trimming deployment model as the applications they validate, while reducing reflection on the test execution path.</p> <p>The post <a href="https://devblogs.microsoft.com/dotnet/mstest-source-generation/">Test what you ship: MSTest and Native AOT</a> appeared first on <a href="https://devblogs.microsoft.com/dotnet">.NET Blog</a>.</p>
Production Ready: Observability, Governance and Deployment
The last episode covers what you need before any of this runs somewhere real. OpenTelemetry traces and logs show exactly what the agent did on each turn. Purview handles governance and data protection. Evaluation gives us a way to tell whether quality holds as the SDK keeps moving. Then we deploy to Foundry Hosted Agents so the thing runs as a service instead of a console app. We close by walking through the full refresh-prompt workflow as a maintenance pattern worth stealing. 📌 This event is part of a series. Learn more here: https://aka.ms/FMTA/series 🔗 Learn more by exploring the resource: https://aka.ms/AgentHarness #MicrosoftReactor #LearnConnectBuild [eventID:27520]
Scaling the Claw: Skills, Shell, CodeAct and Background Agents
Four additions make the agent genuinely useful. Skills package domain knowledge such as valuation and risk scoring into files it discovers and loads only when a request calls for them, including skills managed centrally in Foundry that update with no redeploy. Shell access lets it reorganise a messy folder of trade confirmations, confined to one working directory. CodeAct gives it a sandbox where it writes and runs code to work out an answer rather than guessing at the arithmetic. Background agents let it research several tickers at once and pull the results back together. 📌 This event is part of a series. Learn more here: https://aka.ms/FMTA/series 🔗 Learn more by exploring the resource: https://aka.ms/AgentHarness #MicrosoftReactor #LearnConnectBuild [eventID:27519]
Working With Your Data, Safely: Files, Approvals and Memory
So far the agent can talk about markets but cannot touch anything of yours, and nothing stops it doing something it should not. This episode fixes both. We give it file access so it reads a real portfolio.csv and writes its reports back to disk, then put a place_trade tool behind an explicit human approval. Approving every single read gets old fast, so we add auto-approval rules for the safe calls and one custom rule that clears small trades on its own. We finish with durable memory in two forms, the files the agent curates itself and the facts Foundry extracts automatically, and watch both survive a restart. 📌 This event is part of a series. Learn more here: https://aka.ms/FMTA/series 🔗 Learn more by exploring the resource: https://aka.ms/AgentHarness #MicrosoftReactor #LearnConnectBuild [eventID:27518]
Don't teach Claude how to run your application #claude #aiengineer #claudecode
3 Claude Code Skills I Wish I'd Found Sooner
🤖 Learn how to take the best out of Claude Code with me: https://dometrain.com/course/getting-started-claude-code/?ref=gui-ferreira&promo=youtube&promotion=youtube ⌨ ThatPrompt: https://thatprompt.ai?utm_source=youtube #claudecode #claude #dotnet #ai #aiengineer
The pain of serializing unions and closed class hierarchies with System.Text.Json: Exploring the .NET 11 preview - Part 7
In this post I discuss the System.Text.Json support for unions and closed hierarchies coming in .NET 11, the decisions made, and some of the sharp edges I hit
Cordango: Define Your App Once, Generate the Code You Own
What if you could define an entire business application once, run it on a hosted platform, or generate conventional source code that belongs completely to you? In this session, Tim Cadenbach demos Cordango, an open application platform built around a portable App Definition. That same definition can be interpreted directly by the Cordango platform or deterministically compiled into a conventional software project you can deploy anywhere. We walk through how Cordango works, what an App Definition looks like, and how the platform approaches application development from a very different direction. Today, the first supported generation target is .NET + Vue, with Node, Python, React, and additional targets planned. The generated applications have no runtime dependency on Cordango. There is no license server, model API, Cordango account requirement, or phone-home dependency. Once the code is generated, it is simply your project and your code. Cordango's underlying app format, compiler, validator, and standalone generator are also available under Apache 2.0. The project is currently pre-alpha, so the format and tooling are still evolving, but the standalone generator already works end to end. In this video we cover: 0/ What Cordango is 1/ The Cordango App Definition format 2/ Running applications directly on Cordango 3/ Deterministic source-code generation 4/ Generating .NET + Vue applications 5/ Owning and deploying the generated source independently 6/ Cordango's approach to portable application definitions Where the platform is heading next If Cordango's model works, the interesting idea is not simply "another low-code platform." It is the possibility of separating what an application is from how that application is implemented. One definition. Many targets. Your code. Source code: https://github.com/Cordango/cordango Follow Tim here: https://github.com/deejaytc https://www.tcdev.de/ https://x.com/TimCadenbach https://www.linkedin.com/in/timcadenbach/ #Cordango #SoftwareEngineering #DotNet #VueJS #OpenSource #CodeGeneration #ApplicationDevelopment #DeveloperTools
.NET Data Community Standup: How to start contributing to Entity Framework Core
Learn how to start contributing to the Entity Framework Core project. Where to start. How to build the repository. How it is layered. How tests work. Etc. 🎙️ Featuring: Jiri Cincura #efcore #ef #dotnet #community
How Uno Platform uses .NET, MCP, and AI to build high quality apps
<p>How Uno Platform built two Model Context Protocol servers in C# so AI agents can ground themselves in real documentation and then see and drive a running cross-platform .NET app.</p> <p>The post <a href="https://devblogs.microsoft.com/dotnet/how-uno-platform-uses-dotnet-mcp-ai-to-build-high-quality-apps/">How Uno Platform uses .NET, MCP, and AI to build high quality apps</a> appeared first on <a href="https://devblogs.microsoft.com/dotnet">.NET Blog</a>.</p>
Debugging my new network, when 10 Gigabit Ethernet Runs at 300 Megabits
<div><p>I've been moving my home storage over to a UniFi UNAS Pro 8 as <a href="/blog/migrating-a-synology-nas-to-a-unifi-unas-pro-8-with-robocopy-smb-multichannel-and-surprising-performance-traps">part of a larger homelab moderization</a>. My main IRONHEART (the ultimate PC from a few years back) desktop now has an Intel E610-XT2 10GbE card, the NAS is on 10GbE, and there's a Minisforum MS-01 miniPC on the same network with a 10GbE SFP+ connection running Immich and Portainer and a few other things.</p> <p>Everything says 10 gigabit. Windows says 10 gigabit. UniFi says 10 gigabit. SMB copies are using the correct NIC but my file copies are running at around <strong>100 to 200 megabits per second which is sad making.</strong></p> <p>Naturally, I blamed the NAS, and the spinning rust within. The UNAS has six 16 TB spinning disks in RAID 6 and a pair of NVMe SSDs being used as cache. I'm also running Immich on the MS-01, with its photo library living on the UNAS, so there are lots of thumbnails, metadata reads, and little background writes happening. All seem like reasonable suspects.</p> <p>I switched the UNAS SSD cache from read-write to read-only. No meaningful difference. I stopped Immich completely. No difference. I looked at <code>iostat</code>; the disks weren't saturated. We looked at SMB signing and Windows Defender network scanning. Still slow.</p> <p>Then I stopped testing the NAS and ran <code>iperf3</code> directly between the Windows desktop and the MS-01:</p> <pre><code>iperf3 -c 192.168.1.222 -P 4</code></pre> <p><strong>133 Mbit/sec</strong></p> <p>Oops. The reverse test was better, but still wrong:</p> <pre><code>iperf3 -c 192.168.1.222 -P 4 -R</code></pre> <p><strong>1.33 Gbit/sec</strong></p> <p>That's weird. Now the disks, SMB, Immich, RAID, and the NAS itself were completely out of the equation. This was a Windows/NIC problem and it's weirdly asymmetrical.</p> <p>Looking at the Intel adapter statistics shows me...</p> <pre><code>Get-NetAdapterStatistics -Name "Ethernet - 10 Gig Intel"</code></pre> <p>There were nearly a million <code>ReceivedDiscardedPackets</code>. During one ten-second <code>iperf3</code> test, the counter increased by another 268. Why?</p> <p>The E610 driver had its receive buffers at the default <strong>512</strong>, although it supported up to 4096. I increased them. I love an increased buffer.</p> <pre><code>Set-NetAdapterAdvancedProperty ` -Name "Ethernet - 10 Gig Intel" ` -DisplayName "Receive Buffers" ` -DisplayValue "4096"</code></pre> <p>The discarded-packet count during the next test went from <strong>268 to zero</strong>, and receive throughput jumped from <strong>1.33 Gbit/sec to 5.15 Gbit/sec</strong>. The transmit direction was still terrible, basically <strong>313 Mbit/sec</strong>. The next experiment was disabling Large Send Offload (LSO) V2 for IPv4:</p> <pre><code>Set-NetAdapterAdvancedProperty ` -Name "Ethernet - 10 Gig Intel" ` -DisplayName "Large Send Offload V2 (IPv4)" ` -DisplayValue "Disabled"</code></pre> <p>Then I ran the same <code>iperf3</code> test again.</p> <p><strong>7.03 Gbit/sec</strong></p> <p>That's not a typo. <strong>313 Mbit/sec to 7.03 Gbit/sec by changing one NIC setting.</strong> Sweet sassy molassey.</p> <p>LSO exists for a good reason: Windows can hand large TCP buffers to the NIC and let the adapter/driver segment them into network-sized packets, reducing CPU work. Microsoft does, however, explicitly point out that segmentation offload can reduce maximum sustainable throughput with some network adapters/configurations. LSO is usually useful, but not in this case.</p> <p>In my particular combination of Windows and the Intel E610-XT2, something in the IPv4 LSO path was very, very sad. I don't yet know whether this is an Intel driver bug, firmware issue, Windows interaction, or something particular to this machine, so I wouldn't turn this into random tech blogger advice that everyone should disable LSO. <strong>Measure first, cut once. Er, twice. Just stay woke.</strong></p> <p>Finally I went back to the test that started all this and copied the same large file to the UNAS and Robocopy reported:</p> <pre><code>Speed : 350,201,354 Bytes/sec. Speed : 20,038.682 MegaBytes/min.</code></pre> <p>About <strong>350 MB/sec</strong>, or <strong>2.8 Gbit/sec of sustained real-world SMB writes</strong> to a six-disk RAID 6 NAS.</p> <p>That's much more like it. The useful lesson isn't "disable LSO." It was that when storage is mysteriously slow, eventually you have to stop testing storage. <code>iperf3</code> removed the NAS, filesystem, RAID, cache, SMB and disks from the experiment in one move. Once the raw network was also slow, the problem became dramatically smaller. And, sometimes the little checkbox labeled <strong>Large Send Offload</strong> is capable of making your 10 gigabit card run like it's 2004.</p> <p>TL;DR - with LSO V2 for IPv4 enabled, Windows-to-Linux <code>iperf3</code> managed about <strong>313 Mbit/sec</strong>. Turning off that single offload took the exact same test to <strong>7.03 Gbit/sec</strong>. I’m deliberately saying <em>on this machine</em> because LSO is normally useful and this isn’t blanket advice to disable it everywhere. </p><br/><hr/>© 2025 Scott Hanselman. All rights reserved. <br/></div>