ASP.NET Core News is the only weekly newsletter dedicated to ASP.NET Core. Whether you build Razor Pages, MVC applications, Web APIs, Blazor, SignalR awesomeness, or anything else available on the ASP.NET...

微软宣布了 .NET 11。该版本是标准支持版本 STS，提供两年支持，上个版本 .NET 10 则是长期支持版本 LTS。.NET 11 改进 C# 15、ASP.NET Core、.NET MAUI 以及 Windows，缩短了应用构建时间，主要变化包括：C# 15 引入了联合类型和封闭类层次结构；Native AOT CLI；ASP.NET Core 支持异步验证和 OpenAPI 3.2，以及 Blazor 和 SignalR 应用的新功能；等等。

ASP.NET Core News is the only weekly newsletter dedicated to ASP.NET Core. Whether you build Razor Pages, MVC applications, Web APIs, Blazor, SignalR awesomeness, or anything else available on the ASP.NET...

Guia de SignalR no .NET 10: Hubs, cliente Angular, autorização, reconexão, grupos e escala sem tratar notificações como estado durável.

I build business software on the Microsoft stack for a living. This year I built something different: My Event Bingo, a live bingo game for meetings, presentations and watch parties. A host writes 25 squares from the things that will happen at the event ("someone says synergy", "the dog walks into frame"). Everyone joins from a link or QR code and gets their own shuffled 5x5 card. There is no number caller; the event does the calling. It runs on .NET 10. One Razor Class Library of about 200 components serves both the website (a Blazor Web App) and a .NET MAUI Blazor Hybrid app for iPhone, Android and Windows. SignalR carries everything live: marks, chat, polls, game start, game over. Here is what a live multiplayer game taught me that CRUD apps never did. ## 1. The server owns the lifecycle. Clients only mirror it. Early on, each client worked out for itself whether the game had started, whether someone had won, whether it was over. That is a recipe for two phones showing two different truths. Now there is one enum, derived on the server and pushed out: public enum GameLifecycle { NotStarted, // before StartTime; the host can still edit squares Started, // StartTime crossed, this player hasn't marked anything yet InProgress, // at least one square marked WonByMe, // this player holds a line; the game continues for everyone else Paused, // host paused; marking is blocked, chat still works Ended // winner limit reached, time limit reached, or host finished it } Every transition has a SignalR event. A client may compute the phase locally only on a cold start, before the first push arrives. After that, the server is the source of truth. When a rule changes, it changes in one place. ## 2. Nobody clicks at 7:00 PM. Something on the server has to. A game has a start time. At that moment the Join button needs to light up on every waiting phone, even if nobody touches anything. My first version only noticed the start time when a request came in. Visitors sat on a welcome card with a dead button. The fix is a hosted service, a `BackgroundService` with a `PeriodicTimer`: // Simplified public sealed class GameLifecycleScheduler : BackgroundService { private static readonly TimeSpan TickInterval = TimeSpan.FromSeconds(15); protected override async Task ExecuteAsync(CancellationToken stoppingToken) { using var timer = new PeriodicTimer(TickInterval); while (await timer.WaitForNextTickAsync(stoppingToken)) { // 1. Only look at games that have someone connected right now. // 2. StartTime crossed and not yet announced -> send "game started". // 3. StartTime + 24h crossed -> mark the game ended, then send "game over". } } } Three details turned out to matter: * **Filter on live sessions, not database rows.** A brand-new game has zero player rows but plenty of connected visitors, and those visitors are exactly who needs the push. * **Dedupe "started" on delivery, not on attempt.** If the push reached nobody, retry on the next tick for a short window. A duplicate start is harmless because the client handler is idempotent. A missed start is the bug you are trying to fix. * **Dedupe "ended" in the database.** Flip `IsEnded = true` before broadcasting. Whichever transaction commits first wins, and the scheduler and a last-second square tap can't both end the game. Fifteen seconds is the worst-case delay a player can feel, and it costs two narrow indexed queries per tick. ## 3. A visitor is not a player until they say so My original page load did two things at once: it fetched the game and generated the visitor's card. A GET that writes. Anyone who opened the link, including a link-preview bot, became a player with a locked card. Now loading the game is read-only, and joining is an explicit `POST /api/bingo/joingame`. It is idempotent: call it twice and you get the same card back, never a second card and never an error. The client also disables the button while the request is in flight, but the server does not rely on that. Rule of thumb I now apply everywhere: if a GET changes state, it will eventually be called by something you didn't expect. ## 4. Two tabs, one player: last in wins People open the game link in a second tab or on a second device. If both sessions can mark squares, you get double events and confused boards. A singleton `GameplaySessionRegistry` keys sessions by `UserId|GameId`, gives each registration a monotonic version, and treats the newest one as authoritative. The older session is told it has been superseded, and gameplay commands from it are ignored. It is in-memory and `ConcurrentDictionary`-based. The few read-then-write paths that `ConcurrentDictionary` can't make atomic on its own take a short lock. The same registry answers a question SignalR groups would normally answer: who should get this event? This app routes per connection through the registry instead of using groups, which made it easy to include people who are on the welcome card but haven't joined yet. ## 5. InteractiveAuto means your component boots more than once Gameplay uses the `InteractiveAuto` render mode. A first visit runs on a Server circuit; a returning visit runs on WebAssembly. That is great for load time. It also means a component can prerender, boot on the server, and later boot again in the browser. What helped was sorting state into three buckets: * **Server-authoritative** (the game, players, card, lifecycle, winners): re-fetched on every interactive boot, then kept current by SignalR. Never trusted from a client-side cache. * **UI preferences** (selected tab, mark color): nice to keep, fine to rebuild. * **UI-ephemeral** (animations, unread counts, scroll position): allowed to reset. Once the rule is "server state is always re-fetched, everything else is best-effort", the handoff stops being scary. The other half is guarding JavaScript interop: create the `DotNetObjectReference` once per component instance, dispose it when the component goes away, and make every setup path safe to run twice. Treating "boot" as something that can happen again removed a whole class of ghost-handler bugs. ## 6. Derive winners from the event log, and decide what "first" means Several players can win. Who finished first? I don't store a winners table. Every bingo, and every lost bingo, is already logged as a `GameEvent`, so winners are projected from that log when the game ends. The interesting decision was the timestamp. A player's finish time is the _latest_ moment they went from "no line" to "holding a line". If you make a bingo, un-mark a square, and remake it later, you are timed at the remake. That keeps the ordering fair without recording which squares formed the line. ## What I'd tell anyone starting a real-time Blazor app * Decide early which side owns time, and put a background service behind it. * Make every state-changing call a POST and make it idempotent. * Assume a component will boot twice, and write setup code that is safe to rerun. * Keep the UI library thin. I've been retiring a third-party component suite in favor of small in-house primitives, and every one I replace makes the render-mode handoff easier to reason about. If you want to see it running, start a free game at myeventbingo.com and open it on two phones. Happy to answer questions about the SignalR or MAUI side in the comments.

ASP.NET Core News is the only weekly newsletter dedicated to ASP.NET Core. Whether you build Razor Pages, MVC applications, Web APIs, Blazor, SignalR awesomeness, or anything else available on the ASP.NET...

A vulnerability was found in GiantappMan LiveWallPaper 2.6.8.0 on Windows. This issue affects some unknown processing of the file /LiveWallpaper/UploadFile of the component SignalR Hub. Performing a manipulation results in missing authentication. The attack is possible to be carried out remotely. The exploit has been made public and could be …

Real-time client for Flutter: ASP.NET Core SignalR, classic SignalR 2.x and WebSockets. Either-based errors, auto-reconnect, reliable sends, offline queue, test doubles. Changelog excerpt: Dependency constraints raised. No API or behaviour changes. - `equatable` `^2.1.0`→ `^3.0.0`. An app that pins `equatable`to 2.x must move to 3.x to resolve this version. - `http` `^1.1.0`→ `^1.6.0`, `logging` `^1.2.0`→ `^1.3.0`, `web_socket_channel` `^3.0.2`→ `^3.0.3`, `internet_connection_checker_plus` `^3.1.1`→ `^3.1.2`.

ASP.NET Core News is the only weekly newsletter dedicated to ASP.NET Core. Whether you build Razor Pages, MVC applications, Web APIs, Blazor, SignalR awesomeness, or anything else available on the ASP.NET...

After a talk I gave about the difference between SSE and SignalR, and how to implement user-targeted messages in both of the tools, I was asked a very important question that I hadn’t covered during t...

ASP.NET Core News is the only weekly newsletter dedicated to ASP.NET Core. Whether you build Razor Pages, MVC applications, Web APIs, Blazor, SignalR awesomeness, or anything else available on the ASP.NET...

How to relay NServiceBus events to occasionally-connected clients via SignalR.

Most messaging is about one node handling each message, but sometimes every node needs a copy. Here's how to do that with NATS in a Wolverine application, the new BroadcastToAllNodesAsync() in Wolveri...

In modern applications, and for a long time now, real-time communication between clients and servers has been very important. It’s used in streaming, dashboards, notifications, and many more features....