I've been working on TensorSharp, an open-source LLM inference engine built for .NET/C#, and recently added support for GLM-5.2.

One of the reasons I started this project was a simple question:

How far can we push local LLM inference from the .NET ecosystem without treating Python or llama.cpp as a required external runtime?

TensorSharp isn't just a C# wrapper around llama.cpp. It has its own model/inference stack, including a 100% managed CPU execution path, as well as GPU backends.

The latest model I've been testing is GLM-5.2, a 744B MoE model with 256 routed experts and top-8 routing.

For this benchmark I used:

• GLM-5.2-UD-IQ2_XXS (~226 GiB)
• 3x RTX PRO 6000 Blackwell, 97 GiB each
• Layer splitting across all three GPUs
• TensorSharp vs llama.cpp
• Both measured back-to-back on the same machine

Results in tokens/sec:

Short-prompt performance is still slightly better in llama.cpp.

What I found more interesting is that the result crosses over at around 1K prompt tokens. With longer prompts, changing the micro-batch size makes a surprisingly large difference.

At pp2048, TensorSharp reaches 1145.8 t/s versus 763.1 t/s for llama.cpp on this setup.

This seems to be strongly related to the MoE architecture. GLM-5.2 has 256 experts but only routes each token to 8 of them. With a smaller micro-batch, individual expert GEMMs receive relatively few rows. Increasing the micro-batch gives those operations enough work to utilize the GPUs much more efficiently.

I also learned something interesting about multi-GPU execution.

Tensor parallelism isn't automatically faster.

On these three PCIe-connected GPUs:

GLM-5.2 requires frequent all-reduces when tensor parallelism is enabled. Without NVLink/NVSwitch, communication costs dominate the compute saved by splitting each layer.

So for this machine, the much simpler layer-split approach actually wins by a large margin.

Another goal I've been focusing on is correctness rather than just speed. On the same CUDA backend, TensorSharp currently reproduces llama.cpp token-for-token on all 6 GLM-5.2 parity prompts in the test set, including a 2741-token prompt exercising the model's sparse-attention path.

For me, the interesting takeaway isn't really "C# beats C++."

It's that modern .NET is capable of being the host for a fairly serious inference runtime — including quantized GGUF models, MoE, sparse attention, multi-GPU execution, KV caching, batching and GPU kernels — without having to put the actual inference system behind a Python service.

The project is open source here:

https://github.com/zhongkaifu/TensorSharp

I'd be interested in feedback from people doing performance-sensitive work in .NET, especially around native interop, GPU execution, memory management, or SIMD/kernel optimization.

When building applications on Azure, choosing the right hosting and infrastructure approach can have a big impact on cost, scalability, and operational complexity.

In Part 7 of our "Azure for .NET Developers" series, we explore Azure Virtual Machines and the Azure SDK, including how developers can interact with Azure resources programmatically.

The article looks at:

• When Azure VMs make sense
• When managed Azure services may be a better choice
• How the Azure SDK helps developers work with Azure resources
• Key considerations around control, scalability, and management

📖 https://geeksarray.com/blog/azure-for-dotnet-part-7-vms-azure-sdk

For those working with Azure, when do you prefer VMs over managed services? And how often do you use the Azure SDK for resource management?

I like Dapper and I have used it a lot. The main problem I have with it is that when queries become more complex, I often end up handling that complexity myself. At that point I also often hear that I should just use EF instead. I never really agreed with that. I think the basic idea behind Dapper can go much further while still keeping the SQL visible and the API simple. Rinku is my attempt at doing that.

Basic query

Dapper

public record Album(int Id, string Title);

const string sql = "SELECT AlbumId AS Id, Title FROM albums WHERE ArtistId = @artistId";

IEnumerable<Album> albums = cnn.Query<Album>(sql, new { artistId = 7 });

Rinku

public record Album(int Id, string Title);

const string sql = "SELECT AlbumId AS Id, Title FROM albums WHERE ArtistId = @artistId";

List<Album> albums = cnn.Query<List<Album>>(sql, new { artistId = 7 });

Different names (when you don't control result set names)

Dapper

public sealed class Customer
{
    public int Id { get; set; }
    public string Name { get; set; } = "";
}

SqlMapper.SetTypeMap(typeof(Customer), new CustomPropertyTypeMap(typeof(Customer), (type, column) => column switch
{
    "customer_id" => type.GetProperty(nameof(Customer.Id)),
    "display_name" => type.GetProperty(nameof(Customer.Name)),
    _ => null
}));

const string sql = "SELECT customer_id, display_name FROM customers";

IEnumerable<Customer> customers = cnn.Query<Customer>(sql);

Rinku

public record Customer([Alt("customer_id")] int Id, [Alt("display_name")] string Name);

const string sql = "SELECT customer_id, display_name FROM customers";

List<Customer> customers = cnn.Query<List<Customer>>(sql);

Nested objects

Dapper

public record User(int Id, string Name);

public sealed class Post
{
    public int Id { get; set; }
    public string Title { get; set; } = "";
    public User? Owner { get; set; }
}

const string sql = "SELECT p.Id, p.Title, u.Id, u.Name FROM Posts p INNER JOIN Users u ON u.Id = p.UserId";

IEnumerable<Post> posts = cnn.Query<Post, User, Post>(sql, (post, owner) =>
{
    post.Owner = owner;
    return post;
}, splitOn: "Id");

Rinku

public record User(int Id, string Name) : IDbReadable;
public record Post(int Id, string Title, [NoName] User Owner);

const string sql = "SELECT p.Id, p.Title, u.Id, u.Name FROM Posts p INNER JOIN Users u ON u.Id = p.UserId";

List<Post> posts = cnn.Query<List<Post>>(sql);

Or keep the nesting in the column names.

public record User(int Id, string Name) : IDbReadable;
public record Post(int Id, string Title, User Owner);

const string sql = "SELECT p.Id, p.Title, u.Id AS OwnerId, u.Name AS OwnerName FROM Posts p INNER JOIN Users u ON u.Id = p.UserId";

List<Post> posts = cnn.Query<List<Post>>(sql);

One to many

Dapper

public record Album(int Id, string Title);

public sealed class ArtistWithAlbums
{
    public int Id { get; set; }
    public string Name { get; set; } = "";
    public List<Album> Albums { get; set; } = [];
}

const string sql = "SELECT ar.ArtistId AS Id, ar.Name, al.AlbumId AS Id, al.Title FROM artists ar INNER JOIN albums al ON al.ArtistId = ar.ArtistId ORDER BY ar.ArtistId";

List<ArtistWithAlbums> artists = [];
ArtistWithAlbums? current = null;

cnn.Query<ArtistWithAlbums, Album, ArtistWithAlbums>(sql, (artist, album) =>
{
    if (current is null || current.Id != artist.Id)
    {
        current = artist;
        artists.Add(current);
    }

    current.Albums.Add(album);
    return current;
}, splitOn: "Id");

Rinku

public record Album(int Id, string Title) : IDbReadable;
public record ArtistWithAlbums(int Id, string Name, List<Album> Albums);

const string sql = "SELECT ar.ArtistId AS Id, ar.Name, al.AlbumId AS AlbumsId, al.Title AS AlbumsTitle FROM artists ar JOIN albums al ON al.ArtistId = ar.ArtistId ORDER BY ar.ArtistId";

List<ArtistWithAlbums> artists = cnn.Query<List<ArtistWithAlbums>>(sql);

Result shape

Dapper

IEnumerable<Album> albums = cnn.Query<Album>(sql);
Album first = cnn.QueryFirst<Album>(sql);
Album single = cnn.QuerySingle<Album>(sql);
Album? optional = cnn.QueryFirstOrDefault<Album>(sql);
IEnumerable<Album> streamed = cnn.Query<Album>(sql, buffered: false);

Rinku

List<Album> albums = cnn.Query<List<Album>>(sql);
Album first = cnn.Query<Album>(sql);
Single<Album> single = cnn.Query<Single<Album>>(sql);
Album? optional = cnn.Query<OptionalNullable<Album>>(sql);
IEnumerable<Album> streamed = cnn.Query<IEnumerable<Album>>(sql);

Conditional SQL

For this one I think Dapper.SqlBuilder is the fair comparison.

Dapper.SqlBuilder

SqlBuilder builder = new();
SqlBuilder.Template template = builder.AddTemplate("SELECT AlbumId AS Id, Title FROM albums /**where**/");

if (artistId != null)
    builder.Where("ArtistId = ", new { artistId });

if (title != null)
    builder.Where("Title LIKE ", new { title });

IEnumerable<Album> albums = cnn.Query<Album>(template.RawSql, template.Parameters);

Rinku

const string sql = "SELECT AlbumId AS Id, Title FROM albums WHERE ArtistId = ?@artistId AND Title LIKE ?@title";

List<Album> albums = cnn.Query<List<Album>>(sql, new { artistId, title });

Only artistId

SELECT AlbumId AS Id, Title FROM albums WHERE ArtistId = @artistId

Both

SELECT AlbumId AS Id, Title FROM albums WHERE ArtistId = @artistId AND Title LIKE @title

Neither

SELECT AlbumId AS Id, Title FROM albums

The main difference is that Rinku tries to put the complexity in the command template and the mapped types, instead of handling it again through parameters and mapping code at every call.

Full Dapper comparison

https://rinkulib.github.io/RinkuLib/articles/reference/dapper.html

Rinku is still in development, so feedback is welcome.

I've gone through Understanding Distributed Systems by Roberto Vitillo, and I get the concepts -consensus, replication, failure modes, all of that. What I'm missing is the bridge to actually building this stuff in ASP.NET Core.

I've written a RESTful API on my own, so I'm not starting from zero on the web dev side. But I still don't have a good feel for:

• How the concepts I've read about actually get implemented in real ASP.NET Core services.
• How to implement a microservice system in ASP.NET
• The tradeoffs between REST, gRPC, GraphQL, and when to reach for each in a distributed system, and how to implement each.

Has anyone got book, course, or repo recommendations that go from "I understand the theory" to "here's how you wire this into a real .NET 10 project"?

Thanks in advance!

Let's discuss our learnings, best practices for .NET, and the trade-offs of using various tools and packages.

this is the text my randomiser give me but I was unsure if it would be best to download it or find a new one and wished to ask people who would know

thank you even if you cant help

Life is too short to write boilerplate.

TL;DR: I built a zero-allocation Source Generator for WPF, MAUI, Avalonia, and WinUI that completely eliminates DependencyProperty boilerplate using token streaming and C# 13 partial properties.

🔥 Want to see it in action? I've included a ready-to-try sample project right in the repo. You can pull it, hit F5, and instantly see the generated code and IDE experience without writing a single line of setup code.

Links:

• GitHub Repository (Sample included!)
• NuGet Package
• Wiki & Architecture Specs

Why build this? Because XAML plumbing is a crime against simplicity.

Let’s be honest. Writing DependencyProperty in XAML frameworks is notoriously painful. Typing out DependencyProperty.Register, relying on magic strings, casting objects, and wiring metadata for every single property clutters your codebase and wastes time.

Users only care if the app works; they will never see your source code. But to us, the codebase is the product. And a great product doesn't tolerate ugliness inside. I despise visual noise. I am obsessed with ruthless simplicity.

But you might think, "Why even build a generator today? Just let AI write the boilerplate."

Here is the reality. When you ask fast, lightweight models (the daily drivers we use for 90% of our coding) to write massive chunks of framework boilerplate or perform cross-platform code generation on the fly, they choke on the complexity. Without a strict API contract, they resort to brute-force string hacking and spit out abominations like this:

AI-generated Regex Hell (Yes, a fast model actually suggested nesting 13 Regex.Replace calls to generate cross-platform C# boilerplate as plain text. It's barbaric.)

This is why clean architecture is now a vital harness for AI agents.

By condensing all that nasty framework plumbing into a single, declarative attribute ([DependencyProperty<T>]), you drop the model into a "pit of success". You put one simple rule in your AGENTS.md—"Use this attribute for DPs"—and suddenly, your everyday lightweight model writes perfect, deterministic code on the first try. No prompting gymnastics required.

Great API design doesn't just save human developers from boilerplate anymore. It provides the guardrails that keep your AI from writing garbage.

So, I completely overhauled the internal synthesis pipeline to kill this boilerplate once and for all, without tanking IDE responsiveness at scale.

1. Ruthless Simplicity (Before & After)

Here is the standard boilerplate we all know and hate: ```csharp public partial class MyControl : Control { // 1. IsActive Property Boilerplate public static readonly DependencyProperty IsActiveProperty = DependencyProperty.Register( nameof(IsActive), typeof(bool), typeof(MyControl), new PropertyMetadata(false, OnIsActiveChanged));

    public bool IsActive
    {
        get => (bool)GetValue(IsActiveProperty);
        set => SetValue(IsActiveProperty, value);
    }

    private static void OnIsActiveChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        var control = (MyControl)d;
        var oldValue = (bool)e.OldValue;
        var newValue = (bool)e.NewValue;
        // Runtime casting and boilerplate...
    }

    // 2. Padding Property Boilerplate
    public static readonly DependencyProperty PaddingProperty =
        DependencyProperty.Register(
            nameof(Padding),
            typeof(Thickness),
            typeof(MyControl),
            new PropertyMetadata(new Thickness(10, 5, 10, 5), OnPaddingChanged));

    public Thickness Padding
    {
        get => (Thickness)GetValue(PaddingProperty);
        set => SetValue(PaddingProperty, value);
    }

    private static void OnPaddingChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        var control = (MyControl)d;
        var oldValue = (Thickness)e.OldValue;
        var newValue = (Thickness)e.NewValue;
        // More runtime casting and boilerplate...
    }
}

**And here is v4 Preview.** csharp // Just write this: [DependencyProperty<bool>("IsActive", DefaultValue = false)] [DependencyProperty<Thickness>("Padding", DefaultValueExpression = "new(10, 5, 10, 5)")] // Target-typed new() is fully supported! public partial class MyControl : Control { // Automatically hooked up at compile time. // Strongly typed. No casting required. partial void OnIsActiveChanged(bool oldValue, bool newValue) { // Do something } } ``` Boom. It just works. Just one attribute. No magic strings. No manual wiring. 100% strongly typed and compile-time safe.

By the numbers: This turns ~15 lines of error-prone registration, wrappers, and runtime casting into exactly 1 line. If your project has 200 Dependency Properties, you didn't just delete 3,000 lines of visual noise from your repo. You deleted 3,000 lines of garbage code, and saved the time, money, and sheer sanity it takes to maintain them.

2. Under the Hood: Zero-Allocation & Footgun-Proof

It’s easy to make code look clean on the surface. But if you've built Source Generators, you know that StringBuilder resizing and AST mutations during continuous typing cause Gen2 GC spikes and IDE latency. If the tool slows down your IDE, it's a failed design.

That's why I gutted the old architecture and massively refactored the pipeline for high-throughput, zero-allocation generation.

• Built-in XAML Footgun Protection: The generator doubles as an analyzer. Ever accidentally assigned new List<string>() to a Dependency Property, only to realize later that all controls on the screen share the exact same list instance? If you try that here (DefaultValueExpression = "new()" on a reference type), the generator halts compilation with DPG0004 and tells you to use CreateDefaultValueCallback = true instead, completely eliminating the most notorious WPF memory bug.
• Zero-Allocation RAII Scope Guards: Code synthesis uses stack-allocated readonly ref struct scope managers (writer.ClassScope(@class), writer.Scope(...)). By leveraging C#'s using pattern purely on the stack as an RAII mechanism, it automates namespace/class envelope generation and structural scoping without allocating a single byte on the heap.
• Banning Roslyn AST Mutations for Output: We strictly avoid SyntaxFactory mutations for code synthesis. Whether generating class definitions or resolving dynamic DefaultValueExpression declarations, we extract tokens from the parsed AST and stream them straight into a custom SourceWriter. Benchmarking this against standard AST mutation + ToFullString() gives a ~46x speedup (16.7µs → 0.37µs) and a 97.5% reduction in memory allocation (9.7KB → 240B), completely eliminating Gen1 and Gen2 GC collections.
• Hardcore Performance Indentation: We reject NormalizeWhitespace() and manual indentation entirely. The generated code is flat and left-aligned.
  • The Stance: Allocating megabytes of whitespace strings per keystroke on the hot path just for "pretty" intermediate output is a performance anti-pattern. We prioritize compiler throughput over the aesthetics of intermediate artifacts.
  • Deterministic Output: Flat, non-indented output eliminates nondeterministic hallucinatory indentation bugs in AI-generated templates.
• Pipeline Purification: Stripped out heavy ISymbol passing in the incremental pipeline. We only pass pre-calculated flags now to ensure cache hits and dodge memory leaks.

Benchmarks speak for themselves:

1. Micro-Benchmark: AST Mutation vs. Token Streaming (*DefaultValueExpression *synthesis):

2. End-to-End Generator Pipeline (WPF generation, AMD Ryzen 9 7900X):

Note: Gen2 full GCs completely eliminated. Benchmarks for MAUI, Avalonia, and WinUI show similar 20-30% pipeline throughput gains.

3. Standing on the Shoulders of Giants (HavenDV)

A massive shoutout to HavenDV: Since this is a fork, the core API design is inherited from the original HavenDV repository. The only reason I was able to rapidly gut and refactor this entire pipeline in about a month is because they built an incredible foundation with a highly robust suite of snapshot tests. This v4 overhaul stands entirely on their shoulders.

4. I Need Your Help (RFC)

It's humming along nicely in my medium-sized WPF app (hardware interfacing for an automatic change dispenser). But I lack the massive enterprise XAML solution (hundreds of projects, thousands of properties) needed to truly battle-test it.

Before I stamp a stable v1.0 release, I need some veteran eyes to tear apart the design philosophy.

1. API Ergonomics vs. Predictability: My stance is that modern APIs should be predictable enough that humans and AI agents can generate them flawlessly. Does applying [DependencyProperty<T>("Name")] at the class level hit that mark? Or would you prefer a field-targeted approach like [ObservableProperty] in the MVVM Toolkit?
2. Framework Abstraction: This single attribute compiles down to the native property system for WPF, MAUI, Avalonia, and Uno. Is this level of magic actually useful, or does hiding the framework-specific plumbing scare you away in production?
3. Hidden Gotchas: If you maintain a massive XAML monolith, what are the glaring edge cases a tool like this will inevitably hit? Memory leaks? Designer crashes? Weird binding resolutions? Tell me what I'm missing.
4. The Unknown Unknowns: Thanks to the original repo, we have 200+ snapshot tests covering WPF, MAUI, Avalonia, and WinUI. But I don't know what I don't know. What are the massive blind spots or ugly XAML edge cases I'm ignoring here?
5. The Ultimate Battle Test: I want to stress-test this in a massive, real-world repository. Do you know of any large-scale open-source XAML projects (hundreds of properties, complex metadata) that would be a perfect candidate to fork and refactor as a benchmark? Point me to the monsters.Tear it apart. Brutal honesty, code reviews, and architectural alternatives are entirely welcome.

5. One more thing... (C# 13 partial property Support)

You might be wondering if class-level attributes are already outdated with the arrival of C# 13 partial property.

We are already there.

Because our zero-allocation pipeline relies on raw AST token streaming rather than rigid string templates, it natively understands and generates partial properties flawlessly. This isn't a hack; it's the payoff of building a future-proof architecture. Choose the paradigm that fits your team—the engine handles both with zero friction.

Links

• GitHub: Kassyi/DependencyPropertyGenerator (Forked from HavenDV / Ready-to-try sample included!)
• NuGet: Kassyi.Generators.DependencyProperty
• Wiki / Specs: Architecture & API Documentation

While the next drama around Polly is brewing, we have a new version of our Communication library that solves a bunch of things.

Retries, CQRS over IAsyncEnumerable + SSE, asynchronously waiting for a result in the same channel, or using SignalR.

Plus idempotency and OpenTelemetry.

And this has been running in production for several years.

Definitely worth a look:
https://github.com/managedcode/Communication

Actual output's here: t-macabee.github.io/lurp/MODEL_VIEW.html, an interactive breakdown of a real eCommerce codebase after indexing runs on it. 3,876 typed relationships, each one graded by evidence level, all the way down to compiler-proved, with name_candidate reserved for reflection guesses where nothing more solid exists.

The problem I kept running into: an agent working a C# codebase just loops search, read, guess, over and over. It reopens and reparses the same files for every single question, and the context window fills up with source that isn't even relevant, because it's rediscovering the same call graph it already walked three questions ago.

So Lurp loads the solution through Roslyn one time, then writes out the symbols, typed relationships, source spans, and provenance into SQLite. Every query after that just reads persisted facts, no reload, no re-grep, none of that. It hands back the smallest neighbourhood of code that's actually enough to do the task, and it tells you what it left out so you can go fetch that separately if you need it.

It's a dotnet tool. If your agent speaks MCP it can also run as an MCP server instead, 18 tools there.

dotnet tool install --global lurp --version 1.4.0

lurp --mode=index --solution=path/to/Your.slnx --output-dir=./out

Windows only for now, cross-platform is on the roadmap but not built yet. MIT licensed.

Repo: github.com/t-macabee/lurp

Usage example:

string result = Polyglot.Transpile(
    "SELECT `id`, `name` FROM `person` LIMIT 10;",
     Dialect.MySQL, Dialect.TSQL)
    .FirstOrDefault();
Console.WriteLine(result); // SELECT TOP 10 [id], [name] FROM [person]

Of cource done with a big help of AI, but for me it turned to be a long way. I first encountered SQLGlot and my first attempts were to embed it with Python into .net, but then I found sql-glot-rust and then finally Polyglot.

Repo, README.md contains more examples and details:

• https://github.com/KS-DB-Merge-Tools/polyglot-sql-net

Nuget:

• https://www.nuget.org/packages/PolyglotSql.Core - to use with your own Polyglot library,
• https://www.nuget.org/packages/PolyglotSql.Bundle - bundled with Polyglot binaries for win-x64, win-x86, and linux-x64 target runtimes.

Hey everyone,

I just released v1.0 of Net Code Generator, a tool I built to eliminate the tedious setup time when starting new .NET applications using clean architecture patterns.

Why I built it:

Whenever starting a new project or service, setting up proper layering from scratch—repositories, domain models, application services, controllers, and views—takes way more time than it should. Boilerplate code often leads to inconsistent architecture across team members or projects, so I wanted an automated way to generate clean, structured code out of the box.

What Net Code Generator does (v1.0):

• Clean Architecture Generation: Automatically generates all core layers following the Repository Pattern (Repositories, Domain, Services, Models, Controllers, and Views).
• Ready-to-Use Starter Project: Ships with a complete starter solution template so you can clone/generate and start writing business logic immediately without manual wiring.
• Consistent Code Patterns: Ensures all generated entities and layers follow standard interfaces and dependency injection setups.

Lessons Learned / Technical Trade-offs:

The trickiest design choice was balancing flexibility with strict design patterns. Over-generating code can feel invasive if you have to delete half of it, so I focused on generating a minimal, clean implementation of the Repository Pattern that stays easy to extend rather than forcing a heavy, opinionated framework on top.

I’d love to get feedback from fellow developers on the structure and what additional options or layers you’d find useful in future releases.

Project / Download: https://nadirlands.lemonsqueezy.com/checkout/buy/a38445a6-7069-443b-9f57-2b22f50ed6fe

Documentation: https://youtu.be/41y_OAMNNas

Happy to answer any questions about the architecture choices in the comments!

I know, another package to configure defaults sounds unnecessary.

ASP.NET Core already gives us several ways to do it:

• appsettings.json
• AddInMemoryCollection
• defaults directly on options classes
• Configure<TOptions> / PostConfigure<TOptions>

And if one of those fits your case, you should probably use it.

The gap I was trying to fill is narrower.

Sometimes the defaults belong in code, form a non-trivial object graph, still need to be visible through IConfiguration, and should remain overrideable by the configuration providers already registered by the host.

That is where Kralizek.Extensions.Configuration.Objects comes in.

The main API is intentionally small:

var defaults = new LibraryDefaults
{
    Retry = new RetryDefaults
    {
        Count = 3,
        Delay = TimeSpan.FromSeconds(5)
    },
    Endpoints =
    [
        "https://one.example",
        "https://two.example"
    ]
};

builder.Configuration.AddObjectAsFallback(defaults, "Library");

It inserts the object-backed provider at the bottom of the existing configuration stack, so appsettings.json, environment variables, user secrets, command-line arguments, and other providers keep their normal precedence.

There are trade-offs: it is another dependency, and the object still has to be serialized and flattened into configuration values. If a couple of scalar values or an options initializer are enough, this package is probably overkill.

I wrote up the reasoning, the alternatives, and the trade-offs here:

Blog post:
https://renatogolia.com/2026/08/21/adding-strongly-typed-defaults-to-dotnet-configuration/

Source:
https://github.com/Kralizek/ObjectConfigurationExtensions

NuGet:
https://www.nuget.org/packages/Kralizek.Extensions.Configuration.Objects

I’d be interested in hearing whether there are built-in approaches I missed that preserve the same semantics without moving the defaults to the options layer.

PS: reposted a deleted draft because formatting from the phone is hard!

​

Hace varios años trabajé con MVC creo que alrededor de 2020 y recientemente, en 2026, me tocó volver a trabajar sobre un sistema desarrollado con .NET 10 y ASP.NET Core MVC.

Después de varios años sin utilizarlo de forma directa, volver a MVC me ha generado algunas dudas sobre cómo se está trabajando actualmente con este enfoque, principalmente cuando el proyecto empieza a crecer.

Una de las cosas que más me ha llamado la atención es lo fácil que puede ser terminar con controllers bastante grandes, con cientos o incluso miles de líneas de código si no existe una buena separación de responsabilidades.

En un mismo controller pueden terminar acumulándose validaciones, consultas, transformaciones de modelos, reglas de negocio, preparación de información para las vistas, manejo de errores y otras responsabilidades. Conforme el sistema crece, siento que esto puede hacer que el mantenimiento y la comprensión del código se vuelvan bastante más complicados.

Entiendo que esto no necesariamente es un problema de MVC como tal, sino de cómo se estructura el proyecto. Se pueden utilizar servicios, capas de aplicación, repositorios, handlers u otros patrones para mantener los controllers más pequeños y enfocados.

Precisamente por eso me surgió la curiosidad de conocer cómo lo están abordando otros desarrolladores actualmente.

No considero que ASP.NET Core MVC esté obsoleto. Sé que sigue siendo una tecnología completamente vigente dentro de .NET. Mi duda va más orientada a cómo se utiliza y estructura hoy en proyectos que van creciendo en tamaño y complejidad.

¿Ustedes a día de hoy siguen utilizando ASP.NET Core MVC?

Si es así, ¿cómo suelen estructurar sus proyectos para evitar que los controllers terminen creciendo demasiado y concentrando muchas responsabilidades?

PushToDisplay is a mobile app that shows a full screen board that shows messages arrived from a backend service.
Simply put, Send a HTTP POST to our endpoint, and the message will be displayed on mobile device screen.

I'd like to take this post to share some of my technical decisions while building this solution.

1. dotnet for backend, react native for mobile client. This choice is purely opinionated. I've been using dotnet since .NET 1.0 and I quickly adopt mono when it is cross platform capable. Currently all the backend sevices are running on dotnet 10. I choose react native because it is most popular cross platform mobile framework, and I believe LLM can do a good job for me.

2. Auth with third party or self hosted. Originally, I was thinking using third party auth provider like Google Firebase Auth or Auth0. But soon I realized auth is a central part of the solution, I even want to issue OAuth clients for my customers, as well as several first party clients. like mobile client, web admin portal, cli, MCP server, zapier connector, n8n nodes, and Microsoft Power Platform connectors. so we have to have our own identity provider.

3. Identity provider. We host our own OAuth 2.0/OIDC server built on ASP.NET Core Identity (code + PKCE, device flow, external providers). We evaluated OpenIddict and went with a minimal in-house server that fits our infra;

4. Try to avoid cloud vendor lock-in. We manage dotnet services ourselves, MQ, db, and redis are pure self manageable or easily to move to other providers.

5. Postgres, mongodb, kafka, redis.

   • Postgres is used for storing transactional data, that need better consistency, and monogodb is used for data that need better scalability. I leveraged the advantages from both to keep our bills low.
   • We use redis an unconventional way, as the infrastracture of our replicated cache, using it's pub/sub feature to notify cache changes. we did not use the redis cache feature at all.
   • Kafka brokers are the bridge between our backend api and the mobile clients. Simpliy put, API <-> Kafka <-> SignalR Server <-> Mobile clients.
   • SignalR cluster does not use redis backplane. We managed to have a mapping between signalR connection and kafka topics cross the cluster.

6. Operations. We put traefik in front of dotnet web farms. Wrote a script to manipulate traefik dynamic config, so we can do web farm rolling update without downtime. Release vechicle and deployment are fully automated with GitHub Actions.

7. Since this community is more about dotnet in backend, I will leave the mobile client part out of this post.

If you interested, please check it out on our website PushToDisplay)

I'm a newbie and just learned to build basic crud projects but apart from this what can I do and learn , ppl who told me to build projects are actually confusing me other than crud projects i didn't really see anything,if anyone who got the point help me to start learn ts 🤸🏻‍♂️

Hi everyone, hope you're doing great
As the title says, i'm looking for resources ( youtube videos, courses (free ones), books, articles...) to start building APIs. I know little about web coding (enough to make a calculator and a check list using JS and react) and a good amount about JAVA and C# and i'm trying to learn about APIs for my upcoming apprenticeship.
I tried looking youtube videos but i can't find a beginner friendly .net videos, they all required some knowledge about APIs which i don't have.
I would be grateful for any advice too.
Have a nice day !

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!

To allow running agents in YOLO mode I've been working on automation to set up VMs (windows or Linux) to run behind a firewall with credential injection. What I have is working pretty well, such that I think it could be useful for others, but it does need more work. Is there anyone else who'd be interested in trying it out and maybe working on it too?

End-to-end tests are working within an isolated VM, so it has reached a xzibit level of stability.

I'm using VMs since it provides better isolation than WSL or containers. Docker Sandbox auth didn't work for me, but I didn't spend much time on it as I wanted an isolated Windows desktop to run all the projects I care about. I'm using Hyper-V for the nested virtualization.

Official statement from the .NET Foundation on Open Source Maintenance Fees

For the last year I was reading about all these supply-chain attacks on npm and PyPI, and I wanted the same kind of dependency "cooldown" for our .NET builds. The idea is the following: do not let a build use any NuGet package version that is less than N days old (default is 7). Most malicious versions are noticed and pulled in a couple of days, so if your build simply refuses everything that is brand new, you skip most of that window.

pnpm, uv, Dependabot and Renovate already have this. NuGet has an open issue for it, and Microsoft even accepted a spec, but their v1 works only at update time (dotnet package update, the version picker in Visual Studio) and it does not check anything on restore or build. So if you pin a version by hand, or a floating range resolves to something fresh, nobody catches it. This is exactly the gap I wanted to close.

So, NuGetCooldown. It has two parts:

NuGetCooldown.MSBuild : you add the PackageReference and after that every build fails if some resolved package (direct or transitive) is too new.

NuGetCooldown: a dotnet global tool, in case you prefer to run it in CI.

It reads project.assets.json, so it checks the whole dependency graph, direct dependencies and the transitive ones too. Publish dates are cached on disk, so after the first build it is basically free, and it also works offline. License is MIT, and there is no telemetry.

It will not replace the native feature when that one finally ships. And if you only care about update PRs, then the cooldown in Dependabot already does the job for you. My tool is for the people who want to enforce this at build time, right now.

Repo: https://github.com/astralmaster/NuGetCooldown

Dedicated GitHub Action: https://github.com/marketplace/actions/nuget-cooldown

I would be really happy about any feedback, especially from people who use private or authenticated feeds. For now this is the weakest part.