🔥 Excited to announce my new open-source .NET library: High-Performance UUID Implementation!

🚀 Key Features:

Thread-safe operations
Time-based ordering with 48-bit Unix timestamp
12-bit sequence counter for same-millisecond ordering
Extensive benchmarking and performance optimizations
UUIDv7 standard implementation (draft-ietf-uuidrev-rfc4122bis-14)
Built-in serialization support for System.Text.Json and Newtonsoft.Json

⚡️ Perfect for:
Distributed systems
Database primary keys
Secure identifier generation
High-performance applications

🛠 Built with performance and security in mind, this library provides enhanced uniqueness guarantees while maintaining millisecond-precision timestamps.

💻 GitHub: https://github.com/Taiizor/UUID
📚 Documentation: https://uuid.soferity.com

I don’t know about you, but unit tests are the bane of any developer’s existence.

I was kind of shocked to see in an actual description that you can use AI to generate solid front-end and back-end unit tests.

Curious—do people see this as a good thing or a bad thing?

I am senior so actually enjoy doing the unit tests to see my code works.

Why doesn't Microsoft use there own .NET tech, but prefers to use open source technology stack? How can this make developers have confidence in Microsoft? What's more, most of apps they make have a poor experience.

such as:

So I've been working on this Genetic Algorithm Platform, and I originally wrote it in C#, then I ported to TypeScript, then I thought, after all the advancements I made in TypeScript why not port back to .NET and try out the new shiny .NET Core.

But then I was getting frustrated with interface insanity that TypeScript simply doesn't suffer from (recursive generics are nice!).

And so I thought, just so I wasn't barking up the wrong tree I'd do a quick perf test:

C#/.NET Core

using System;
using System.Diagnostics;

namespace GeneticAlgorithmPlatform
{
    public class Program
    {
        public static void Main(string[] args)
        {

            var sw = new Stopwatch();
            sw.Start();

            var n = 0;
            for (var j = 0; j < 10; j++)
            {
                for (var i = 0; i < 1000000000; i++)
                {
                    n += i;
                }
            }

            sw.Stop();

            Console.WriteLine("Elapsed Time: " + sw.ElapsedMilliseconds);
        }
    }
}

.NET Core Result: 19,035 milliseconds.

TypeScript/NodeJS

import Stopwatch from "typescript-dotnet-umd/System/Diagnostics/Stopwatch";
console.log("Elapsed Time:",Stopwatch.measure(()=>{
	let n = 0;
	for (let j = 0; j < 10; j++)
	{
		for (let i = 0; i < 1000000000; i++)
		{
			n += i;
		}
	}
}).total.milliseconds);
// Latest: 10M loops per second.

NodeJS Result: 9,918 milliseconds

What is going on here?

I was certain .NET Core would leave NodeJS in the dust.

There just seems to be a trend of people mucking about without putting in much effort.

The two screens were only for me to get used to React.

It seems the commercial side is putting more faith in React Native for mobile, which is a shame. I was originally a Xamarin.Forms developer and really enjoyed the experience.

I used Expo, so it was easy to test. I know MAUI works on Android at least and u always use a real device anyway.

Yeah it may not have hot reload but u can use expo go just until u test on device.

But I do see the advantage of using dot-net for the back end api for sure.

I am a software engineer working on a .net codebase for the first time professionally. I have prior experience working with rails and node. I saw this post on twitter and it deeply resonated with me. As someone who is new, i understand i may lack the context behind these patterns but i thought to share the post here to learn from those with more experience than i have. What are your thoughts on this.

The hidden cost of enterprise .NET architecture:

Debugging hell.

I've spent 13+ years in .NET codebases, and I keep seeing the same pattern:

Teams build fortress-level abstractions for problems they don't have.

IUserService calls IUserRepository.
IUserRepository wraps IUserDataAccess.
IUserDataAccess calls IUserQueryBuilder.
IUserQueryBuilder finally hits the database.

To change one validation rule, you step through 5 layers.

To fix a bug, you open 7 files.

The justification is always the same:

"What if we need to swap out Entity Framework?"
"What if we switch databases?"
"What if we need multiple implementations?"

What if this, what if that.

The reality:
Those "what ifs" don't come to life in 99% of cases.

I've seen exactly zero projects swap their ORM.

But I've seen dozens of developers waste hours navigating abstraction mazes.

New developers are confused about where to put a new piece of functionality.
Senior developers are debugging through the code that has more layers than a wedding cake.

The end result?

You spend more time navigating than building.

Look, good abstractions hide complexity.
Bad abstractions create it.

Most enterprise .NET apps have way too much of the second kind.

AI crawlers hit your pages and get the full HTML: nav, scripts, Razor-rendered chrome, the lot. They want the content; they parse the wrapper.

I work on a PageSpeed optimization engine (C++ core, exposed to .NET via P/Invoke as an ASP.NET Core middleware). The piece I want to put up for discussion: content negotiation that hands AI crawlers a clean Markdown rendering of the same URL, while browsers keep getting HTML.

It sits in the Kestrel pipeline as middleware. The gate is two ANDed conditions — you opt in, and the request explicitly sends Accept: text/markdown (*/* does not trigger it):

builder.Services.AddPageSpeed(options =>
{
    options.EnableAgentOptimize = true; 
// off by default
});

var app = builder.Build();
app.UsePageSpeed();

When all two hold, the middleware serves the Markdown variant with Vary: Accept, noindex, and Cache-Control: private, so it never competes with your real pages in search. Otherwise the request falls straight through to your normal HTML: non-markdown / non-entitled requests are untouched.

Caveats, since this is r/dotnet and you'll ask:

• Commercial product; production use needs a license (there's a free community tier).

• The markdown negotiation is off by default — explicit opt-in.

• How the (experimental) HTML→Markdown extraction actually works (strips scripts/styles/nav, escapes anything that could forge Markdown structure, respects robots.txt / noai / Google-Extended opt-out): https://modpagespeed.com/blog/serve-markdown-to-ai-crawlers-llms-txt/

Disclosure: I build this. Genuinely curious what .NET folks think: useful, or a maintenance/SEO footgun? And would you want this as middleware at all, or only at a reverse-proxy layer?

I’m learning C# and in the future .NET, and I’ve noticed that every course and source that I watch/read suggest to use Visual Studio. As far as I’ve searched about it, VS is much heavier than VSCode (and also the fact of just runs on Windows). So, what are the advantages in using Visual Studio instead of VSCode?

I would like to use VSCode but I’m a bit concerned about missing any tools or features that just has on Visual Sudio.

Cheers guys 🤙🏻

Hi, this is a blog post I recently finished writing, it came from a conversation I was having with a colleague and I think it will be of interest to the people in this sub reddit. Hope you like it:

Don't be a full stack developer (techgems.net)

I'm a full-stack developer, with some 2 years of experience in JavaScript (nodejs, react and so on).

Is it worth my time to learn .NET? How do jobs pay in contrast to other technologies? If so, what would be a good learning roadmap?

Sorry but unless u working on independent hardware ie a closed system on your house.

Their is no such thing as serverless. Yes u can reduce the requirments you need by creating static web sites.

But these still live somewhere can recrutters stop with the buzz word overkill plz

I just need to vent. I've been a developer for 30 years and an avid .net developer for the past 20 years but sometimes it's just too much.

I have some code that gets ran during an SCCM task sequence in Windows PE mode. It's a simple .NET 4.6 WPF MVVM app that weights in at 1.2MB.

Recently I needed to make another tool for this app so I thought ok lets have some fun and break out Blazor Hybrid on top of .net 9.0 and wpf. I developed the app in a day and it looked beautiful. Except it's 149MB. That's not couting webview2 which WinPE isn't sporting so adding that and I'm at 691MB.

So I boot my PE environment up... mount a drive and start to xcopy the app over to the ramdrive (X:\) and boom insufficient disk space. I was going to try to just run it from the mapped drive but the doco for webview2 says it doesn't work from mapped or unc paths.

Man I generally love where dotnet is going... it's nice to let my UX guy play with Blazor and run my apps on all different kinds of processors and platforms but sometimes it seems like they have really missed the boat with regard to the simple scenarios.

Long live .NET Framework and winforms cause that's probably what I'm going to choose for this app going forward.

Check it out
Stef Heyenrath developed a library that allows you to create variables in C# with multiple types!

Check out his library here:
https://www.nuget.org/packages/AnyOf

Check out his repo and sponsor his work here:
https://github.com/StefH/AnyOf

#csharp #dotnet

I don't want to complain but I'm getting worried about the direction C# is heading. I'm not sure it is the right strategy to cram every feature possible to the language, every year, to the point it becomes confusing and ulearneable. Many features are being introduced that may look nice in a vacuum but not many people are actually asking for. Especially syntactic sugar that may save a couple of keystrokes while the language is just fine doing it "classic" way. This bloat is not going to win over newbies, inexperienced developers like me or professionals from other languages.

For example, why on Earth do we need this? I couldn't even wrap my head around this idea reading it a first few times (yes, I'm tired and not very bright overall), but that means lot's of other people will also find this feature hard to read. What substantial improvement to the language does it offer? Dates on the posts show this feature is levitating around their minds since 2017, and it is on the table for C# 11. We need to cram MORE, let's dig up some old ideas that had been dismissed.

"Just don't use the features you don't want. You can code like it's C# 5". No. This is delusion. I don't want to feel forever amateur and analysis paralysis for not being able to learn all of the language's common features. And I don't mean some deep Jon Skeet level stuff, but just common everyday features that keep adding up in piles. Full stack development is a huge cognitive overload already. Don't do this to my beloved language. Simplicity of Go or even Java now starting to look appealing to me. I'm not alone in this.

Don't get me wrong. I'm all for improvement. But not every "improvement" is actually improvement. Remeber good old times? A C# version introduced Generics. Another version added varand auto-properties. Another version introduced frigging LINQ. And lambdas. And another version introduced async/await. Are there any features of that scale being introduced recently? I can't name a single notable thing since C# 7.

I think C# is really, really good already. Leave it alone. Instead of focusing on bloating the language, they'd rather focus on developing and enriching the .NET Core ecosystem, libraries, cross-platform tooling, etc.

/rant

I’m a backend developer working in .NET, and my company asked me to generate legal documents programmatically from the backend.

• So far, things were manageable. My current approach is:

• I generate a client JSON via an API (contains all client data)

• I store DOCX templates in wwwroot

• The template contains placeholders like {Name}, {Age}, etc.

• I load the DOCX and replace placeholders using values from the JSON

{

"client": {

"name": "Test",

"age": 30

}

}

The Problem

Now I’ve been assigned Last Will & Testament generation.

• ~130 pages long

• Extremely complex

• Hundreds of nested conditions and sub-conditions

• Many paragraphs are conditionally included/excluded

• Same data point affects multiple sections

• Logic depends on combinations like:

  • marital status

  • children / deceased children

  • trusts

  • residue rules

  • survival periods

  • powers of appointment, etc.

At this scale:

• Simple placeholder replacement completely breaks down

• Writing procedural or nested if/else scripting feels unmaintainable

• The document is more like a decision tree than a static template

What I’m Looking For

• Architectural guidance (rules engine, decision tables, DSL, etc.)

• Patterns for large conditional document generation

• .NET-friendly approaches (OpenXML, rule engines, JSON-driven rendering)

• Or even tooling suggestions (legal-doc automation tools, AI-assisted workflows)

At this point, writing manual scripting for this document feels like an impossible task, and I’m sure there must be a better design than what I’m doing.

Any help or direction would be hugely appreciated.

I've been using .NET for years and I love it. That said, there are some things I don't like. Here are my little annoyances (if you have an explanation for why these things are the way they are, please let me know). And share your own annoyances!

1. No variable shadowing, i.e. if you have a variable named 'whatever' in a scope, you can't have another variable also named 'whatever' in a nested scope. This is just baffling. I might be wrong but I think C# is the only major language that forbids this. Why?? It often makes sense to have the same name, e.g. when you have an early 'if' (without 'else') with a 'return' in it and then some code after to handle an edge case and a general case of some operation. It makes sense to have a variable inside and outside of 'if' with the same name, but no, compiler forbids it, and you are forced to add an 'else' block or change the name.

2. No array literals. You always have to write 'new int[] {...}' (or 'new[] {...}' if the type can be inferred). In many other languages there are convenient array literals.

3. Null-safety is inferior to, for example, Dart. It would be really useful to have an equivalent of Dart's 'late' keyword.

4. Making the word 'event' be a keyword was a mistake. Come on, the feature is rarely used (I bet many don't even know that this feature exists), and it's a very popular name for a variable. So you need to prefix it with '@' all the time. Sad...

5. I'm not very familiar with C++, but as far as I know generics there are compile-time generics, whereas in C# they are runtime generics. The difference is that in .NET generics always require adding type parameter constraints, because without them the compiler will allow only stuff like 'ToString' and 'GetType'. In other words, generic code can do nothing unless you explicitly specify the allowed operations via constraints, which is a pain. And it just seems to me like compile-time generics make more sense logically, no?

6. Pointers to managed memory are useless? For those who don't know: you can use the 'fixed' keyword to pin a managed object in place on the heap (so that GC doesn't move it) and take a pointer to its field, but this pointer is only valid inside the 'fixed' block and cannot be used outside of it. What's the point of this? I understand taking pointers to unmanaged memory, but managed? Not an annoyance per se, just confusion.

7. Long names everywhere. 'TaskCompletionSource' instead of 'Completer' or 'Promise'. 'ReaderWriterLockSlim' instead of 'RWMutex'. Etc.

Is it just me, or is Microsoft tooling changing in such a way that a shop spends more time and effort babysitting frameworks and libraries than on domain design & logic? Maybe I'm getting senile or something and it's really just my brain slipping, but it just seems the framework infrastructure has grown more complex and finicky. I won't rule out my brain is simply rotting, but would like second opinions as a sanity check. Thank You!

I will agree that once the framework ducks are all lined up, then domain design can then be the focus, but it takes more effort to get and keep those ducks in line than in the past. MS seems to now emphasize web-scale and "enterprise" rather than rank and file CRUD, and it's thus assumed big teams exist to specialize on tool portions so they can deal with the heftier stack via divide-and-conquer (specialization). Or am I just seeing it all wrong?

Addendum: Others seem to also spend more time on infrastructure-over-domain, it's not just me. They spend more time tinkering with the shop's engine than driving. 🏎️

Looks like we can do funny things with @unoplatform❣️ I just "created" this Tetris game using Uno, you check out the code right here:https://github.com/pictos/UnoTetris

Hey fellow developers,

The world of .NET has been evolving rapidly, and with it, the choices for Object-Relational Mapping (ORM) tools have also grown. Whether you're a seasoned pro or just getting started with .NET development, choosing the right ORM can make a significant difference in your project's efficiency and maintainability.

So, I want to hear from you all: What do you think is the best .NET ORM in 2023?

Please share your experiences, insights, and opinions on which ORM tool you believe is currently leading the pack.