DEV Community: Safwan Abdulghani

[Boost]

Safwan Abdulghani — Sat, 20 Dec 2025 02:15:33 +0000

RoomSharp v0.4.3: Production-grade migrations, safe-by-default concurrency, and new companion packages

Safwan Abdulghani ・ Dec 20

#dotnet #csharp #sql #database

RoomSharp v0.4.3: Production-grade migrations, safe-by-default concurrency, and new companion packages

Safwan Abdulghani — Sat, 20 Dec 2025 02:14:36 +0000

RoomSharp 0.4.3 in one sentence

New to RoomSharp? Check out What is RoomSharp? for an overview.

RoomSharp v0.4.3 is a "core systems" release: migrations become stricter and more durable, concurrency becomes safe by default (with real opt-in parallelism), mapper caching moves to runtime, and the ecosystem expands with RoomSharp.Cli and RoomSharp.QueryExtensions and RoomSharp.Reactive.

If you're building apps where correctness, predictability, and performance matter (desktop, services, mobile-ish SQLite workloads), this is the release that makes the default path safer and the power-user path more explicit.

TL;DR

Migrations: Strict chains, journaled execution, transaction-safe

Concurrency: Serialized by default, Parallel opt-in with sessions

CLI: room migrate:up, room schema:export, and more

QueryExtensions: Dapper-like ad-hoc SQL with fluent builders

Reactive: Observe() + GetValueAsync() + OnDataSourceChanged()

Highlights

Migration engine overhaul
- Transaction-bound migration execution (via MigrationContext)
- Durable migration journaling (__room_migrations)
- Single-row state tracking (__room_state)
- Dirty-state protection to block unsafe re-execution after partial failure
- Strict "no gaps / no branching" migration chains
Concurrency overhaul
- Serialized mode is the default for safe multi-threaded usage
- Parallel mode enables true parallel DB I/O through multiple connections (session-per-operation)
Mapper cache moved to runtime
- Cache is owned by RoomDatabase, reducing generated code size while preserving hot-path performance characteristics
New packages
- RoomSharp.Cli – scaffolding, migrations, schema export/validation, inspection, safe diagnostics
- RoomSharp.QueryExtensions – Dapper-like ad-hoc SQL + streaming + low-level row access
- RoomSharp.Reactive – System.Reactive (Rx.NET) integration for RoomSharp queries
Reactive queries
- Table-ID based change tracking with transaction awareness
- Coalescing dispatcher + bounded per-subscriber delivery
- Built-in operators: Where(), DistinctUntilChanged(), Debounce(), Throttle()
- NEW: GetValueAsync() – await first query result without Task.Delay() workarounds
- NEW: OnDataSourceChanged() – zero-allocation lightweight change notifications

1) Migrations: strict, durable, and transaction-safe

Migrations are where systems typically fail in production—not because the SQL is hard, but because tooling is permissive, state tracking is weak, or execution leaks outside transactions.

RoomSharp 0.4.3 addresses this by introducing a new runtime migration engine with a few strong rules.

New metadata tables

RoomSharp now tracks migration state using:

__room_state — single-row "current state"
__room_migrations — append-only journal of applied migrations (including checksums, timing, and success/failure details)

This makes drift detection and recovery workflows much more deterministic.

New migration API: `IRoomMigration` + `MigrationContext`

The preferred style is now:

Implement IRoomMigration
Use MigrationContext to create commands that are guaranteed to be bound to the current transaction

Example: a manual migration that adds a column, with an explicit checksum (helper provided by RoomSharp):

using RoomSharp.Migrations;

public sealed class UserMigration_1_2 : IRoomMigration
{
    public int StartVersion => 1;
    public int EndVersion => 2;

    public string Id => "UserMigration_1_2:1->2";
    public string Name => nameof(UserMigration_1_2);

    public string Checksum =>
        MigrationChecksum.Sha256("ALTER TABLE users ADD COLUMN status TEXT DEFAULT 'active'");

    public async Task UpAsync(MigrationContext ctx)
    {
        await using var cmd = ctx.CreateCommand(
            "ALTER TABLE users ADD COLUMN status TEXT DEFAULT 'active'");

        await cmd.ExecuteNonQueryAsync(ctx.CancellationToken);
    }
}

Strict pathing: no gaps, no branching

RoomSharp now enforces a single migration chain:

A migration can only apply when StartVersion == currentVersion
No skipping versions
No divergent chains

This is stricter than many tools, but it prevents ambiguous migration plans and "works on my machine" database histories.

Dirty-state protection

If a previous migration attempt left the database in an unsafe state (tracked via a dirty flag), RoomSharp will fail fast instead of retrying and potentially compounding damage.

Production guidance: restore from backup or manually repair schema before clearing dirty-state.

Cross-process provider locks (implementation detail)

RoomSharp acquires a best-effort cross-process lock before applying migrations to avoid concurrent migration runners.

Provider	Mechanism	Notes
PostgreSQL	Advisory lock	Scoped to the DB session; released on disconnect
SQL Server	Application lock	Uses a named lock; honors timeout
MySQL	Named lock	Requires lock name uniqueness per database/app id
SQLite	Early write lock acquisition + busy timeout	Prevents concurrent writers during migration

This is an implementation detail and may change between versions.

2) RoomSharp.Cli: runtime migrations and tooling from the command line

RoomSharp.Cli is more than scaffolding. The important architectural choice is:

The CLI loads your compiled assembly and executes the same migration pipeline the runtime uses.

That means plans and verification are consistent with what happens when your app boots.

Install

dotnet tool install -g RoomSharp.Cli
room --help

Project Configuration (`room.config.json`)

Optional but recommended. Place at the project root to avoid passing flags with every command.

room make:config --provider sqlite --connection "Data Source=app.db" --ns MyApp.Data

This generates:

{
  "provider": "sqlite|pgsql|mysql|sqlserver",
  "connectionString": "Data Source=room.db",
  "buildConfiguration": "Debug",
  "namespaceRoot": "MyApp.Data",
  "paths": {
    "entities": "Data/Models",
    "daos": "Data/Daos",
    "database": "Data/Database",
    "migrations": "Data/Migrations",
    "autoMigrations": "Data/Migrations/Auto",
    "schema": "Data/Schemas",
    "seeders": "Data/Database/Seeders"
  }
}

Connection string references – avoid hardcoding secrets:

Prefix	Source	Example
`$env:`	Environment variable	`$env:DATABASE_URL`
`$appsettings:`	`appsettings.json` path	`$appsettings:ConnectionStrings:Default`

// From environment variable
{ "connectionString": "$env:DATABASE_URL" }

// From appsettings.json → ConnectionStrings → Default
{ "connectionString": "$appsettings:ConnectionStrings:Default" }

Migration workflow

Plan what would run (strict chain enforced):

room migrate:plan -b --to=3

Apply migrations:

room migrate:up -b --to=3

Verify applied migrations against recorded checksums (great for CI):

room migrate:verify -b

Dangerous recovery-only command (edits version state only; does not revert schema):

room migrate:set-version --to=2 --force

Safety defaults (why it matters)

CLI can auto-build before running runtime commands (-b), and can force Release builds (-r)
Scaffolding supports --dry-run and requires --force to overwrite
query defaults to safe behavior and blocks writes unless explicitly allowed

Example query usage:

room query "SELECT * FROM users" --format=table
room query "DELETE FROM users" --allow-writes   # explicit opt-in

Schema export and validation

Schema tooling is an underrated superpower for teams:

room schema:export --out ./schema_export
room schema:export --sql --out ./schema_sql
room schema:validate --provider=sqlserver --connection="..." --schema=./schema_export

Use these steps to support:

DBA review
CI schema verification
Reproducible documentation for migrations

3) Concurrency: safe by default, parallel when you opt in

ADO.NET makes it very easy to accidentally do unsafe things:

Reusing a DbConnection concurrently
Executing multiple commands at once on the same connection
Mixing transactions with parallel flows

RoomSharp 0.4.3 makes the safe path the default.

Serialized mode (default)

All DAO calls on a RoomDatabase instance are serialized through an internal gate
You can safely do Task.WhenAll(...) with the same DB instance without corrupting connection state

var db = RoomDatabase.Builder<AppDatabaseImpl>()
    .UseSqlite("app.db")
    .Build();

// Safe: both calls are serialized automatically
await Task.WhenAll(
    db.UserDao.GetAllAsync(),
    db.TodoDao.GetAllAsync()
);

Parallel mode (opt-in, true parallel DB I/O)

Parallel mode does not mean "parallel commands on one connection".
It means: multiple independent sessions (and therefore connections).

Enable via the [Database] attribute:

[Database(Version = 1, ConcurrencyMode = ConcurrencyMode.Parallel)]
public abstract class AppDatabase : RoomDatabase { }

Configure with a connection factory:

var cs = "Data Source=app.db;Mode=ReadWriteCreate;Cache=Private";

var db = RoomDatabase.Builder<AppDatabase>()
    .UseSqliteConnection(cs)
    .UseConnectionFactory(() => new SqliteConnection(cs))
    .SetMaxParallelConnections(32)
    .Build();

Unit of Work: explicit single-connection transactional scope

Transactions remain single-connection by nature, so RoomSharp provides a Unit-of-Work abstraction:

await using var uow = await db.BeginUnitOfWorkAsync();

await db.UserDao.InsertAsync(new User { Email = "a@b.com" });
await db.UserDao.UpdateAsync(new User { Id = 1, Email = "c@d.com" });

await uow.CommitAsync();

Note: BeginUnitOfWork requires ConcurrencyMode = Parallel.

Practical guidance:

Use Parallel for read-heavy workloads, especially when you can benefit from concurrent queries
Keep transactional flows within a single UnitOfWork/session

4) Mapper cache moved to runtime (smaller generated code)

In previous designs, mapper caches are often emitted into generated DAO code (or kept as per-DAO statics).
In 0.4.3, the mapper cache is owned by RoomDatabase at runtime:

Smaller generated output
Shared caching infrastructure
Preserves the high-performance "hit path" design

This is an internal optimization. The behavior is transparent to application code.

5) RoomSharp.QueryExtensions: ad-hoc SQL without giving up RoomSharp integration

RoomSharp removed QueryExecutor and [RawQuery]. The replacement is a dedicated package:
RoomSharp.QueryExtensions.

It's explicitly positioned as:

Dapper-like control
Integrated with RoomSharp's concurrency model
Supports streaming and low-level row access
Not a full ORM, and not meant to replace DAOs for core domain queries

Install

dotnet add package RoomSharp.QueryExtensions

Quick examples

// Fluent query (type-safe)
var users = await db.From<User>()
    .Where(u => u.IsActive)
    .OrderBy(u => u.Name)
    .GetAsync();

// With eager loading
var orders = await db.From<Order>()
    .Include(o => o.Customer)
    .GetAsync();

// Raw SQL
var count = await db.ExecuteScalarAsync<long>(
    "SELECT COUNT(*) FROM users WHERE IsActive = @active",
    new { active = true });

// Streaming large results
await foreach (var item in db.QueryStreamAsync<Item>("SELECT * FROM items"))
{
    Process(item);
}

Fluent query builder

using RoomSharp.QueryExtensions.FluentQuery;

// String-based
var todos = await db.Table<Todo>("todos")
    .Where("IsDone", false)
    .Where("CategoryId", ">", 5)
    .OrderBy("CreatedAt")
    .Take(20)
    .GetAsync();

// Expression-based (type-safe)
var activeUsers = await db.From<User>()
    .Where(u => u.IsActive)
    .WhereNotNull(u => u.Email)
    .WhereBetween(u => u.Age, 18, 65)
    .OrderBy(u => u.Name)
    .GetAsync();

Joins with eager loading

// Join with Include and filtered by related entity
var order = await db.From<Order>()
    .Select("orders.id", "orders.customer_id", "orders.total")
    .Join("customers", "orders.customer_id", "customers.id")
    .WhereEndsWith("customers.name", "Smith")
    .Include(o => o.Customer)
    .SingleAsync();

// Multiple JOINs
var results = await db.Table<OrderDto>("orders")
    .Join("customers", "orders.customer_id", "customers.id")
    .LeftJoin("products", "orders.product_id", "products.id")
    .Select("orders.id", "customers.name", "products.title")
    .GetAsync();

⚠️ When using Join(), always use table prefixes in Select() to avoid ambiguous column errors.

Low-level zero-allocation row access: `RowReader`

For hot paths, aggregations, exports, or high-frequency reads:

using RoomSharp.QueryExtensions.Extensions;
using RoomSharp.QueryExtensions.LowLevel;

await db.ReadRawAsync(
    "SELECT Id, Title, IsDone FROM todos",
    param: null,
    (in RowReader r) =>
    {
        var id = r.Get<long>(0);
        var title = r.Get<string>(1);
        var isDone = r.Get<bool>(2);
        Console.WriteLine($"{id}: {title} ({(isDone ? "done" : "pending")})");
    });

Concurrency integration

QueryExtensions respects RoomSharp's concurrency model:

In Serialized mode it acquires the internal gate automatically
In Parallel mode you can use multiple DbSessions concurrently

// Parallel mode - use sessions for concurrency
await using var session1 = await db.OpenSessionAsync();
await using var session2 = await db.OpenSessionAsync();

var task1 = session1.QueryAsync<Todo>("SELECT * FROM todos WHERE CategoryId = 1");
var task2 = session2.QueryAsync<Todo>("SELECT * FROM todos WHERE CategoryId = 2");

await Task.WhenAll(task1.AsTask(), task2.AsTask());

6) Dependency injection improvements (RoomSharp.DependencyInjection)

RoomSharp ships a DI companion package that wires databases and DAOs into IServiceCollection using familiar ASP.NET Core patterns.

Install

dotnet add package RoomSharp.DependencyInjection

Basic registration

builder.Services.AddRoomSharpDatabase<AppDatabase>(context =>
{
    var configuration = context.Services.GetRequiredService<IConfiguration>();
    var connString = configuration.GetConnectionString("Default")!;

    context.UseSqlite(connString);

    context.Builder
        .SetVersion(2)
        .AddMigrations(new InitialMigration())
        .SetEntities(typeof(User), typeof(Todo));
});

builder.Services.AddRoomSharpDao<AppDatabase, ITodoDao>(db => db.TodoDao);

Provider shortcuts

context.UseSqlite("app.db");
context.UseSqlServer("Server=.;Database=MyApp;Trusted_Connection=True;");
context.UsePostgres("Host=localhost;Database=myapp;Username=user;Password=pass;");
context.UseMySql("Server=localhost;Database=myapp;User=root;Password=pass;");

Service lifetimes + scoped shorthand

builder.Services.AddRoomSharpDatabase<AppDatabase>(ctx => ctx.UseSqlite("app.db"));

builder.Services.AddRoomSharpDatabase<AppDatabase>(
    ctx => ctx.UseSqlite("app.db"),
    ServiceLifetime.Scoped);

builder.Services.AddRoomSharpScopedDatabase<AppDatabase>(ctx => ctx.UseSqlite("app.db"));

Factory pattern for background services / Blazor Server

builder.Services.AddRoomSharpDatabaseFactory<AppDatabase>(ctx =>
{
    ctx.UseSqlServer(configuration.GetConnectionString("Default")!);
});

public class MyBackgroundService : BackgroundService
{
    private readonly IRoomDatabaseFactory<AppDatabase> _dbFactory;

    public MyBackgroundService(IRoomDatabaseFactory<AppDatabase> dbFactory)
        => _dbFactory = dbFactory;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        using var db = _dbFactory.Create();
        await db.TodoDao.GetAllAsync();
    }
}

7) Reactive queries & change tracking

RoomSharp includes a reactive query system that re-executes queries when watched tables change. The system is:

Table-ID based – uses integer IDs for efficient lookup
Transaction-aware – notifications dispatched only after commit
Coalesced – reduces notification noise via dispatcher
Bounded delivery – supports LatestOnly, Buffered, All modes

Enable change tracking + observe a query

using RoomSharp.Extensions;
using RoomSharp.Invalidation;
using RoomSharp.Reactive;

var db = RoomDatabase.Builder<AppDatabaseImpl>()
    .UseSqlite("app.db")
    .EnableChangeTracking(o =>
    {
        o.DispatchInterval = TimeSpan.FromMilliseconds(50);
        o.DeliveryMode = DeliveryMode.LatestOnly;
    })
    .Build();

var todosTableId = db.GetTableIdOrThrow("todos");

var notesQuery = db.Observe(
    static async (ct, database) => await database.NoteDao.GetAllAsync(),
    notesTableId
);


using var sub = query.Subscribe(
    onNext: list => Console.WriteLine($"Todos: {list.Count}"),
    onError: ex => Console.WriteLine($"Error: {ex.Message}"));

Built-in operators

// Debounce: delays refresh until a quiet period
await using var debounced = db.Observe(ct => ..., todosTableId)
    .Debounce(TimeSpan.FromMilliseconds(100))
    .DistinctUntilChanged();

// Throttle: limits refresh rate
await using var throttled = db.Observe(ct => ..., todosTableId)
    .Throttle(TimeSpan.FromMilliseconds(200))
    .Where(list => list.Count > 0);

Rx.NET integration

using RoomSharp.Reactive.Rx;

// Convert to IObservable<T> for use with Rx.NET operators
var observable = query.ToObservable();

observable
    .Buffer(TimeSpan.FromSeconds(1))
    .Subscribe(batch => Console.WriteLine($"Received {batch.Count} updates"));

GetValueAsync: await first query result

Instead of using Subscribe() + Task.Delay(), you can now await the first query result directly:

// Before (workaround)
var subscription = query.Subscribe(onNext: list => { ... });
await Task.Delay(500);  // Unreliable!

// After (recommended)
var initialData = await query.GetValueAsync();
Console.WriteLine($"Initial count: {initialData.Count}");

DataSourceChanged: lightweight change notifications

For simple notification scenarios where you don't need reactive queries, RoomSharp provides a zero-allocation callback:

// Register a lightweight callback
db.OnDataSourceChanged(info =>
{
    Console.WriteLine($"Table {info.TableId}: {info.Operation} ({info.AffectedRows} rows)");
});

// Remove callback when no longer needed
db.OnDataSourceChanged(null);

DataChangeInfo structure

public readonly struct DataChangeInfo
{
    public readonly int TableId;              // Table identifier
    public readonly DataChangeOperation Operation;  // Insert, Update, Delete, BulkInsert
    public readonly int AffectedRows;         // Number of affected rows
}

Performance characteristics

Feature	Description
Zero-allocation	Uses `struct` instead of `class`
Zero-cost when unused	Inline null check with early return
Immediate notification	Called synchronously after each operation
No dependencies	Works without `EnableChangeTracking()`

9) Provider update: MySQL now uses MySqlConnector

RoomSharp's MySQL provider switched its internal driver from MySql.Data to MySqlConnector for performance and licensing considerations. This change is transparent at the application level—no code changes required.

Breaking / behavioral changes

Change	Migration path
`__room_metadata` deprecated	New installs use `__room_state` + `__room_migrations`. Existing databases are upgraded automatically.
`QueryExecutor` and `[RawQuery]` removed	Use RoomSharp.QueryExtensions package

Suggested upgrade checklist

Preview migrations:

   room migrate:plan -b

Apply migrations:

   room migrate:up -b

Verify checksums (CI-friendly):

   room migrate:verify -b

If you used [RawQuery]: migrate those call sites to RoomSharp.QueryExtensions.
Decide concurrency mode:
- Stick to Serialized (default) for most apps (especially SQLite)
- Enable Parallel only when you need real concurrency and can provide a connection factory

Closing thoughts

RoomSharp 0.4.3 sharpens the contract between your application and the database:

Migrations are strict and journaled
Concurrency is safe by default and explicit when parallel
Tooling matures with a CLI that runs the same migration pipeline
Ad-hoc SQL is moved into a focused companion package without sacrificing integration
Reactive queries are transaction-aware and coalesced by design

This release focuses on making the default path safer while providing explicit power-user options when needed. RoomSharp deliberately avoids feature creep—new capabilities are added only when they align with its explicit, predictable design philosophy.

Get Started

dotnet add package RoomSharp

NuGet Packages

Package	Description
RoomSharp	Core library with SQLite support
RoomSharp.MySql	MySQL/MariaDB provider
RoomSharp.PostgreSql	PostgreSQL provider
RoomSharp.SqlServer	SQL Server provider
RoomSharp.DependencyInjection	Microsoft.Extensions.DI integration
RoomSharp.Cli	CLI tool for migrations and schema
RoomSharp.QueryExtensions	Fluent query builders
RoomSharp.Reactive	Observable queries and change tracking

RoomSharp: Source-Generated Data Layer for Modern .NET

Safwan Abdulghani — Tue, 18 Nov 2025 01:22:56 +0000

If you’ve ever envied Android’s Room stack and wished you could have the same attribute-driven ergonomics, source-generated DAOs, and multi-database freedom in .NET 8/9/10, RoomSharp is for you. It’s a Room-inspired data layer built specifically for modern .NET: a Roslyn source generator, a set of lightweight providers (SQLite, SQL Server, PostgreSQL, MySQL/MariaDB), and companion packages that deliver zero-reflection persistence without hiding the power of raw ADO.NET.
The official documentation is available at:
https://safwan.pro/roomsharp/

You can also grab the main package on NuGet:
https://www.nuget.org/packages/RoomSharp

The RoomSharp Package Lineup

RoomSharp – the runtime, attributes, relation loader, paging helpers, multi-instance invalidation logic, and type converter infrastructure.
RoomSharp.SourceGenerator – the Roslyn generator that turns [Dao], [Entity], [Insert], [Query], [Transaction], and friends into fully compiled implementations (AppDatabaseImpl, TodoDaoImpl, …) at build time. No runtime reflection, no IL weaving, just C#.
RoomSharp.SqlServer / RoomSharp.PostgreSql / RoomSharp.MySql / RoomSharp (for SQLite) – each provider implements IDatabaseProvider, so you can switch backends with a single builder call.
RoomSharp.DependencyInjection – IServiceCollection extensions that register databases and DAOs as first-class citizens in ASP.NET Core, worker services, and background jobs.

What Working With RoomSharp Looks Like

using RoomSharp.Attributes;
using RoomSharp.Core;

[Entity(TableName = "users")]
[Index(Value = ["Email"], Unique = true)]
public class User
{
    [PrimaryKey(AutoGenerate = true)]
    public long Id { get; set; }

    [Unique]
    public required string Email { get; set; }
    public string? Name { get; set; }
}

[Dao]
public interface IUserDao
{
    [Insert] long Insert(User user);

    [Query("SELECT * FROM users WHERE Email = :email")]
    Task<User?> FindByEmailAsync(string email);

    [Transaction]
    async Task<long> UpsertAsync(User user) { … }
}

[Database(Version = 1, Entities = [typeof(User)])]
public abstract class AppDatabase(IDatabaseProvider provider, ILogger? logger = null)
    : RoomDatabase(provider, logger)
{
    public abstract IUserDao UserDao { get; }
}

var db = RoomDatabase.Builder<AppDatabaseImpl>()
    .UseSqlite("app.db")
    .SetJournalMode(JournalMode.WAL)
    .EnableMultiInstanceInvalidation()
    .SetAutoCloseTimeout(TimeSpan.FromMinutes(5))
    .Build();

You describe your schema with attributes, author DAOs as interfaces (with optional method bodies), and let the generator spit out the implementation. The builder wires in the provider, logging, callbacks, query executors, WAL settings, multi-instance invalidation, and auto-close semantics.

Calling DAOs from Your Application

Once the generator produces AppDatabaseImpl, you work with DAOs like any other service. Inject the database, grab the DAO, and call the generated members—transactions, type converters, and relation loaders are already baked in.

public sealed class UserService(AppDatabase db, ILogger<UserService> logger)
{
    public async Task<long> CreateUserAsync(string email, string? name)
    {
        var newUser = new User { Email = email, Name = name };
        var id = await db.UserDao.UpsertAsync(newUser);

        logger.LogInformation("Upserted user {Email} with id {Id}", email, id);
        return id;
    }

    public async Task<IReadOnlyList<User>> GetActiveUsersAsync()
    {
        // Generated query method with mapping handled by RoomSharp.
        var users = await db.UserDao.RunCustomQueryAsync(
            new QueryBuilder()
                .Select("*")
                .From("users")
                .Where("IsActive = 1")
                .OrderBy("CreatedAt DESC")
                .Build());

        return users;
    }
}

// Somewhere in your app's startup or minimal API endpoint.
var userId = await userService.CreateUserAsync("jane@contoso.dev", "Jane");

Because the DAO implementation is emitted at compile time, there’s no reflection penalty or runtime codegen. Each call gets compiled SQL, parameter handling, and transaction boundaries designed specifically for the method you declared.

Builder Superpowers

RoomDatabaseBuilder<T> isn’t just “give me a connection string.” It can:

swap providers (UseSqlite, UseProvider(new PostgresProvider(), connString))
override metadata (SetVersion, SetEntities) when you need conditional builds
register callbacks (AddCallback) for OnCreate, OnOpen, OnDestructiveMigration
orchestrate migrations (AddMigrations, FallbackToDestructiveMigration)
plug diagnostics (SetQueryExecutor) or enable WAL + auto-close for desktop/mobile scenarios.

All of it is exposed through RoomSharp.Extensions, so even though the builder stays lean, the API surface feels cohesive.

Transactions, Converters, and Relations with Zero Boilerplate

[Transaction] wraps DAO methods—sync or async—in the right helper (RunInTransaction, RunInTransactionAsync), so you can just focus on domain logic.
Type conversion is handled via ITypeConverter<TFrom, TTo> implementations you can attach to properties or register globally (db.Converters.Register(new GuidToStringConverter())).
[Relation] + [Embedded] let DAOs project 1:1, 1:N, and N:N graphs into DTOs, and RelationLoader can hydrate navigation properties post-query.
Paging, LiveData-like observables, raw query helpers, and multi-map DTO support live directly inside the core package.

Migrations Without Drama

RoomSharp mixes declarative and imperative migrations:

[AutoMigration(From = 1, To = 2, Spec = typeof(UserSpec))] with IAutoMigrationSpec handles straightforward schema changes (rename table, rename column, add/drop column, etc.) and allows custom post-migrate hooks.
For the times you need hand-crafted SQL, derive from Migration and override Migrate(DbConnection connection).

MigrationManager keeps the internal __room_metadata table in sync, reports destructive migrations, and ensures callbacks can respond accordingly.

Raw SQL When You Need It

Prefer to craft SQL yourself? [RawQuery] methods accept ISupportSQLiteQuery, and RoomSharp.RawQuery.QueryBuilder lets you compose parameterized SQL fluently. For deeper control, implement IQueryExecutor (great for logging, caching, or plugging Dapper) and register it via SetQueryExecutor.

First-Class ASP.NET Core Integration

The RoomSharp.DependencyInjection package adds intuitive extensions:

services.AddRoomSharpDatabase<AppDatabase>(context =>
{
    var configuration = context.Services.GetRequiredService<IConfiguration>();
    var conn = configuration.GetConnectionString("RoomSharp")!;

    context.UseSqlite(conn);
    context.Builder
        .SetVersion(2)
        .AddMigrations(new InitialMigration())
        .SetEntities(typeof(User), typeof(Todo));
});

services.AddRoomSharpDao<AppDatabase, ITodoDao>(db => db.TodoDao);

The logger resolved from DI is automatically attached to the builder.
Databases are registered as singletons so they can manage their own connection pools.
DAOs default to scoped lifetimes, but you can override the ServiceLifetime when calling AddRoomSharpDao.
You can bind connection strings from IConfiguration, resolve custom providers from DI (UseProvider<TProvider>()), or expose DAOs as factory delegates if you prefer.

Provider Packages Built for Production

The runtime models every backend via IDatabaseProvider, so swapping is a matter of configuration:

RoomSharp ships with SQLite support and helpers such as SetJournalMode(JournalMode) and multi-instance invalidation for WAL scenarios.
RoomSharp.SqlServer, RoomSharp.PostgreSql, and RoomSharp.MySql lean on the official ADO.NET drivers (Microsoft.Data.SqlClient, Npgsql, MySql.Data). Each provider fine-tunes dialect helpers so generated SQL uses the proper parameter styles and data type affinities.
Need custom behavior (connection resiliency, tracing)? Implement your own provider or wrap the existing ones.

Getting Started Today

Pull RoomSharp from NuGet (dotnet add package RoomSharp) and pair it with any provider package you need (RoomSharp.SqlServer, RoomSharp.PostgreSql, RoomSharp.MySql) plus the source generator companion.
Model your entities/DAOs exactly like the sample shown above, then run dotnet build to let the generator emit *Impl classes in your project.
Wire the generated database into your host (minimal API, ASP.NET Core, worker service) via the builder or the RoomSharp.DependencyInjection extensions.
Full documentation, API references, and usage guides are available at: https://safwan.pro/roomsharp/ The public GitHub repository and samples are on the way—follow the NuGet page to get notified when they drop.

RoomSharp targets net8/net9/net10 today, is licensed under MIT, and is heading toward a public GitHub launch alongside full-text search improvements and a re-enabled test suite. Feedback, contributions, and real-world stories are very welcome especially if you’ve been wanting a Room-style experience in the .NET ecosystem.

Give it a spin, tell me what hurts, and let’s build the data layer we’ve always wanted in C#.

Rust-Style Error Handling in C# - Why SharpResults Makes Your Code Bulletproof

Safwan Abdulghani — Tue, 14 Oct 2025 21:40:34 +0000

We've all been there. You're debugging a production issue at 2 AM, and somewhere deep in the call stack, someone forgot to catch an exception. The error was invisible in the function signature. No warning. No compile-time check. Just a runtime crash waiting to happen.

public User GetUser(string id)  // Can this throw? Who knows!
{
    return _database.Query(id);  // Spoiler: it can
}

Meanwhile, in Rust land, this doesn't happen. The compiler literally won't let you ignore errors. Every function that can fail says so in its type signature, and you can't compile your code until you handle it.

I wanted that safety in C#. So I built SharpResults.

Why Exceptions Aren't Enough

Don't get me wrong—exceptions have their place for truly unexpected situations.
But when failures are part of normal program flow, exceptions make code harder to reason about, less predictable, and slower to execute:

try
{
    var user = await GetUser(id);
    try
    {
        var orders = await GetOrders(user.Id);
        try
        {
            var total = CalculateTotal(orders);
            return total;
        }
        catch (InvalidOperationException ex)
        {
            // Handle calculation errors
        }
    }
    catch (HttpRequestException ex)
    {
        // Handle API errors
    }
}
catch (NotFoundException ex)
{
    // Handle missing user
}

Pyramid of doom, anyone? And here's the thing: nothing in the type signatures tells you this can fail. You just have to know. Or read the docs. Or learn the hard way in production.

The Rust Way: Errors Are Just Values

Rust takes a different approach. If something can fail, you return a Result:

// Rust
fn divide(a: i32, b: i32) -> Result<i32, String> {
    if b == 0 {
        Err("Cannot divide by zero".to_string())
    } else {
        Ok(a / b)
    }
}

The type signature screams "this can fail!" Now here's the same thing with SharpResults:

// C# with SharpResults
public Result<int, string> Divide(int a, int b)
{
    if (b == 0)
        return "Cannot divide by zero";  // Implicit Err

    return a / b;  // Implicit Ok
}

See the difference? The error is part of the type. The compiler knows about it. Your IDE knows about it. You can't pretend it doesn't exist.

You Literally Can't Ignore Errors

Here's where it gets good. Try to use the result without handling the error:

var result = Divide(10, 0);
int value = result;  // ❌ Compile error!

The compiler won't let you. You have to handle both cases:

var message = result.Match(
    ok: value => $"Result: {value}",
    err: error => $"Error: {error}"
);

Compare that to exceptions:

public int DivideUnsafe(int a, int b)
{
    return a / b;  // Can throw, nothing stops you from ignoring it
}

var value = DivideUnsafe(10, 0);  // 💥 Boom, runtime crash

Multiple Ways to Create Results

SharpResults gives you flexibility in how you create results:

// Explicit factory methods
var ok = Result.Ok<int, string>(42);
var err = Result.Err<int, string>("Something went wrong");

// Implicit conversions (my favorite)
Result<int, string> result1 = 42;  // Becomes Ok
Result<int, string> result2 = "Error";  // Becomes Err

// Catch exceptions automatically
var result3 = Result.Try(() => int.Parse("123"));
var result4 = await Result.TryAsync(async () => await GetDataAsync());

// Convert from Option or functions
var fromOption = Result.From(someOption);
var fromFunc = Result.From(() => DoSomething());

// With custom error types
var result5 = Result.From(
    () => RiskyOperation(),
    ex => new MyError(ex.Message, 500)
);

Working with Results: Your Way

Multiple ways to extract values depending on your needs:

// Safe extraction with defaults
var value = result.UnwrapOr(0);  // Returns value or 0
var value2 = result.UnwrapOrElse(err => err.Length);  // Compute from error
var value3 = result.UnwrapOrDefault();  // Type's default value

// Pattern matching (C# 8+)
var message = result switch
{
    (true, var val, _) => $"Success: {val}",
    (false, _, var err) => $"Error: {err}"
};

// Check state
if (result.WhenOk(out var val))
    Console.WriteLine($"Got {val}");

if (result.WhenErr(out var error))
    Console.WriteLine($"Error: {error}");

// Deconstruction
var (value, error) = result;  // One will be null

// Properties
if (result.IsOk)
    ProcessValue(result.Unwrap());

Chain Operations Without the Pyramid

Remember that nested try-catch nightmare from earlier? Here's the SharpResults version:

public Result<double, string> GetDiscountedPrice(string userId, string productId)
{
    return GetUser(userId)
        .AndThen(user => GetProduct(productId).Map(product => (user, product)))
        .AndThen(data => CalculateDiscount(data.user, data.product))
        .Map(discount => ApplyDiscount(productPrice, discount));
}

Or if you prefer LINQ query syntax:

var result = from user in GetUser(userId)
             from product in GetProduct(productId)
             from discount in CalculateDiscount(user, product)
             select ApplyDiscount(product.Price, discount);

No nesting. No manual error propagation. If any step fails, the error automatically flows through and you handle it once at the end. This is called "railway-oriented programming"—your code either stays on the happy path or switches to the error track.

Option: Never Null Again

Tony Hoare called null references his "billion-dollar mistake." Rust doesn't have null—it has Option<T>. SharpResults brings that too:

// No more null returns
public Option<User> FindUserById(string id)
{
    var user = _users.FirstOrDefault(u => u.Id == id);
    return Option.Create(user);  // Some(user) or None
}

// Multiple ways to create Options
Option<int> opt1 = Option.Some(42);
Option<int> opt2 = Option.None<int>();
Option<int> opt3 = 42;  // Implicit conversion

// Chain operations safely
var displayName = FindUserById(id)
    .Map(u => u.Name)
    .Filter(name => !string.IsNullOrEmpty(name))
    .UnwrapOr("Anonymous");

// Pattern matching (.NET 8+)
if (FindUserById(id) is (true, var user))
    Console.WriteLine($"Found: {user.Name}");

// Filter and transform
var adminOption = FindUserById("123")
    .Filter(u => u.IsAdmin)
    .Map(u => u.Name);

No NullReferenceException. Ever. The type system tracks whether a value might be missing, and the compiler makes sure you handle it.

Safe Collections: No More LINQ Bombs

How many times has this bitten you?

var first = list.First();  // 💥 InvalidOperationException if empty
var value = dict[key];     // 💥 KeyNotFoundException if missing
var single = items.Single();  // 💥 Multiple exceptions possible

SharpResults adds safe alternatives for everything:

// Safe LINQ operations
var first = users.FirstOrNone();  // Option<User>
var last = users.LastOrNone(u => u.IsActive);
var single = items.SingleOrNone(u => u.Id == id);
var element = users.ElementAtOrNone(5);

// Dictionary operations
var value = dict.GetValueOrNone(key);  // Option<TValue>

// Stack and Queue
var peeked = stack.PeekOrNone();  // Doesn't remove
var popped = stack.PopOrNone();  // Removes and returns
var dequeued = queue.DequeueOrNone();

// PriorityQueue (.NET 6+)
var next = priorityQueue.PeekOrNone<Task, int>();
var task = priorityQueue.DequeueOrNone<Task, int>();

// Thread-safe concurrent collections
var item = concurrentBag.TakeOrNone();
var value = concurrentStack.PopOrNone();
var next = concurrentQueue.DequeueOrNone();

// Sets (HashSet, SortedSet, ImmutableHashSet, etc.)
var found = hashSet.GetValueOrNone(searchValue);
var item = sortedSet.GetValueOrNone(value);

// Extract all Some values from a sequence
var values = options.Values();  // IEnumerable<T>

// Transform and filter in one pass
var results = items.SelectWhere(x => 
    x > 0 ? Option.Some(x * 2) : Option.None<int>()
);

// Sequence operations
var allOrNone = options.Sequence();  // Option<IEnumerable<T>>
var listOrNone = options.SequenceList();  // Option<List<T>>

No exceptions. Just explicit presence or absence that the type system tracks.

Result Collection Operations

Work with collections of Results safely:

// Extract all successes
var successes = results.Values();  // IEnumerable<T>

// Extract all failures
var failures = results.Errors();  // IEnumerable<TError>

// Inspect without consuming
var result = GetData()
    .Inspect(data => Console.WriteLine($"Got: {data}"))
    .InspectErr(err => Logger.Error(err));

// Check contents
if (result.Contains(expectedValue))
    Console.WriteLine("Found it!");

if (errorResult.ContainsErr(specificException))
    Console.WriteLine("Expected error occurred");

// Collect results (all must succeed)
var results = ids
    .Select(id => GetUser(id))
    .Collect();  // Result<List<User>, TError>

NumericOption: Math That Can Fail (.NET 7+)

For numeric types, you can do math directly on optional numbers:

NumericOption<int> a = 10;
NumericOption<int> b = 20;

var sum = a + b;        // Some(30)
var product = a * b;    // Some(200)
var difference = a - b; // Some(-10)

NumericOption<int> none = NumericOption<int>.None;
var invalid = a + none; // None - operations propagate None

// All arithmetic operators work
var incremented = ++a;  // Some(11)
var negated = -b;       // Some(-20)

// Numeric checks
bool isPositive = NumericOption.IsPositive(a);  // true
bool isEven = NumericOption.IsEvenInteger(b);   // true

// Safe parsing
var parsed = NumericOption<int>.Parse("42");     // Some(42)
var failed = NumericOption<int>.Parse("nope");   // None

// Numeric functions
var absolute = NumericOption.Abs(negated);  // Some(20)
var max = NumericOption.Max(a, b);          // Some(20)
var clamped = NumericOption.Clamp(a, 0, 100);

// Convert between types
Option<int> regularOption = myNumericOption;  // Implicit

Unit Type: For Void-Like Operations

When you want to return a Result but there's no meaningful success value:

public Result<Unit, string> SaveData(string data)
{
    try
    {
        File.WriteAllText("data.txt", data);
        return Unit.Default;  // Success with no value
    }
    catch (Exception ex)
    {
        return ex.Message;  // Error
    }
}

// Or use Result.From for actions
var result = Result.From(() => File.Delete("temp.txt"));

Option/Result Interop

Convert between Options and Results seamlessly:

// Option to Result
var result = option.OkOr("Value not found");  // Result<T, string>
var result2 = option.OkOrElse(() => new MyError("Missing"));

// Result to Option
var okOption = result.Ok();   // Option<T> - None if Err
var errOption = result.Err(); // Option<TError> - None if Ok

// Transpose nested types
Option<Result<int, string>> optRes = /* ... */;
Result<Option<int>, string> resOpt = optRes.Transpose();

Result<Option<int>, string> resOpt2 = /* ... */;
Option<Result<int, string>> optRes2 = resOpt2.Transpose();

// NumericOption to Result
NumericOption<int> numOpt = 42;
var result = numOpt.OkOr("No number");

Bool Extensions: Conditional Options

Create Options based on boolean conditions:

// Execute function if true
var result = isValid.Then(() => ProcessData());  // Option<T>

// Create Some/None based on condition
var option = hasPermission.ThenSome(userData);  // Some or None

// Async versions
var asyncResult = await isValid.ThenAsync(async () => 
    await LoadDataAsync()
);

Full Async/Await Support

Everything works seamlessly with async, including ValueTask for performance:

// Result async operations
var result = await GetUserAsync(id)
    .MapAsync(async user => await GetProfileAsync(user))
    .AndThenAsync(async profile => await EnrichAsync(profile))
    .MapOrElseAsync(
        mapper: async data => await FormatAsync(data),
        defaultFactory: async err => await GetDefaultAsync()
    );

// Option async operations
var option = await FindUserAsync(id)
    .MapAsync(async user => await user.GetNameAsync())
    .AndThenAsync(async name => await ValidateAsync(name))
    .OrElseAsync(async () => await GetDefaultNameAsync());

// Work with async sequences
await foreach (var value in asyncOptions.ValuesAsync())
{
    await ProcessAsync(value);
}

// Async collection operations
var firstAsync = await asyncSequence.FirstOrNoneAsync();
var filteredAsync = await asyncSequence.FirstOrNoneAsync(x => x > 10);

// Results in async sequences
await foreach (var success in asyncResults.ValuesAsync())
{
    await ProcessSuccessAsync(success);
}

await foreach (var error in asyncResults.ErrorsAsync())
{
    await LogErrorAsync(error);
}

Advanced Patterns

SharpResults supports sophisticated error handling patterns:

// OrElse - try alternatives on error
var result = TryPrimary()
    .OrElse(err => TrySecondary())
    .OrElse(err => TryTertiary());

// Flatten nested results
Result<Result<int, string>, string> nested = GetNestedResult();
Result<int, string> flattened = nested.Flatten();

// Zip multiple results together
var combined = result1.Zip(result2, (a, b) => a + b);

// And/Or for combining results
var both = result1.And(result2);  // Ok only if both Ok
var either = result1.Or(result2); // First Ok or last Err

JSON Serialization: Just Works

Built-in support for System.Text.Json with no configuration:

using System.Text.Json;

// Option serialization
var option = Option.Some(42);
var json = JsonSerializer.Serialize(option);  // "42"

var none = Option.None<int>();
var jsonNone = JsonSerializer.Serialize(none);  // "null"

// Result serialization
var ok = Result.Ok<int, string>(42);
var jsonOk = JsonSerializer.Serialize(ok);  // {"ok":42}

var err = Result.Err<int, string>("Error message");
var jsonErr = JsonSerializer.Serialize(err);  // {"err":"Error message"}

// NumericOption serialization (.NET 7+)
NumericOption<int> numOpt = 100;
var jsonNum = JsonSerializer.Serialize(numOpt);  // "100"

// Deserialization works automatically
var deserializedOpt = JsonSerializer.Deserialize<Option<int>>("42");
var deserializedResult = JsonSerializer.Deserialize<Result<int, string>>("""{"ok":42}""");

JSON Extensions for Safe Parsing

Work with System.Text.Json safely:

using SharpResults.Extensions;

// JsonValue
var number = jsonValue.GetOption<int>();  // Option<int>

// JsonObject
var name = jsonObj.GetPropValue<string>("name");  // Option<string>
var node = jsonObj.GetPropOption("address");      // Option<JsonNode>

// JsonElement
var prop = jsonElement.GetPropOption("field");           // Option<JsonElement>
var value = jsonElement.GetPropOption("id".AsSpan());    // Span support

Real-World API Example

Here's how I actually use this for HTTP APIs:

public record ApiError(string Message, int StatusCode);

public async Task<Result<WeatherData, ApiError>> GetWeatherAsync(string city)
{
    return await Result.TryAsync(async () =>
    {
        using var response = await _client.GetAsync($"api/weather/{city}");

        if (!response.IsSuccessStatusCode)
            return Result.Err<WeatherData, ApiError>(
                new ApiError("API request failed", (int)response.StatusCode)
            );

        var json = await response.Content.ReadAsStringAsync();
        var data = JsonSerializer.Deserialize<WeatherData>(json);

        return data is not null
            ? Result.Ok<WeatherData, ApiError>(data)
            : Result.Err<WeatherData, ApiError>(
                new ApiError("Invalid response data", 500)
            );
    })
    .MapErr(ex => new ApiError(ex.Message, 500));
}

// Usage in a controller
var weather = await GetWeatherAsync("London");

return weather.Match(
    ok: data => Ok(new WeatherResponse(data)),
    err: error => StatusCode(error.StatusCode, error.Message)
);

No unhandled exceptions. Error types are explicit. The compiler ensures you handle both paths.

Bridging Exception-Based Code

You'll still work with libraries that throw exceptions. Result.Try is your bridge:

// Catch exceptions and convert to Result
var result = Result.Try(() => 
    JsonSerializer.Deserialize<User>(json)
);

// Async version
var result = await Result.TryAsync(async () => 
    await httpClient.GetStringAsync(url)
);

// Custom error types
var result = Result.From(
    () => RiskyOperation(),
    ex => new MyError(ex.Message, ex.GetType().Name)
);

// For actions (void methods)
var result = Result.From(() => File.Delete("temp.txt"));

This keeps your domain logic clean while working with the messy real world.

Performance: Actually Pretty Good

Rust's philosophy is "zero-cost abstractions." SharpResults gets pretty close:

Structs, not classes - No heap allocations for Result/Option
No exception overhead - No stack unwinding costs
Aggressive inlining - MethodImpl attributes everywhere
Span support - Zero-copy conversions

Result<int, string> result = 42;  // Stack-allocated
ReadOnlySpan<int> span = result.AsSpan();  // No copying

// Convert to enumerable without allocating until iteration
IEnumerable<int> enumerable = result.AsEnumerable();

Why This Actually Matters

Type Safety Prevents Runtime Crashes

// Before: invisible errors
public User GetUser(string id);  // Can throw 5 different exceptions

// After: explicit errors
public Result<User, DatabaseError> GetUser(string id);  // Crystal clear

Composability Beats Brittleness

// Exception version: fragile
try { return Step1(); }
catch { try { return Step2(); } catch { ... } }

// Result version: composable
return Step1()
    .AndThen(Step2)
    .AndThen(Step3);

Compiler Enforcement Beats Documentation

// This compiles, crashes at runtime
var user = GetUser(id);
Console.WriteLine(user.Name);  // 💥

// This won't compile until you handle errors
var result = GetUser(id);
// Must call Match, Unwrap, UnwrapOr, etc.

When To Use What

Use Result:

API calls that can fail
Database operations
File I/O operations
Business logic validations
Any operation with expected failure modes

Use Option:

Instead of returning null
Dictionary lookups
Finding items in collections
Configuration values that might not exist
Optional parameters or fields

Still use exceptions:

Programming errors (ArgumentNullException)
Truly exceptional situations (OutOfMemoryException)
Third-party code boundaries you don't control

Getting Started

dotnet add package SharpResults

Start simple:

using SharpResults;

public Result<int, string> ParseAge(string input)
{
    return int.TryParse(input, out var age) && age > 0
        ? age
        : "Invalid age";
}

// Chain operations
var result = ParseAge("25")
    .AndThen(age => ValidateAge(age))
    .Map(age => new User { Age = age });

// Handle both cases
result.Match(
    ok: user => Console.WriteLine($"Created: {user.Age}"),
    err: error => Console.WriteLine($"Failed: {error}")
);

What You Get

Result - Rust-style error handling
Option - Null safety without nullable types
Pattern matching - Deconstruction and switch expressions
LINQ integration - Query syntax support
Full async/await - Task and ValueTask support
Safe collections - FirstOrNone, GetValueOrNone, PopOrNone, etc.
NumericOption - Math operations on optional numbers (.NET 7+)
Unit type - For void-like operations
Zero dependencies - No external packages
JSON serialization - Built-in System.Text.Json support
Performance - Struct-based, stack-allocated
Immutable collections - Support for ImmutableStack, ImmutableQueue, etc.
Concurrent collections - Thread-safe operations

Built for .NET 8+, MIT licensed, zero dependencies.

My Honest Take

Is this more verbose than throwing exceptions? Sometimes, yeah. But it's honest verbosity. The error handling is visible. The compiler helps you. And most importantly, you stop getting paged at 2 AM because someone forgot a try-catch.

Rust proved that making errors explicit makes code more robust. SharpResults brings that lesson to C#. Your code becomes more maintainable, your bugs become compile-time errors, and your function signatures actually tell the truth about what can go wrong.

Try it on one feature. See how it feels. Let the compiler guide you. I think you'll find that explicit error handling is actually liberating—not limiting.

Links:

Have you tried similar patterns in production? What's your take on explicit vs exception-based error handling? I'd love to hear your thoughts below! 👇

DEV Community: Safwan Abdulghani

[Boost]

RoomSharp v0.4.3: Production-grade migrations, safe-by-default concurrency, and new companion packages

Safwan Abdulghani ・ Dec 20

RoomSharp v0.4.3: Production-grade migrations, safe-by-default concurrency, and new companion packages

RoomSharp 0.4.3 in one sentence

Highlights

1) Migrations: strict, durable, and transaction-safe

New metadata tables

New migration API: IRoomMigration + MigrationContext

Strict pathing: no gaps, no branching

Dirty-state protection

Cross-process provider locks (implementation detail)

2) RoomSharp.Cli: runtime migrations and tooling from the command line

Install

Project Configuration (room.config.json)

Migration workflow

Safety defaults (why it matters)

Schema export and validation

3) Concurrency: safe by default, parallel when you opt in

Serialized mode (default)

Parallel mode (opt-in, true parallel DB I/O)

Unit of Work: explicit single-connection transactional scope

4) Mapper cache moved to runtime (smaller generated code)

5) RoomSharp.QueryExtensions: ad-hoc SQL without giving up RoomSharp integration

Install

Quick examples

Fluent query builder

Joins with eager loading

Low-level zero-allocation row access: RowReader

Concurrency integration

6) Dependency injection improvements (RoomSharp.DependencyInjection)

Install

Basic registration

Provider shortcuts

Service lifetimes + scoped shorthand

Factory pattern for background services / Blazor Server

7) Reactive queries & change tracking

Enable change tracking + observe a query

Built-in operators

Rx.NET integration

GetValueAsync: await first query result

DataSourceChanged: lightweight change notifications

DataChangeInfo structure

Performance characteristics

9) Provider update: MySQL now uses MySqlConnector

Breaking / behavioral changes

Suggested upgrade checklist

Closing thoughts

Get Started

NuGet Packages

Links

RoomSharp: Source-Generated Data Layer for Modern .NET

The RoomSharp Package Lineup

What Working With RoomSharp Looks Like

Calling DAOs from Your Application

Builder Superpowers

Transactions, Converters, and Relations with Zero Boilerplate

Migrations Without Drama

Raw SQL When You Need It

First-Class ASP.NET Core Integration

Provider Packages Built for Production

Getting Started Today

Rust-Style Error Handling in C# - Why SharpResults Makes Your Code Bulletproof

Why Exceptions Aren't Enough

The Rust Way: Errors Are Just Values

You Literally Can't Ignore Errors

Multiple Ways to Create Results

Working with Results: Your Way

Chain Operations Without the Pyramid

Option: Never Null Again

Safe Collections: No More LINQ Bombs

Result Collection Operations

NumericOption: Math That Can Fail (.NET 7+)

Unit Type: For Void-Like Operations

Option/Result Interop

Bool Extensions: Conditional Options

Full Async/Await Support

Advanced Patterns

JSON Serialization: Just Works

New migration API: `IRoomMigration` + `MigrationContext`

Project Configuration (`room.config.json`)

Low-level zero-allocation row access: `RowReader`