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?

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

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?

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?

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

I got tired of keeping heavy browser tabs open in the background just to listen to songs while working and gaming, so I put together a tiny WPF floating widget for Windows that docks right above the taskbar.

You can drag it anywhere on the screen, pick an artist, and it pulls songs from YouTube.

One tricky bug I ran into: modern WPF MediaElement blocks direct HTTPS CDN streams due to security zone policy restrictions (it kept throwing "Only site-of-origin pack URIs are supported for media"). I solved it by caching the audio stream into a temp m4a file first. An unexpected bonus is that seeking works smoothly and replay is instantaneous with zero network lag.

Code and pre-built binaries are open-source on GitHub:

https://github.com/selfi123/Taskbar-Music-Player

Feedback and feature ideas are welcome!

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?

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?

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

Saw the license thread yesterday. One thing i havent seen mentioned is that the licensed packages don't come as a new major. On the .NET 10 line it goes from 10.4.0, wich is MIT OR Apache-2.0 on NuGet, to 10.5.0 under the new TickerQ Software License Agreement. Same on the other lines with 9.5.0 and 8.5.0.

So if your Dependabot or Renovate config only holds back majors, the next PR it opens could be the license change. And going by their licensing page, a missing or invalid license file blocks job execution, so as far as i can tell the jobs just stop rather than log a warning.

The free Community tier covers companies under USD 5 million in revenue, so alot of people will be fine there, but you still need to get the license file and wire it in with UseLicense(...). Haven't tried that flow myself.

If you want to stay on the MIT releases for now, pin it. With central package management:

<PackageVersion Include="TickerQ" Version="[10.4.0]" />

In dependabot.yml:

ignore:
  - dependency-name: "TickerQ*"
    versions: [">= 10.5.0"]

And for Renovate, a packageRule with "matchPackageNames": ["/^TickerQ/"] and "allowedVersions": "<10.5.0".

Use the right number for you're line (9.5.0 or 8.5.0 if you're on those), and do the same for every TickerQ package you reference, not just the main one.

A few months ago, I posted about my library.

Quick description: It's a Markdown viewer control for Avalonia UI 12, built on Markdig. It renders to native Avalonia controls, with no WebView, so it behaves the same on Windows, macOS, Linux and in the browser (WebAssembly).

12.4 came out this week, with a lot of new features:

• Streaming. viewer.BeginStreaming() returns a session you can Append text to from any thread (e.g. tokens from an AI chat) . Only the blocks still being written re-render, so scroll position, selection and focus survive every update. A half-written **bold or link renders as it will once complete, and <think> blocks fold into "Thought for 12 seconds" when they end.
• Mermaid diagrams and LaTeX math in pure .NET (Mermaider and CSharpMath), including the \(…\) delimiters models like to emit.
• Theme presets: GitHub, Chat (takes your message bubble's colours) and Docs. Light/dark switches live.
• Code blocks with a copy button, and optional line numbers, wrapping and max height. TextMate highlighting is a separate package.
• Find, folding (alerts, <details>, headings), a context menu with copy as Markdown, HTML or a table, and saving a diagram as SVG or PNG.
• Accessibility: screen reader roles, Tab through links, WCAG AA colours and a high-contrast mode. Right-to-left text too.

Streaming is mostly intended for AI integration. With Microsoft.Extensions.AI it's a few lines:

using var session = viewer.BeginStreaming();
await foreach (var update in chatClient.GetStreamingResponseAsync(prompt))
session.Append(update.Text);

There was a lot of focus on improving the performance to make it viable in the browser (WebAssembly). It's not yet enough and the upcoming 12.4.1 version will make it even better.

Try it in your browser: https://kryptos-fr.github.io/MarkView.Avalonia/demo/

Docs: https://kryptos-fr.github.io/MarkView.Avalonia/

Repo: https://github.com/Kryptos-FR/MarkView.Avalonia

Package: https://www.nuget.org/packages/MarkView.Avalonia

If you use another Markdown control in an Avalonia or WPF app today, I'd like to know what would make you switch, or what's missing.

Full disclosure: I used Claude AI to work out the roadmap, discuss the architecture and implementation candidates. I then delegated the coding to Claude sub-agents while I did all the review and manual testing. I kept it transparent on the repo where all such commits include a "Co-authored-by: Claude" mention.

On that note, I found that Claude was very efficient when all projects have a high test coverage (currently 95%), as well as mutation testing using Stryker (also 95%). That causes some delays in CI where Stryker can take up to 3 hours but in my opinion it is worth the trouble.

I've gotten tired of slow PDF converters, and packages that change to paid licensing, like PDFsharp just changed to AGPL from v6.5.0. So I’ve built PdfPecker over the past 2 weeks with Claude as a coding assistant, and I’ve tested and reviewed everything myself.

I've tested it to get very close to Chrome, and it's now closer than Firefox. PdfPecker matched Chrome 97% on 103 pages, compared to Firefox's 95%. It's crazy how many differences there can be when rendering HTML to PDF, I haven’t seen any two that render it the same when the pages become complex.

Main bullets:

• Zero dependencies
• No Chrome
• Modern CSS
• No JavaScript, it's built for templates you control
• It can render from HTML to PDF in under 1ms for a typical invoice
• Uses very little memory
• MIT license

You can find the package on https://www.nuget.org/packages/PdfPecker

PdfPecker.Fluent has also been created to make a QuestPDF style C# API.

Getting started:

using PdfPecker;

byte[] pdf = HtmlToPdf.Convert("<h1>Hello</h1><p>World</p>");
File.WriteAllBytes("hello.pdf", pdf);

Feedback welcome, especially HTML that breaks PDF rendering.

Really a question for professionals in this niche industry. Still an on-prem saturated market albeit many cloud players in this market and push for AI Analytics in everything.

I am a support professional and consider myself a domain expert in this field. I also am working 2 projects myself in .NET. First is, an Android camera app using C#/Android SDK (not MAUI). The other is a network video recorder using ASP MVC.

I really enjoy development and would love to transition to this kind of work. What is the workload like? How much between refactoring older code and shipping new features? I know alot of these codebases are 15-20 years old. Is trying to transition right now worth it or just stick to handling escalated support.

I am located in NYC so if there are events or local resources I could seek for advice or even mentoring. I am the only person who understands programming at my job and I have no greybeards or wizards to ask questions to.

Thanks!

Pretty much how much of a big deal is this feature?

Improvements across Spec, Sample and Faster, plus stronger input validation and clearer error handling.

Some breaking changes (mostly removals/renames and the target framework shift from net8). Most users should have a small migration. Full details:

https://www.nuget.org/packages/CsCheck/5.0.0#releasenotes-body-tab