DEV Community: Diego Teles

Porting Zod to C#: ZodSharp – A Zero-Allocation, High-Performance Schema Validation Library for .NET

Diego Teles — Sun, 14 Dec 2025 00:05:05 +0000

Porting Zod to C#: ZodSharp – A Zero-Allocation, High-Performance Schema Validation Library for .NET

As a .NET developer, I’ve long been frustrated by one persistent pain point: most validation libraries rely heavily on reflection, leading to slow performance and constant allocations. Whether it’s validating API inputs, forms, or data pipelines, that overhead adds up — especially in high-throughput scenarios.

Then I discovered Zod — the gold standard for schema validation in the TypeScript world, created by colinhacks. Its fluent API, full type inference, excellent error messages, and zero-dependency design made it feel like magic. But there was nothing quite like it in C#.

So I decided to change that. I built ZodSharp — a complete, from-scratch rewrite of Zod tailored for modern .NET, with a relentless focus on performance, zero-allocation, and developer experience.

This post is the story of that journey and why ZodSharp might just become your new go-to validation library.

Why Zod Became the Standard in TypeScript

Zod dominates the JS/TS ecosystem for good reason:

Fluent, chainable API that's a joy to write
Full type safety with automatic inference
Powerful composition for complex schemas
Rich transforms and refinements
Clear, structured error reporting
Zero runtime dependencies

In .NET, we have solid options like FluentValidation, but they lean on reflection and expressions — great for flexibility, but costly in performance-critical paths.

ZodSharp brings that same elegant developer experience to C# — without the allocation tax.

Not a Simple Port — A Performance-First Rewrite

While staying faithful to Zod’s public API and semantics, nearly every internal detail was re-engineered for .NET’s strengths.

Zero-Allocation: The Core Design Goal

The #1 priority: validation should produce zero garbage in hot paths.

Reflection-based validation creates objects, closures, and temporary collections on every call. ZodSharp eliminates that entirely.

Key techniques:

Validation rules as structs

   public readonly struct MinLengthRule : IValidationRule<string>
   {
       private readonly int _min;
       public MinLengthRule(int min) => _min = min;

       public bool IsValid(in string value) => value.Length >= _min;
   }

Immutable collections with minimal overhead (ImmutableArray, ImmutableDictionary)
ValidationResult as a struct — no heap allocation on success or failure
ArrayPool for any temporary buffers
Manual loops instead of LINQ in performance-critical sections
Span and ReadOnlySpan for string operations with zero copies

Fluent API — As Close to Zod as Possible

The API feels instantly familiar to Zod users:

// Almost identical to Zod TS
var schema = Z.String()
    .Min(3)
    .Max(50)
    .Email()
    .Trim()
    .ToLower();

Object schemas:

var userSchema = Z.Object()
    .Field("name", Z.String().Min(1))
    .Field("age", Z.Number().Min(0).Max(120))
    .Field("email", Z.String().Email())
    .Build();

Transforms, refinements, unions, optionals, literals — all supported.

Source Generators & DataAnnotations Integration

One of the biggest .NET-specific wins: compile-time schema generation.

Decorate a class with [ZodSchema] and use standard DataAnnotations — ZodSharp generates a static schema at build time:

[ZodSchema]
public class User
{
    [Required, StringLength(50, MinimumLength = 3)]
    public string Name { get; set; } = string.Empty;

    [Range(0, 120)]
    public int Age { get; set; }

    [EmailAddress]
    public string Email { get; set; } = string.Empty;
}

// Usage
var result = UserSchema.Validate(new User { ... });

No runtime reflection needed.

Project Architecture Overview

ZodSharp/
├── src/ZodSharp/
│   ├── Core/                → Interfaces, base classes, results, errors
│   ├── Schemas/             → String, Number, Object, Array, Union, etc.
│   ├── Rules/               → Struct-based validation rules
│   ├── Expressions/         → Compiled validators via Expression Trees
│   ├── Json/                → Newtonsoft.Json integration
│   ├── Optimizations/       → Zero-allocation helpers
│   └── Z.cs                 → Static factory (Z.String(), Z.Object(), etc.)
├── src/ZodSharp.SourceGenerators/
│   └── ZodSchemaGenerator.cs → [ZodSchema] source generator
├── example/                 → Full usage samples
└── README.md

Rough Performance Wins

Early benchmarks show dramatic improvements over typical reflection-based validation:

Scenario	Reflection-Based	ZodSharp	Gain
Simple string validation	~0.15 ms	~0.01 ms	~15× faster
Complex object validation	~0.8 ms	~0.05 ms	~16× faster
Allocations per validation	Multiple	Zero	Eliminated

The gap widens under load.

Practical Use Cases

ZodSharp shines anywhere validation performance matters:

High-throughput APIs (REST, gRPC, GraphQL)
Microservices with frequent input validation
Real-time systems
Data ingestion pipelines
Desktop/mobile apps with complex forms
Anywhere you want Zod-like DX without the runtime cost

What’s Already Implemented

Fluent schema building
Full primitive support (string, number, boolean, array, object, union, literal)
Transforms (.Trim(), .ToLower(), etc.)
Refinements (custom validation)
Optional / nullable wrappers
Discriminated unions
Lazy/recursive schemas
Source generator with DataAnnotations
Newtonsoft.Json integration
Advanced string rules (.Url(), .Uuid(), .Email(), .StartsWith()...)
Advanced number rules (.Positive(), .MultipleOf(), .Finite()...)

What’s Next?

Public benchmark suite
ASP.NET Core model binding integration
Entity Framework validation hooks
More JSON serializer support (System.Text.Json)
Enhanced error formatting
Community contributions!

Final Thoughts

Building ZodSharp was incredibly rewarding. It wasn’t just about bringing Zod to C# — it was about solving a real, widespread pain in the .NET ecosystem: fast, type-safe, zero-overhead validation.

If you’ve ever groaned at reflection slowdowns or wished for a more modern validation experience in C#, I hope you’ll give ZodSharp a try.

GitHub: https://github.com/guinhx/ZodSharp

NuGet: https://www.nuget.org/packages/ZodSharp

Original Zod: https://github.com/colinhacks/zod

Feedback, stars, issues, and PRs are very welcome! Let me know — have you felt the reflection validation pain? What would make you switch?

Thanks for reading! 🚀

Tags: #dotnet #csharp #validation #zod #performance #opensource #typesafety

Porting Mistreevous to C#: A High-Performance Behavior Tree Library for Modern .NET

Diego Teles — Sun, 14 Dec 2025 00:02:40 +0000

Porting Mistreevous to C#: A High-Performance Behavior Tree Library for Modern .NET

When I started building dedicated servers for multiplayer games, I ran into a very real problem: server-side entities needed rich, structured, and consistent AI behavior. In single-player games, the client usually handles this. In modern multiplayer titles with authoritative servers, the AI must run server-side — and that completely changes the performance and architectural demands.

Behavior Trees were the obvious choice. I fell in love with Mistreevous, a beautifully designed TypeScript library by nikkorn, thanks to its clean, modular, and highly expressive DSL. The challenge? Bring that same elegance to the .NET world — but optimized for the harsh reality of server tick loops.

This post is the story of that port: MistreevousSharp, a ground-up rewrite focused on zero-allocation, predictability, and raw performance.

Why Behavior Trees?

Behavior Trees shine in games, robotics, simulations, and any agent-based system because they offer:

Hierarchical composition
Excellent readability and intent clarity
Strong modularity
Easy debugging
Predictable execution order

For multiplayer servers specifically, they deliver:

Extremely low cost per tick
Deterministic outcomes
Clean separation of logic and state
Horizontal scaling across hundreds of entities

Mistreevous already nailed the design in TypeScript. The C# version had to be just as expressive — but truly server-ready.

Why Mistreevous Specifically?

The original Mistreevous stands out with:

A fluid, readable DSL
Well-defined node types
Simple parsing
Full JSON compatibility
An intuitive API

But it was built for a JavaScript runtime. In .NET (especially .NET 9 and .NET Standard 2.1), we have far more control over memory and performance.

The goal: keep the spirit and compatibility, but eliminate allocations and make it scream on the server.

Not Just a Port — A Performance-Focused Rewrite

While staying 100% semantically compatible with the original, almost every internal detail was re-engineered.

Zero-Allocation: The Core Principle

The primary objective was simple: calling Step() (one AI tick) must generate zero garbage.

On a server with dozens or hundreds of entities ticking 30–60 times per second, even tiny repeated allocations become a GC nightmare.

Key techniques applied:

Eliminated LINQ in hot paths

No enumerators, closures, or temporary collections.
Reusable buffers and pools

Pre-allocated, thread-safe lists reused across ticks.
Manual Span-based parsing

Character-by-character processing instead of Split() or regex.
No captured closures

Avoided delegate allocations wherever possible.
Classic for loops

Bypassing enumerator overhead.
Compact node design

Fixed arrays, lightweight structs, minimal fields.

Full DSL and JSON Compatibility

A non-negotiable requirement: any tree from the original Mistreevous must work unchanged.

Example DSL:

root {
    sequence {
        action [CheckHealth]
        selector {
            action [Flee]
            action [Fight]
        }
    }
}

MistreevousSharp supports:

Identical SUCCESS / FAILURE / RUNNING semantics
Same guard evaluation
Subtree references
Decorator behavior
Execution order

You can literally copy-paste trees between TypeScript and C# projects.

Project Architecture Overview

The repository is organized to mirror the conceptual structure while making optimizations explicit:

MistreevousSharp/
├── assets/                      → Images and thumbnails
├── example/                     → Full working demo (MyAgent + Program.cs)
├── src/Mistreevous/
│   ├── Agent.cs
│   ├── BehaviourTree.cs         → Core execution engine
│   ├── BehaviourTreeBuilder.cs
│   ├── MDSLDefinitionParser.cs  → Zero-alloc DSL parser
│   ├── Nodes/                   → Full node hierarchy
│   │   ├── Composite/ (Sequence, Selector, Parallel, etc.)
│   │   ├── Decorator/ (Repeat, Retry, Flip, etc.)
│   │   └── Leaf/ (Action, Condition, Wait)
│   ├── Attributes/              → Guards and callbacks
│   └── Optimizations/           → Zero-allocation helpers
├── .github/workflows/           → Automated NuGet publish
└── README.md

The Optimizations/ folder is unique to the C# version — it centralizes all performance-critical tricks that don't exist in the TS original.

Rough Performance Comparison

Early benchmarks on modest trees:

Operation	Original Mistreevous (TS)	MistreevousSharp (C#)	Improvement
DSL Parsing	~0.8 ms	~0.35 ms	~2.3× faster
Per-tick execution	Variable (GC pauses)	Stable ~0.00x ms	Near-zero overhead
Allocations per tick	Multiple objects	Zero	Completely eliminated

The real gains scale dramatically with entity count.

Usage Example in C

var definition = @"
root {
    sequence {
        action [CheckHealth]
        selector {
            action [Flee]
            action [Fight]
        }
    }
}";

var agent = new MyAgent(); // Implements your action callbacks

var tree = new BehaviourTree(definition, agent);

while (gameIsRunning)
{
    tree.Step(); // One AI tick — zero allocations
}

See the full example in the repo's example/ folder.

Where It Shines

Beyond multiplayer servers, MistreevousSharp is perfect for:

Unity games (no GC spikes)
Godot C# projects
Simulations and autonomous agents
Robotics and drone control
Any system needing modular, readable AI

Final Thoughts

Porting Mistreevous to C# was far more than translation — it required rethinking every allocation, every loop, and every object for the .NET reality. The result is a library that keeps the original's elegance and compatibility while being truly ready for high-performance, server-scale scenarios.

If you're building anything with complex agent behavior in .NET, give it a try!

GitHub: https://github.com/guinhx/MistreevousSharp

NuGet: https://www.nuget.org/packages/MistreevousSharp

Original Mistreevous (TS): https://github.com/nikkorn/mistreevous

Feedback, stars, and contributions very welcome! Let me know if you've used behavior trees on the server side — what pains did you hit?

Tags: #dotnet #csharp #gamedev #behaviortrees #performance #opensource #multiplayer

NimbleMock: A Modern, Blazing-Fast Mocking Library for .NET (34x Faster Than Moq)

Diego Teles — Sat, 13 Dec 2025 23:57:59 +0000

NimbleMock: A Modern, Blazing-Fast Mocking Library for .NET (34x Faster Than Moq)

Hey devs! If you've ever felt the pain of verbose mocking setups, runtime overhead slowing down your test suites, or struggling to mock static methods like DateTime.Now without ugly wrappers, you're not alone. Traditional libraries like Moq and NSubstitute are great, but in large-scale .NET projects (especially with async-heavy code and generic repositories), they can feel dated and slow.

That's why I built NimbleMock — a zero-allocation, source-generated mocking library designed for modern .NET testing in 2025 and beyond.

Why I Built NimbleMock

Over the years, I've dealt with common mocking frustrations in enterprise .NET apps:

Verbose setups for large interfaces (mocking 20+ methods just to test one).
Performance hits from runtime proxies (Castle.DynamicProxy in Moq) — slow creation and verification in big test suites.
Static/sealed mocking hell — no native support without paid tools or wrappers.
Async and generics issues — unexpected null tasks or clunky type inference.
Brittle tests — mocks that pass locally but fail in production because they don't match real API shapes.

Moq is battle-tested (and had its share of drama), NSubstitute is clean and readable, but neither fully leverages modern .NET features like source generators for zero overhead.

NimbleMock fixes these with compile-time magic: no runtime proxies, aggressive inlining, and stack allocation. Result? 34x faster mock creation and 3x faster verification than Moq, with zero allocations in typical scenarios.

Key Features

Partial mocks: Only mock what you need — unmocked methods throw clear NotImplementedException for early detection.
Native static/sealed mocking: Mock DateTime.Now, Environment, etc., directly.
First-class async support: Seamless for Task<T> and ValueTask<T>.
Generic type inference: Full support for nested generics (e.g., EF Core IQueryable<T>).
Fluent, chainable API: Inspired by the best of NSubstitute and Moq.
Lie-proofing: Optional runtime validation against real staging APIs to catch outdated mock shapes.
Compile-time analyzers: Catch errors early (e.g., warn if you forget SetupAsync for async methods).

MIT-licensed, open-source, and ready for contributions!

Quick Start

Install via NuGet:

dotnet add package NimbleMock

Basic example:

using NimbleMock;

public interface IUserRepository
{
    User GetById(int id);
    Task<bool> SaveAsync(User user);
}

var mock = Mock.Of<IUserRepository>()
    .Setup(x => x.GetById(1), new User { Id = 1, Name = "Alice" })
    .SetupAsync(x => x.SaveAsync(default!), true)
    .Build();

var user = mock.Object.GetById(1); // Returns Alice

mock.Verify(x => x.GetById(1)).Once();

Partial mock (perfect for god-interfaces):

var mock = Mock.Partial<ILargeService>()
    .Only(x => x.GetData(1), expectedData)
    .Build();

// Unmocked methods throw for safety

Static mocking:

var staticMock = Mock.Static<DateTime>()
    .Returns(d => d.Now, new DateTime(2025, 12, 25))
    .Build();

staticMock.Verify(d => d.Now).Once();

Generics example:

public interface IRepository<T>
{
    IQueryable<T> Query();
}

var mock = Mock.Of<IRepository<User>>()
    .Setup(x => x.Query(), users.AsQueryable())
    .Build();

var results = mock.Object.Query().Where(u => u.IsActive).ToList();

Performance Benchmarks

Run on .NET 8 (BenchmarkDotNet):

Mock Creation & Setup

Library	Time (ns)	Memory Allocated	Gain vs Moq
Moq	48,812	10.37 KB	Baseline
NSubstitute	9,937	12.36 KB	~5x faster
NimbleMock	1,415	3.45 KB	34x faster than Moq

Method Execution Overhead

Library	Time (μs)	Gain vs Moq
Moq	~1.4	Baseline
NSubstitute	~1.6	Slower
NimbleMock	~0.6	2.3x faster

Verification

Library	Time (ns)	Memory Allocated	Gain vs Moq
Moq	1,795	2.12 KB	Baseline
NSubstitute	2,163	2.82 KB	Slower
NimbleMock	585	0.53 KB	3x faster than Moq

Run them yourself:

dotnet run --project tests/NimbleMock.Benchmarks --configuration Release

Migrating from Moq/NSubstitute

It's straightforward — fluent chains make it cleaner.

From Moq:

// Moq
var mock = new Mock<IUserRepository>();
mock.Setup(x => x.GetById(1)).Returns(user);

// NimbleMock
var mock = Mock.Of<IUserRepository>()
    .Setup(x => x.GetById(1), user)
    .Build();

Verification is more readable too.

Full migration guide in the repo!

Lie-Proofing: Avoid "Tests That Lie"

Unique feature: Validate mocks against real endpoints.

var result = await LieProofing.AssertMatchesReal<IApiService>("https://api.staging.example.com");

if (!result.IsValid)
{
    // Log mismatches
}

Catches drifting APIs before production outages.

Final Thoughts

NimbleMock is built for .NET 8/9+ era: fast, safe, and joyful TDD. If you're tired of slow suites or static mocking hacks, give it a try!

GitHub: https://github.com/guinhx/NimbleMock
NuGet: https://www.nuget.org/packages/NimbleMock

Feedback welcome — what pains do you have with current mocking libs? Would you switch for native statics and this speed?

Star if you like it, and let's make testing fun again! 🚀

Tags: #dotnet #csharp #testing #tdd #opensource #mocking #performance