During my recent project where I migrated an ASP.NET Core application to Azure SignalR Service, I encountered a notable issue with HttpContext. In standard ASP.NET SignalR setups, I could easily access HttpContext via IHttpContextAccessor in my Hub class. This approach had been working flawlessly for me for years. However, after the migration to Azure SignalR Service, I noticed that IHttpContextAccessor didn't provide the same level of information. This change is understandable, considering the connection in Azure SignalR Service is between the client and Azure, rather than directly to my server's hub. To adapt, I shifted my strategy to directly pass essential data, such as timezone information, from the client to the hub. This method of passing parameters directly turned out to be a more efficient solution. Additionally, I appreciated how Azure SignalR Service manages IPrincipal information from HttpContext, which is useful for identity management using the Context.User property. This experience was a valuable addition to my ongoing journey of mastering evolving technologies in the .NET and Azure ecosystems.

Failures in your application often are not just because the code you wrote is bad, it's often because services or dependencies you depend on are having an issue. Health Checks in ASP.NET Core help you identify the problem areas.

For C# Advent 2020, I want to talk about SignalR ConnectionIds and the biggest mistake I see people making when trying to manage them theirselves.