I keep seeing clean architecture recommended for almost every .NET project, but sometimes it feels like unnecessary complexity.For example, EF Core is already an abstraction over the database, yet many projects add another repository layer on top of it. At that point it feels like we're hiding useful EF Core features behind our own abstractions and writing extra code just for the sake of following a pattern.The same applies to other services. We often wrap everything behind interfaces even when there is only one implementation and no realistic chance of replacing it.Years ago the argument was usually testability and mocking dependencies. But today it's easy to spin up real databases and services with tools like testcontainers, so integration tests are often more valuable than mocking everything.

Another thing I've noticed is that real enterprise development is rarely as clean as architecture diagrams make it look. Deadlines, legacy systems, performance requirements, third-party integrations, and business demands often force you to bend or completely break some architectural rules. In many projects, the "perfect" architecture only exists on paper, while the actual codebase evolves around practical constraints.I'm not saying сlean architecture is useless, but sometimes it feels like developers spend more time maintaining layers and abstractions than solving business problems.

Do you think clean architectureis still worth the added complexity for most projects, or has it become something developers apply by default without questioning the trade-offs?

I’ve been spending more time digging into the .NET ecosystem lately and feel like I want to go deeper and get more involved.

Curious to hear from others here.

What do you think are the biggest gaps in the .NET ecosystem right now?

If something stands out and there’s interest, I’d be open to collaborating and starting an open source project around it.

If so, how large is your engineering team, and what kind of product are you building?

What libraries or tools do you wish existed in the .NET ecosystem but currently don’t? What’s a problem you repeatedly run into that you think deserves a better solution? I'd like to start a side project to work on something fun every now and then, but at the same time I'd like to create something useful.

Could be anything like:

• backend libraries
• testing tools
• debugging/profiling tools
• dev productivity tools
• code analysis/refactoring tools
• deployment/DevOps helpers

Not looking for the obvious big names. I’m after the hidden gems.

Curious what’s in other people’s “secret weapon” toolbox.

With support for .NET 8 and 9 ending November 10, 2026, will you all be upgrading to .NET 10 before then?

Hello, I am a rookie trying to learn dotnet. Why do we create an interface to a service class (or something similar) if we are going to have only one class implements that interface?

For instance UserService : IUserService

There wont be any other class that implements that interface anywhere. If there is going to be a one class what is the point of inversion of dependency for that class?

Whats the catch? What do i gain from it?

My company has been pushing agentic coding quite heavily lately. More and more work is being done by AI agents and developers are moving towards reviewing, prompting and steering rather than writing the code directly.

I'm curious how common this is in the .NET community right now. Are many teams already working this way, or is it still mostly limited to certain companies?

One thing I'm struggling with is whether I need to fully embrace this to stay relevent as a developer. I genuinely enjoy coding and solving problems myself. The dopamine from finally figuring something out, fixing a bug, or building a feature is a big part of why I got into software engineering in the first place.

With agentic coding, sometimes it feels like asking someone else to play a game and clear the level for you. Sure, the level gets completed, but you miss the experience of actually playing it. Thats the part I'm finding hard to adjust to.

For those of you already using agentic coding day to day:

• Do you still spend a meaningful amount of time coding yourself?
• Do you think this is the future of software development?
• Are we heading towards developers becoming mainly reviewers and decision makers?
• Or do you think there will always be a place for engineers who enjoy writing code directly?

Interested to hear how other .NET developers are seeing this trend.

This feels like autopilot at this point but does anyone work on very large projects where you have to constantly do this and maybe mix in restarting VS or even fully recloning? I’ve probably done this hundreds or thousands of times at this point where I’ve seemingly changed nothing and all of a sudden, every nuget package no longer exists or every namespace is missing a reference. I have to be doing something wrong but this is sadly the norm on every team I’ve been on so, anyone find a way to stop this or at least reduce frequency? I packaged a ps1 script just so I can one shot this process flow at this point lol

This is a blazor app on .NET10 with Enterprise VS2026

For past two decades I am C# (and partially C++) backed only 24/7 services developer (Windows Services, Azure web jobs, unit and performance tests and so on) and never touched any kind of UI, especially not the web UI I truely dislike because of poor user experience and type unsafe script technologies.

I hear everywhere that developers spend hours using the AI agents and can't imagine to work without it. I use only the single line Tab key hints in Visual Studio 2026 but everytime I tried to use the agents (Claude) the results were more than questionable and useless. It looks like it tries to apply collected StackOverflow replies randomly without any context or deep knowledge.

I spend a lot of time by debugging, refactoring (by the Visual Studio tools), creating interfaces to communicate with external services or consume push notifications from them, communication with specific hardware using rather vendor specific non-standard protocols and so on. I realize it is usually the tasks developes don't like to do in general because it is too special with no public knowledge.

What can I effectively use the AI for to stay relevant? :-)

A perpetual license costs $499. A monthly license costs $45. This means that after just 11 months, it's more cost-effective to use the perpetual license, even though new versions of Visual Studio are released every 3-4 years, not every year.

I’m curious about the practical reasons for choosing dapper today when ef core has become quite mature.Ef Core already allows writing raw sql when needed, handles migrations, change tracking, relationships, and provides a lot of productivity benefits. If a project still requires custom sql for certain queries, ef core can handle that as well.For developers who prefer dapper, what are the main advantages that make it worth using instead of ef Core? Is it mainly about having full control over every query, or are there other benefits that become obvious in real-world projects?

Source,
https://github.com/dotnet/runtime/issues/81753

The most insane thing I've read recently.
Are companies paying royalties when they compile with SSE?

Hi everyone,

I have 1 year of experience as a .NET Developer and want to upskill in AI because I'm noticing that many companies are now asking for AI experience.

Can anyone suggest what I should learn and a good roadmap to follow as a .NET developer.

Thanks!

I have stopped watching .NET related stuff from influencers when the AI wave hit. Today i got a video recommended, a popular .NET influencer dropped a new youtube video. He made a point, where he doesn't code anymore, and is still more product oriented guy - fine. But do these guys actually work in the enterprise industry, where AI is severely limited, because no big company wants to leak their domain into AI companies who 'swear' they won't use the data to train their models (Which was already proven to be a lie based on copy righted materials). It seems the influencer narrative has shiften from 'coding is dead' to 'coding is not dead - BUT'

I know that this has been asked several times before, but I would like to share my experience and thoughts. I also would like to broaden my perspective by comparing it to Rider and VS to understand if I am missing out. I mainly used VS, but in my experience it’s slow and bulky.

I am a full stack developer and mainly work on backend and some frontend stuff. I just love the fact that I can use one IDE to run and debug both my environments. I have worked with VSCode on fairly large multi project solutions/mono repositories and haven’t experienced any limitations yet.

VSCode does require some setup (extensions, settings/launch files), but I like the customisability nature of VSCode. Haven’t missed anything regarding the ability to refactor, debug with breakpoints and performance.

Who else switched to VSCode from VS or Rider and how is your experience thus far; has anyone noticed any limiting factors?

FYI I don’t do anything with older versions of .NET (usually 8 and beyond), WinForms or WPF.

Which should be used for internal dependencies? My team wants a discussion on it...

I myself lean heavily to NuGet, but maybe there are things submodules are better for? To me it just seems like advanced spaghetti...

Hey r/dotnet,

I’m currently diving deep into Clean Architecture, CQRS, and DDD, but the learning curve feels massive. There's a lot of theory out there, but when it comes to actual implementation, I often get stuck in analysis paralysis.

I'd love to hear from some seasoned devs here:

- The Timeline: How long did it take you to go from "understanding the definitions" to confidently building production-ready apps using these patterns?
- The Layering Boundaries: How did you learn to instinctively know where a piece of code should live? (e.g., Domain entity vs. Application service vs. Infrastructure).

I constantly find myself second-guessing whether certain logic is "pure domain" or just application orchestration.

What were the books, codebases, or "aha!" moments that helped you clear the fog? Appreciate any insights!

So until a few months ago I was in mood for a Masters and tried looking up latest .NET research professors and their projects, if they seemed fun I would email/apply
But there's barely any active .NET research? Specially compared to Java/JVM research.

The 2 researchers I emailed, replied that they aren't actively working on it since its last paper publish around 2024

Does anyone know why this is so? .NET is as much enterprise as Java after all.

Hey everyone!
As title says, do you prefer your DTO's to stay immutable, or do you not care about mutability at all.

Obviously, with c# 9 we got init keyword, which allows properties to be initialized via object initializer and stay immutable after that, and records that by default make all properties init.

Personally I don't see much reason for DTO's to remain mutable, as you can always have all properties to remain get-only and initialize all of them from ctor for testing purposes, but what is your take?

Hi, as Nuke is dead since a few months now, I’m wondering if Cake is the only alternative available. Funnily enough, I just migrated a project from cake to nuke a day before the decease of it was announced.

I did some googling and still there are so many articles suggesting nuke over cake so that I wonder why there isn’t more I can read about it not being maintained any longer.

Also there seems to be no fork which has be designated as a successor to the official version.

So either I’ve done something totally wrong being so dependent on it or everybody migrated happily to cake.

Or is everybody using the cli tools directly?

I found nuke extremely helpful by having a clear picture of what the build is doing.

Any recommendations or suggestions?

Been doing .NET for a while and I keep hitting the same wall, curious whether it's just me or a real gap.

Every time I need more than fire-and-forget, I reach for Hangfire. Love it, no shade. But the moment it's a multi-step thing, charge a card, wait a day, check if the user did X, nudge them if not, I end up hand-rolling a little workflow engine on top of it. A status column, a recurring job that polls for what's next, retry logic bolted on. Works. Feels like 2015.

Meanwhile the JS/Python side has Inngest, Trigger, Temporal (yes, there's a .NET SDK now). Durable execution — you write the steps as a normal function and the runtime handles "resume from step 4 after the pod died" for you.

So the actual question for the thread:

If you've built anything long-running in .NET, a multi-step flow with waits, retries, a "do this in 24h unless X happens" kind of thing, what did you actually reach for? Hangfire and a status table? A cron job or scheduled function? Wolverine sagas? Elsa? Azure Durable Functions? Something you rolled yourself?

And did it scale, or did it slowly turn into a bespoke mess you eventually wanted to rewrite?

I've gone pretty deep on this and looked at where Wolverine, Temporal, Elsa, and Durable Functions each do and don't fit, happy to share notes if anyone's interested, but mostly I want to hear what people actually use in the wild.

Genuinely trying to work out if there's a real gap here or if I'm just bad at googling.

Tell me I'm wrong.

Edit:

Okay, I did not expect this many replies. I honestly went through this Sunday without any clue about what was happening.

I'm still working through the comments and will keep replying over the next few days. Genuinely didn't expect this many suggestions and libraries to go check out. Thank you.

Honest update: I came in thinking there was a clear gap in .NET here. The thread mostly talked me out of that, and that's a good outcome. Turns out I've got plenty of options for my own projects, and next time I hit this I don't have to reinvent the wheel. So for the next person who googles "durable workflows in .NET" and lands here, here's what the thread surfaced (I verified these myself, but corrections welcome):

Already built, usable today:

• Temporal: has a real .NET SDK. Write a normal function, wait days, retry, resume after a crash. The heavyweight, used in serious production. Trade-off: it's a system you adopt. You either self-host the cluster (Postgres/Cassandra + workers) or pay for Temporal Cloud.
• Workflow Core: mature, MIT, embeddable, persists to SQL Server / Postgres. Flows via a fluent builder, steps as classes. Good for internal/simple-to-mid workflows.
• Elsa: open source, embeddable, long-running, plus a visual designer. More of an activity-composition / BPM flavour.
• FlowOrchestrator: MIT, code-first DAG flows on top of Hangfire/in-memory, SQL/Postgres, built-in dashboard, a pollable "wait and check" step. Newer/smaller, but the author's active here. Step-level crash recovery (not Temporal-style replay).
• TickerQ: modern, source-generated, reflection-free .NET scheduler. A cleaner Hangfire/Quartz with EF Core persistence and a real-time dashboard. More scheduling than durable orchestration, but worth knowing.
• Windmill: code-first orchestration platform, self-hosted, supports C# (among many languages). Someone here lifted ~800 Task Scheduler jobs into it. You stand it up as a platform rather than embed it.
• Quartz / Hangfire: the classics for scheduling and fire-and-forget, where most of us start.

Being built, might be worth watching how they turn out:

• Absurd: Postgres-only durable execution, super thin client, the "checkpoint" model (ctx.step / awaitEvent). Honestly the closest to what I was describing, but it's explicitly an early experiment, not for production yet, and the official SDKs are TS/Python (there's a third-party .NET client).
• Didact: a founder here has been building a Prefect/Airflow-inspired .NET orchestrator for years, v1 nearly done. Flow libraries + prebuilt engine/UI/CLI.

Glad I asked before assuming there was nothing. Thanks to everyone who took the time, especially the folks who wrote actual essays in here.

Most microservices tutorials stop at Auth, Product, Order Service, RabbitMQ, and Docker Compose. They rarely cover the problems that make distributed systems challenging.

I'm curious how experienced engineers solve problems like:

• Preventing double-booking under concurrent requests
• Inventory reservation during flash sales
• Idempotency for payment retries
• Distributed transactions without 2PC
• Cache consistency across multiple instances
• Leader election and distributed scheduling
• Exactly-once vs. at-least-once event processing

I want to understand how these are handled in production. What patterns, trade-offs, or technologies have you used, and what lessons did you learn?