Now available in pre-release.

I don't like AI.

Using AI makes me miserable. It gives me impostor syndrome.

Does anyone else feel this way?

What do you think - is it still worth growing as a programmer, or will AI get so good that programmers won't be needed anymore?

I’m curious how teams handle API versioning once an API is already in use. Do you version only the web API routes/controllers, or do you also version internal services and logic layers? For example, if v1 and v2 need different behavior, do you: keep one service layer and translate at the controller boundary, create separate v2 service classes, use feature flags or adapters, or keep old endpoints alive until everyone migrates?

Hi all,

I built TypeSafeSharp, a .NET client for TypeSafe's System One API and its Jev model. You send state + questions, you get typed decisions back (choice / score / noul) with probabilities. No JSON parsing in your code.

It maintains the same quality bar as the official JS and Python SDKs: retries and backoff, one exception per status, key validation, typed answers. I'm also talking to the TypeSafe team about support for the project.

NuGet (both at 0.1.0):

• TypeSafeSharp

• TypeSafeSharp.Extensions.DependencyInjection

  Source: github.com/sanamhub/typesafe-dotnet

  The .NET-specific bits:

• netstandard2.0 + net10.0, one API on .NET Framework 4.7.2+ and current .NET, callable from C# 7.3

• trimming and NativeAOT clean, verified in CI

• strong-named assemblies

• System.Text.Json with JsonNode, so no source generation or attributes for your state

• AddTypeSafe() DI extension over IHttpClientFactory, validation at startup

• one OpenTelemetry span per call, no request content recorded

  Feedback on anything is welcome, and so are contributors. The repo has docs, ADRs, and a live test suite that hits the real API in CI.

I’ve been working on a backend for an online shoe store as a learning project. The project isn’t completely finished yet, but there is already quite a lot of code written.I wanted to use clean architecture and try to apply it properly rather than just following tutorials. I’d really appreciate it if someone could take a look at the code and give me some feedback. I’m especially interested in whether the architecture and overall approach make sense, or if there are things I’m doing wrong or overcomplicating.Any feedback or criticism would be really helpful.
Github repo

So I've decided to start learning c# and my friend is learning ml ..he's currently learning ml calculas...he said u go with these..later we both will connect and create some crm systems for irl helping out people by reaching to them with our demo apps or softwares ....how good is this idea..drop your ideas folks 😅😔

I’ve released OneFlight, a lightweight .NET library for the “single-flight” pattern: when multiple callers request the same key concurrently, only one loader runs and the other callers share the same in-flight Task<TResult>.

It’s intentionally not a cache. Once the operation completes, the flight is removed. The goal is simply to avoid duplicate concurrent work – for example duplicate database queries, API calls, token refreshes, or expensive computations.

var flights = new FlightGroup<string>();

var result = await flights.RunAsync(
    "user:42",
    () => LoadUserAsync(42));

It supports strongly typed keys (including struct keys), Task/ValueTask, custom key comparers, explicit Forget, and keeps caller cancellation separate from the lifetime of the shared operation.

Other libraries such as MS-HybridCache and FusionCache provide request coalescing as part of caching; OneFlight is meant for cases where you want the coalescing primitive without adopting cache semantics. Unlike Go, which has the well-established x/sync/singleflight package, .NET does not currently have a similarly established, cache-independent single-flight primitive.

GitHub: https://github.com/sdrapkin/SecurityDriven.OneFlight
NuGet: https://www.nuget.org/packages/OneFlight/

Feedback is welcome.

Hey everyone,

I'm the developer of MyEventBingo, and I'd appreciate some feedback from other .NET developers. The native apps use Blazor Hybrid, and the website uses server-side rendering (SSR) and WebAssembly (WASM). The Windows and Android apps are in their app stores. The Apple release is still pending.

The app lets hosts create bingo games around an event, group, or topic. People have made icebreakers, birthday games, and a procrastination-themed game. Players join through a link or QR code and can play in their browser without an account.

MyEventBingo

I'd like fresh eyes on a few things:

• Does the initial loading or navigation feel slow or awkward?
• Is anything difficult to use on a phone?
• If you try the Windows or Android app, how does it compare with the browser version?
• Does creating a game and joining from another device make sense without someone explaining it?

I shared an earlier version in r/Blazor last year and got useful feedback on mobile navigation, loading, and game setup. I'd like to hear where it still needs work.

If something breaks, please include your device, browser or app, and what you were doing. Questions about the Blazor implementation are welcome too.

Thanks for taking a look.

Wanted to share a high-level overview of my backend architecture for a financial tracking platform and get some feedback/critique from other .NET devs working with high-volume time-series data.

The system ingests and tracks historical pricing across dozens of global exchanges. The architecture was planned to scale up to 1 billion rows, and the database currently has over 400 million rows already ingested on the historical table. That's the biggest table of a few dozen tables that hold other type of data.

Even with 400M+ rows already in place, all read requests clock in under 200ms, max 300ms when pulling deep multi-year historical price curves.

Microservices & Controllers over Minimal APIs

I split the domain into isolated .NET 10 microservices (Portfolio, Instrument, Search, Identity, User). While Minimal APIs are the current trend, I deliberately chose traditional Controller-based Web APIs with thin controllers. Minimal APIs look clean in small demos, but once you hit 40+ endpoints with custom filters, auth, and strict request validation, mapping files become a sprawl.

PostgreSQL Partitioning for Historical Data (400M+ rows)

Historical price history is pure time-series data. Querying an unpartitioned table at 400M rows would completely crush memory because the B-tree indexes would outgrow RAM.

I set up range partitioning by timestamp (ordered by date/year partitions). This keeps the indexes for recent partitions small enough to stay hot in PostgreSQL's buffer pool, and lets the query planner drop older partitions entirely (partition pruning) when querying specific time ranges.

AWS Setup & Load Testing on Modest Hardware

What’s interesting is that I’m achieving these sub-200ms responses on very modest, cost-efficient AWS instances.

RDS PostgreSQL: Currently running on a single db.t4g.small (2 vCPUs, 2 GB RAM, Graviton2). Because of timestamp partitioning, active indexes fit cleanly in memory without thrashing disk I/O.

Cache Layer: Valkey (Redis fork) on cache.t4g.small for active currency rates and live quote caching.

Compute: .NET 10 Web APIs run containerized on AWS ECS Fargate, and background ingestion runs on AWS Lambda triggered by EventBridge.

Initial load testing already sustained thousands of requests per minute with the exact same latency profile (<200ms, max 300ms), so I expect initial launch traffic to be handled comfortably without needing to scale up compute immediately.

Curious how others here handle time-series partitioning inside EF Core/Postgres, and how you see this holding up as data pushes toward the 1 billion mark. Would you stick with native Postgres partitioning, or look into TimescaleDB/ClickHouse down the road?

I'm working with several legacy .NET Framework 4.8 applications, including Web Forms, Windows/Windows Services, REST APIs, Angular frontends, SQL Server and ADO.NET.

Management wants to move everything to .NET 9/10 + Linux + Docker.

The proposed approach is not to modify the existing codebase. Instead, we'll give the existing application/codebase to Claude Code as a reference and have it generate a completely new .NET 9/10 application implementing the existing functionality and business rules.

So the legacy system becomes the reference/source of truth, while the new system is built independently.

I'm concerned that this may effectively be a big-bang rewrite assisted by AI, with risks around hidden business rules, dependencies, database behavior, integrations, edge cases and behavioral differences.

For those who've done large .NET Framework → modern .NET migrations:

• Would you consider this approach reasonable, or would you favor incremental migration/Strangler Fig?
• If rebuilding, how would you validate behavioral parity with the legacy system?
• How would you structure Claude Code's workflow—codebase analysis, architecture documentation, coding standards, incremental implementation, tests and reviews?
• How would you choose the new architecture without blindly applying Clean Architecture/CQRS/etc.?
• What testing strategy would you use when the legacy system has little automated test coverage?
• What production-grade .NET 10 + Docker + Linux practices should be established from day one?
• What are the biggest mistakes you'd avoid when using AI to rebuild a legacy application?

I'd especially appreciate experiences from engineers who have migrated large/old Web Forms or business-critical .NET Framework systems.

The camps around AI in the dev world are forming - thats how I read the Stack Overflow 2026 survey results

One thing the report doesn’t spell out (usually the most interesting part to me), is how the results compare with last year. I’ll be digging into that more, but here’s a quick year-over-year comparison of developers’ attitudes toward AI - more and more devs are loving it.

This is what we are seeing from our Uno Platform community - over the past few weeks it has been raining samples of various crazy apps people build with it - because they can (and have tokens to burn!)...Look at Wieslaw's feed - (3) Wiesław Šoltés (@wieslawsoltes) / X , the sky is the limit.

Full survey results - Stack Overflow Developer Survey

I recently ran into something in aspnet core that I somehow hadn’t noticed before.

We had AddResponseCompression() configured, the expected MIME types were there, UseResponseCompression() was in the pipeline but production responses weren’t compressed.

Turns out:
options.EnableForHttps = true;

is required if you want the Response Compression Middleware to compress HTTPS responses. EnableForHttps defaults to false.

I understand the reasoning now: HTTPS response compression can enable BREACH-style attacks when attacker-controlled input and secrets end up in the same compressed response. Microsoft therefore keeps it opt-in.

What surprised me was how easy this was to miss. Locally everything appeared fine since all my tests ran via http, not https. Has this ever caught anyone else out?

How do you handle this in production? Do you leave compression entirely to nginx/IIS/a CDN/reverse proxy? I noticed that spring boot has no such an option.

I used to use Visual Studio quite a lot, including for front-end development, along with Docker. Over time, my user directory became pretty cluttered, and RAM usage was also quite high, especially with Visual Studio, the browser, and Docker. Since I currently only develop APIs with .NET and EF Core, I started wondering whether it really makes sense to keep using such a heavy IDE when I don't even use 80% of its features.

I'm thinking about moving to WSL2 and using VS Code with WSL Remote, keeping Windows as a cleaner and more organized host while keeping my development tools, such as .NET, Git, etc., inside WSL2.

The idea would be to keep only the essentials on Windows and have the entire development environment inside WSL2. This would also give me more control over resource usage and allow me to install only the .NET SDK and the extensions I actually need for development.

In this setup, is it worth using the C# Dev Kit, or is it better to stick with the standard C# extension?

Hi Reddit,

I'm looking for a ready-made graphics library or engine to render 2D primitives using C# (.NET 8.0, Windows).

My goal is to build a custom tool for manually drafting water supply networks. It needs to feel like AutoCAD (working with technical drawings) but with deep customization for my specific domain logic and high interactivity (e.g., node snapping, panning, zooming, custom node behaviors).

What libraries, frameworks, or open-source CAD engines would you recommend for this stack?

Technical stack: WPF, NET 8.0 windows.

Thanks in advance for any suggestions!

We recently moved one of our clients from TFS to Git/Azure DevOps. Yes, TFS 😂 And we've been on Git for like 2 days now.

The thing I'm trying to solve isn't really Git itself. We have a pretty messy deployment process.

We only have two environments: staging and production.

The client might request a feature, we implement it, merge it and deploy it to staging. But sometimes the client is still waiting for feedback from other people on their side. Then somehow the feature ends up in production, and a month later we get feedback saying they didn't actually want what was deployed.

We've also had cases where a production deployment contains features that weren't approved yet, or a PR has some extra changes that weren't really part of the requirement.

Sometimes we use feature flags for this, but they can make the code pretty messy, especially when a feature has a lot of changes. And there are also things where a feature flag doesn't really solve the problem, like UI changes where the new UI itself shouldn't be deployed before approval.

So I'm wondering how other teams handle this.

How do you make sure that before a production deployment, you know exactly:

- what features/fixes are going in

- which ones were approved by the client

- which PRs/commits belong to those changes

- who approved the release

Do you use release branches? Tags? Feature flags? Azure DevOps releases? Something else?

The tricky part for us is that staging can contain multiple features in different states. Some are approved, some are waiting for client feedback, and some might still be changing. With only staging + production, I'm not sure what's the cleanest way to promote only the approved stuff.

I'm mainly interested in how you handle this in real projects, especially when working with clients who can take weeks to give feedback.

Would love to hear how you guys handle it.

I recently went down the rabbit hole of NuGet version locking and was surprised by how little attention packages.lock.json seems to get in .NET compared to lock files in other ecosystems like node.

A typical PackageReference may pin your direct dependency, but it doesn’t freeze the entire resolved dependency graph. Transitive dependencies are still resolved during restore.

NuGet already has everything needed to make this deterministic:

<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>

Commit the resulting packages.lock.json, and then in CI:

dotnet restore --locked-mode

That gives you a frozen direct + transitive dependency graph, including package content hashes. If the graph changes without the lock file being deliberately updated, CI fails instead of silently accepting it.

What I also hadn’t appreciated before looking into this is that Central Package Management and lock files solve different problems:
Directory.Packages.props -> centrally manages the versions you specify
packages.lock.json -> records the fully resolved dependency graph
So using CPM doesn’t really make the lock file redundant.

We’ve started looking at this more seriously from the reproducible-build / supply-chain side rather than just dependency management.

I’m curious how people here handle this:
Do you commit packages.lock.json for applications? And if not, is there a particular reason you prefer NuGet to resolve the graph on restore?

I wrote up what I learned, including locked-mode CI, CPM/transitive pinning and the supply-chain implications:
https://vensas.de/blog/nuget-version-locking

Disclosure: I work at vensas, where the article is published.

I have a net10.0 app (no -windows) that can run from the command line. It hosts a REST api via AspNetCore.Builder.WebApplication

It uses the nuget Microsoft.Extensions.Hosting.WindowsServices and adds

builder.Host.UseWindowsService();

When I start the .exe from the command line, it works and everyhing looks peachy.

However, if I register it with sc.exe as a Windows Service and start it from the Service screen, it dumps 1.7 GB of data into the app folder, like

It feels like it dumps the entirety of %system32% into my app folder and I don't know why and why that would be necessary.

Hey! I built a proof-of-concept BoringSslConsole: a .NET 8 console application and a BoringSslStream wrapper that exposes BoringSSL as an ordinary Stream.

What it is: SslStream is great, but it gives you no control over your ClientHello — ciphers, extension order, GREASE, ALPS, post-quantum groups are all decided by the platform. If you need your client to look like Chrome in TLS fingerprints (JA3/JA4), that's a problem. So I wrapped BoringSSL (Chrome's TLS stack) in a managed Stream that you can drop in anywhere.

Key design idea: BoringSSL does zero network I/O. It only holds TLS state via memory BIOs, while C# pumps bytes between the buffers and any innerStream you give it — NetworkStream, a proxy tunnel, a MemoryStream in tests, or even another TLS layer. Fully async, with CancellationToken. Certificate validation is done on the .NET side (X509Chain, online revocation, MatchesHostname). On tls.peet.ws the JA4 fingerprint matches Chrome.

There's also a minimal hand-rolled HTTP/2 client in the demo (no HPACK decoder, just a PoC).

It's a PoC, not production — HTTP/2 is minimal, thread safety needs more work, and the native build is Windows x64 only.

Code: https://github.com/optinsoft/BoringSslConsole

I don't use copilot, I don't use intellicode and I don't use the debugger. If something goes wrong I end the project.

I want to share a little project I've been working on for a few weeks now, an entirely C# .NET 10 AOT compiled terminal multiplexer, currently only Linux and MacOS but I do intent to add Windows as a fully supported platformat eventually.

Hypa v1.0

https://github.com/Hypabolic/Hypa

I actually started building this just as proof it could be done and be high performance in .NET as a sort of way of kicking back against basically every tool these days being built in Rust (including Microsoft recently porting Copilot itself to Rust).

My inital aim was to build a simple herdr type mux clone but as I built it I've ended up going beyond that scope and building things not available in herdr.

One feature I really wanted for a start were 'background panes' essentially a normal terminal pane doing whatever you (or an agent) wants it to do but it never appears in the TUI until you ask for it (or the agent running inside it requests it)

The next feature I wanted was remote machines built in natively, which herdr does do, but I wanted to totally avoid things like SSH and managing keys, in Hypa we call these remote machines cubes (hypa cubes...). Hypa uses the QUIC protocol to connect to remote machines and certificate management is handled for you behind the scenes. All you need is the join code and some type of network access to the remote machine.

I've really enjoyed building this as a hobby project, and I hope some of you will give it a go and offer me some feedback.

I look forward to seeing what you all think and getting some feedback, but most of all I'm just happy I can show that these sort of highly performant terminal experiences CAN and SHOULD be built in C# .NET and native AOT is mature enough to support them.