#628 – October 04, 2026
middleware in ASP.NET Core runs on every HTTP request and response
What is middleware in ASP.NET Core and the gotchas
6 minutes by David Grace
Middleware in ASP.NET Core runs on every HTTP request and response. You can write it as a class, but watch out for common mistakes. Forgetting to call next stops the rest of the pipeline from running. Scoped services must be injected into InvokeAsync, not the constructor, since middleware itself lives for the whole app lifetime. You also cannot modify a response after it has started, and background tasks need their own fresh scope to avoid using disposed services.
Beyond grep: Testing codebase memory MCP on .NET
12 minutes by Marek Sirkovský
Most AI coding tools waste tokens by scanning entire codebases when asked simple questions. Codebase Memory MCP tries to fix this by building a local knowledge graph of your code using tree-sitter, then exposing it to AI assistants through MCP. It works well for navigating within a single repository, but struggles with newer C# features and fails to trace relationships across repositories or NuGet package boundaries, a limitation shared by similar tools like GitNexus and Grafel.
Automatic CSRF protection based on fetch metadata headers
14 minutes by Andrew Lock
Andrew takes a look at the new Cross-Site Request Forgery protection added to ASP.NET Core in .NET 11 preview 6, which relies on the Fetch Metadata HTTP headers, instead of the "traditional" anti-CSRF tokens used in earlier versions of .NET Core. He talks about CSRF attacks, the existing protections in ASP.NET Core, discusses why a new approach is possible, and provides a brief recap on Fetch Metadata headers. He also shows how this works in ASP.NET Core as of .NET 11 preview 6, and finally, he takes a look at the implementation behind the feature, as well as dives into why the new feature doesn't really help you if you're using MVC or Razor Pages.
The hidden trap of fixed buffers in C#
7 minutes by Kevin Gosse
Adding a constructor to a struct with a fixed buffer changes how memory is initialized. Without a constructor, the compiler zeroes all memory automatically. With one, fixed buffers are exempt from that zeroing rule, so they retain whatever values were in memory before. This is by design in the C# spec but easy to miss. The fix is to manually clear the buffer inside the constructor.
Guid.CreateVersion7 is NOT a sequential guid for SQL server
5 minutes by Bart Wullems
Using version 7 GUIDs in SQL Server causes index fragmentation, just like random GUIDs do. This happens because SQL Server sorts GUID bytes in a different order than the RFC standard, putting the timestamp in the least significant position. Bart says the fix is to let EF Core or SQL Server generate the ID, or use a library that reorders the bytes to match SQL Server's sorting rules.
And the most popular article from the last issue was: