Don't you just hate errors that will tell you something is wrong, but not tell you what? I ran into that case recently while refactoring an Azure Functions project. Worker failed to index

On May 31st, 2024, Hampton Roads DevFest successfully re-engaged the local developer community in Virginia Beach, Virginia, with 183 attendees. Organized by the non-profit RevolutionVA, the event featured local speakers and took place at the Zeider's American Dream Theater, chosen for its affordability and unique setting. Ticket sales and sponsorships, including support from Microsoft, contributed to the event's income, though it ended with a net loss of $486.63. Despite this, the event was deemed a success, effectively revitalizing the community and providing valuable insights for future events.

Last week, the team and I were migrating an application built with ASP.NET Core and SignalR to use the Azure SignalR Service. We ran into an issue with the HttpContext when using Azure SignalR Service. Unlike in a normal SignalR integration, where you can access HttpContext via IHttpContextAccessor in the Hub class, with Azure SignalR Service the connection changes, affecting the available HttpContext data. This required a shift in our approach, leading us to directly pass the necessary information from the client to the hub.

Setting up HangFire in my .NET applications is effortless. This library helps me offload the strenuous tasks from my web applications by establishing background services using my existing code without requiring special interfaces. Its dashboard is handy for managing jobs and gives me a clear view of the active, failed, and scheduled jobs. For scheduling and recurring jobs, HangFire provides flexible configurations. If it fails, it'll make multiple attempts to run a job, making debugging a breeze for me.

As I've been going on the road to talk about background services within the .NET ecosystem, one of my favorites has HangFire. I've been using HangFire in my applications for years, and it's been a vital tool for offloading some of the heavy lifting from my web applications.

In preparation for my latest talk on Tactics for Building Background Services in .NET, I've been working on a sample project to demonstrate the concepts. It's amazing how much easier it is to build Window Services today than it used to be!

I have an obsession with vanity metrics. They're not supposed to be useful, but I think there is an excellent arguement for tracking them.

Our team with one product grew to include two new teams. This meant more people, larger tech stack, and more complexity when it came to support and future growth.

In 2021, I released SignalR Mastery on Udemy. After the first year, I wanted to take a moment to reflect on my journey of building and releasing the course.

I knew that I wanted to move this application to .NET 6, as it would be the new LTS version, and I was foregoing several dependency updates. In particular, there was one dependency that was still based on .NET Framework that was giving me concern. It never made the jump to .NET Standard, so I worried about future compatibility. It was during the amazing Visual Studio 2021 launch video, I saw mention of the .NET upgrade assistant. Now - I feel like a fool because this tool has been around for a while, but it was getting an update to support .NET 6. Maybe this was the tool that would help us go live with .NET 6?