When I designed a control flow between an API and agents in my homelab/prod setup, it became obvious that loose HTTP calls didn’t model the problem well. I needed a persistent, typed, bidirectional channel — and that’s where gRPC in .NET 10 came into the picture.

What gRPC solves best

• Strong contract between services — client and server agree on method names, input/output types, and message shape through .proto files.
• Continuous communication — instead of multiple independent requests, you can keep a stream open for heartbeats, inventory updates, and even an interactive terminal.
• More natural for internal scenarios — it makes more sense when the services are under the same team’s control and share contract versions.

Where it fits in the architecture

In the Dokpod case, the split looked like this:

• Outbound connection initiated by the agent — this helps in scenarios where the host sits behind NAT or a firewall.
• Client certificate authentication — adds identity to the channel between the API and agents.
• HTTP/2 as the base — the transport fits the model of multiple messages over a single connection much better.

When I would choose gRPC

• When both ends are controlled by the same team.
• When you want typed messages and code generation.
• When bidirectional streaming is central to the problem.
• When the communication is more “service-to-service” than “human client to API”.

When I would avoid it

• When the consumption needs to be open and simple for third parties.
• When REST already solves the use case well.
• When the team wants an easier surface to inspect manually.

In the end, gRPC is not a universal replacement for REST; it’s a very specific tool for very specific problems. In my case, it fit because there was a real need for persistent streaming, strong contracts, and internal communication between components. How are you using gRPC in .NET — only for internal service calls, or have you pushed it closer to the edge as well?

I maintain an older ASP.NET WebForms/Web API application written in VB.NET, targeting .NET Framework 4.8.
It runs as a 32-bit application under IIS Express.

These days I do most of my editing outside Visual Studio with help from a coding agent, so I’m wondering how much I still need VS for.

I’ve successfully built the solution from the command line using the MSBuild installed with VS 2022 Professional.
I also have a script to start IIS Express separately. That covers building and running it without opening the IDE, but I’m still using tools from the VS installation.

The part I’m unsure about is debugging.
Has anyone here used dnSpyEx for day-to-day debugging of a VB.NET web application? Can you step through the original .vb files with matching PDBs, or do you mostly work with decompiled code?
How well do breakpoints and variable inspection work?

I’m also unclear about standalone Build Tools licensing for a commercial application like this.
Does using those still require a Visual Studio license? An official reference would be helpful.

Would be interested to hear from anyone maintaining a similar application.
Is this a workable setup, or do you find yourself going back to Visual Studio whenever a server-side bug gets complicated?

Hey everyone! I'm the creator of TickerQ.

I've been reading the recent discussions about the licensing change, and I wanted to share some context and explain what's been happening behind the scenes.

First, I understand the frustration around moving away from open source. TickerQ started as a personal project, but as it grew, maintaining it properly became a much bigger responsibility.

We decided to move to commercial licensing to make development sustainable and invest more in engineering, testing, and long-term support.

Previous open-source versions remain under their original licenses, and the new release includes a free Community license for eligible users.

About the versioning confusion

Some people asked why such a big release came as a minor update.

We've always aligned TickerQ's major package versions with .NET:

• 10.5.x → .NET 10
• 9.5.x → .NET 9
• 8.5.x → .NET 8

So the 5.x represents the TickerQ release generation, while the first number identifies the .NET version.

That said, I understand why introducing a licensing change in a minor update raised concerns, especially with automated dependency updates. We should have communicated this better.

What we've actually been working on

TickerQ 5.x isn't just another update. We've completely redesigned, rebuilt, and re-architected it, focusing heavily on production reliability.

A few highlights:

• 98+ issues resolved, including stability and concurrency problems.
• Enterprise-level testing and benchmarks to improve reliability and performance.
• AI-powered with auto Investigate failures, recomend jobs, alert setup and much more.
• Debug running jobs in real time, and troubleshoot issues directly from the dashboard with AI assistance.
• Workflow orchestration with sequential and parallel execution, conditions, retries, and recovery.
• Completely new dashboard with AI-assisted diagnostics and real-time monitoring.
• Expanded database support including SQL Server, PostgreSQL, MySQL, MariaDB, SQLite, Oracle, CockroachDB, YugabyteDB, MongoDB, and Redis.
• Better distributed execution and worker coordination.
• Business calendar policies, advanced scheduling, and OpenTelemetry.
• Slack, Microsoft Teams, and webhook integrations.

Another important change is that TickerQ is no longer a one-person project. We now have a professional engineering team working on it, with a much stronger focus on testing, maintenance, and support.

I know some people have had issues with previous versions, and I won't pretend everything was perfect. That's exactly why we invested so much effort into rebuilding it.

We're not trying to turn a small hobby library into a paid product overnight. We're trying to build something reliable that developers and companies can actually depend on long-term.

I appreciate everyone who has supported TickerQ, reported bugs, contributed, or even criticized the decisions we've made.

I know we won't convince everyone, but I wanted to explain our side rather than stay silent.

Happy to answer questions and hear your thoughts.

Changelog: https://tickerq.net/docs/5.x/changelog

I wanted a bigger cache, not another Redis instance. So I built a filesystem-backed cache for .NET.

I ran into an interesting problem while working on a .NET application hosted on a VM.

The VM had plenty of disk space, but RAM was a much more precious resource. I wanted to cache a lot of data to avoid repeatedly doing expensive work, but keeping all of that data in memory wasn't particularly appealing.

The obvious options each had trade-offs.

IMemoryCache was straightforward, but I didn't want my cache capacity tied so closely to my application's memory budget.

Redis was an option, but deploying and maintaining a separate caching service felt like unnecessary infrastructure for an application that just needed a larger local cache.

I wondered: why not use the disk we already have?

So I started building a filesystem-backed implementation of .NET's IDistributedCache.

The idea is simple: keep the metadata needed to find entries in memory, but store the actual payloads on disk. Put a hard limit on storage, handle expiration and eviction automatically, and optionally preserve the cache across application restarts.

No separate server. No need to keep every cached payload in managed memory. Just a cache that can grow beyond the application's RAM budget.

I've also integrated it with .NET's HybridCache, so it can serve as a secondary cache without changing the application-level caching API.

I've been benchmarking it against other caching approaches. Redis is impressively fast, and I'm not going to pretend I've beaten it on raw latency. That's not really the point.

The interesting trade-off is capacity versus memory consumption and infrastructure complexity.

I ended up publishing it as Eryri.FileDistributedCache: https://www.nuget.org/packages/Eryri.FileDistributedCache

I'm curious how other .NET developers approach this problem.

If you had a single-instance application with plenty of disk space but a limited RAM budget, would you consider a filesystem-backed cache, or would you reach for something else?

we have a silo cluster serving our trading platform.
we have user role grains that hold user state like positions, current ProfitLoss, etc..

we need to expose for our backoffice webpage, endpoints to serve general queries like "get all positions from today"
"get all orders belong to instrument x" etc...

is there any reason to use 'StatelessWorker' for that? in our case it the statelessworker will just query the db. is it better then just using a standard .net service/singleton that would query the db?

thanks for your help

Microsoft released .NET 10.0.14 on 25 October as an out-of-band security update, and the stated reason is CVE-2026-111497, an out-of-bounds write (CWE-787) in the Brotli decoder bundled with .NET. CVSS 8.1, publicly disclosed, exploitation marked more likely.

Affected and fixed: - .NET 8 before 8.0.33 → 8.0.33 - .NET 9 before 9.0.22 → 9.0.22 - .NET 10 before 10.0.14 → 10.0.14 (SDK 10.0.114 or 10.0.403) - .NET Framework is not affected

The same release completes the October 13 fixes for CVE-2026-70197 (SocketAsyncEventArgs) and CVE-2026-102870 (Blazor WebAssembly debugger), which had shipped incomplete, and adds CVE-2026-114148 for Linux source-build tarballs.

Exposure needs a call path that decompresses attacker-controlled Brotli: request decompression with br enabled, HttpClient AutomaticDecompression including Brotli, or BrotliStream/BrotliDecoder on untrusted input. None of that is on by default, and response compression alone does not hit it. Until you update, dropping Brotli from those paths is a workable stopgap.

Framework-dependent apps need the host runtime updated and restarted. Self-contained apps need a rebuild and republish, and the Blazor WebAssembly Server/DevServer packages have to be bumped separately because the shared runtime update does not cover them.

Advisory: https://github.com/dotnet/announcements/issues/494 Release notes: https://github.com/dotnet/core/blob/main/release-notes/10.0/10.0.14/10.0.14.md

Microsoft shipped fixes on 25 Oct for the Brotli decoder out-of-bounds write (CVE-2026-111497). The fixed versions are .NET 8.0.33, 9.0.22 and 10.0.14, .NET 11 RC3, Visual Studio 2019, 2022 and 2026, and PowerShell 7.4 to 7.6. Microsoft rates it 8.1 and "Exploitation More Likely". No in-the-wild exploitation has been reported yet, and the public PoC only works against a weakened build.

Per the advisories, the exposure is anywhere attacker-controlled Brotli data reaches the decoder: compressed request bodies, responses fetched from untrusted servers and compressed files. Updating the machine-wide runtime is the easy part. Self-contained deployments and container images that bundle their own runtime need rebuilding.

Has anyone found a reliable way to inventory which services actually decompress Brotli input, or are you just rebuilding everything?

I maintain DrDXT, an open-source (GPL-3.0) Windows game optimizer. It has to touch system

settings, and I didn't want the UI to run elevated. So:

- the WPF UI runs as the user;

- a separate elevated helper only accepts a fixed set of bounded operations, and anything

outside the list is refused;

- each write journals the original value first, so a crash, a rollback or an uninstall

restores it.

CI runs almost 9,900 tests, plus CodeQL, on GitHub Actions.

I'm curious how others handle this. Do you use a separate service, a scheduled task, or

something else? And if anyone wants to dig in, there are good first issues:

https://github.com/ablanchard-dev/drdxt/issues

Repo: https://github.com/ablanchard-dev/drdxt

For example I have the nuget "Microsoft.Data.SqlClient" Version="7.1.1" and it depends on "System.Security.Cryptography.Pkcs" Version="9.0.18" which has some kind of vulnerability. So I manually added "System.Security.Cryptography.Pkcs" Version="10.0.13" to the project.

my hope is that "Microsoft.Data.SqlClient" will upgrade their version and then reference a new/safe version of "System.Security.Cryptography.Pkcs" all on its own and go maybe even beyond Version="10.0.13" which would be the perfect time to remove my direct dependency again and rely on the transitive one. IF I still remember that I did that in the first place.

How do you deal with such issues?

For only web I would easily go with blazor of course. And MAUI also seems like a nice option but I don't think it would feel as good on mobile as something like React Native.

Are there any other options, or what is your go to framework?