DEV Community: arika

Achieve Prisma-like Developer Experience in EF Core! Introduction to Linqraft

arika — Tue, 02 Dec 2025 00:49:11 +0000

The other day, I released a C# library called Linqraft! In this article, I'd like to introduce it.

Motivation

C# is a wonderful language. With powerful type safety, a rich standard library, and the ability to handle everything from GUI app development to web development, I think it's an excellent language for almost any purpose.

However, there's something about C# that has been frustrating me on a daily basis.

That is: "Defining classes is tedious!" and "Writing Select queries is tedious!"

Since C# is a statically-typed language, you basically have to define all the classes you want to use. While this is unavoidable to some extent, having to define derived classes every time is extremely tedious.
Especially when using an ORM (Object-Relational Mapping) for database access, the shape of data you want must be defined as a DTO (Data Transfer Object) every time, resulting in writing similar class definitions over and over again.

Let's compare this with Prisma, a TypeScript ORM. In Prisma, you can write:

// user type is automatically generated from schema file
const users = await prisma.user.findMany({
  // Specify the data you want with select
  select: {
    id: true,
    name: true,
    posts: {
      // You can also specify related table data with select
      select: {
        title: true,
      },
    },
  },
});

// The type of users automatically becomes: (automatically done for you!)
// This type can also be easily reused
type Users = {
  id: number;
  name: string;
  posts: {
    title: string;
  }[];
}[];

If you try to do the same thing in C#'s EF Core, it looks like this:

// Assume Users type is defined in a separate file
var users = dbContext.Users
    // Specifying the data you want with Select is the same
    .Select(u => new UserWithPostDto
    {
        Id = u.Id,
        Name = u.Name,
        // Child classes are also specified with Select in the same way
        Posts = u.Posts.Select(p => new PostDto { Title = p.Title }).ToList()
    })
    .ToList();

// You have to define the DTO class yourself!
public class UserWithPostDto
{
    public int Id { get; set; }
    public string Name { get; set; }
    public List<PostDto> Posts { get; set; }
}
// Same for child classes
public class PostDto
{
    public string Title { get; set; }
}
// Since we already have a User class, it seems like it could be auto-generated from there...

In this regard, Prisma is clearly easier and more convenient. Even though we're already defining the Users type as a class¹, it feels frustrating to have to manually define derived DTO classes.

The above scale is still tolerable, but it gets even more painful in more complex cases.

var result = dbContext.Orders
    .Select(o => new OrderDto
    {
        Id = o.Id,
        Customer = new CustomerDto
        {
            CustomerId = o.Customer.Id,
            CustomerName = o.Customer.Name,
            // Tedious part
            CustomerAddress = o.Customer.Address != null
                ? o.Customer.Address.Location
                : null,
            // Wrap in another DTO because we don't want to check every time
            AdditionalInfo = o.Customer.AdditionalInfo != null
                ? new CustomerAdditionalInfoDto
                {
                    InfoDetail = o.Customer.AdditionalInfo.InfoDetail,
                    CreatedAt = o.Customer.AdditionalInfo.CreatedAt
                }
                : null
        },
        Items = o.Items.Select(i => new OrderItemDto
        {
            ProductId = i.ProductId,
            Quantity = i.Quantity,
            // Same for arrays. Hard to read...
            ProductComments = i.CommentInfo != null
                ? i.CommentInfo.Comments.Select(c => new ProductCommentDto
                {
                    CommentText = c.CommentText,
                    CreatedBy = c.CreatedBy
                }).ToList()
                : new List<ProductCommentDto>()
        }).ToList()
    })
    .ToList();

// Not shown here, but all DTO class definitions used above also need to be defined

First of all, there are already 5 DTOs in the above example, which is extremely tedious. But even more annoying is the "null checking".
First, EF Core's Select expressions cannot use ?. (null-conditional operator). Specifically, it cannot be used inside Expression<...>.
Therefore, you have to write code that uses ternary operators to check for null, and if it's not null, access the member below it.

For child classes alone, you can simply write o.A != null ? o.A.B : null, but as this gets deeper to grandchild classes and great-grandchild classes, the null checking code keeps growing and becomes very hard to read.

// Unbelievably hard to read
Property = o.A != null && o.A.B != null && o.A.B.C != null
    ? o.A.B.C.D
    : null

The same applies when picking up array values in child classes (which can be null), requiring tedious code.

// Give me a break
Items = o.Child != null
    ? o.Child.Items.Select(i => new ItemDto{ /* ... */ }).ToList()
    : new List<ItemDto>()

What do you think? I really hate this.

What I Wanted

Looking at the Prisma example above again, it has roughly the following features (using TypeScript language features as well):

When you write a query once, the corresponding type is generated
You can write ?. directly in queries without worrying about null checking

After thinking about it, I realized that by combining anonymous types, source generators, and interceptors, these features could be achieved.

Attempting the Implementation

Using Anonymous Types

Are you familiar with C#'s anonymous types? It's a feature where the compiler automatically generates a corresponding class when you write new { ... } as shown below.

// Don't write a type name after new
var anon = new
{
    Id = 1,
    Name = "Alice",
    IsActive = true
};

Some of you may not have used this much, but it's very convenient for defining disposable classes in Select queries.

var users = dbContext.Users
    .Select(u => new
    {
        Id = u.Id,
        Name = u.Name,
        Posts = u.Posts.Select(p => new { Title = p.Title }).ToList()
    })
    .ToList();

// You can access and use it normally
var user = users[0];
Console.WriteLine(user.Name);
foreach(var post in user.Posts)
{
    Console.WriteLine(post.Title);
}

However, as it's called an "anonymous" type, the actual type name doesn't exist, so it cannot be used as method arguments or return values. This restriction is quite painful, so it surprisingly doesn't have many opportunities to shine.

Auto-generating Corresponding Classes

This means that if we create a source generator that automatically generates corresponding classes based on what's defined with anonymous types, wouldn't that work? This is a natural progression. Linqraft achieves exactly this.

Specifically, using a specific method name (SelectExpr) as a hook point, it automatically generates class definitions based on the anonymous type passed as an argument.
Since it would be inconvenient if you couldn't specify the generated class name, it's designed to allow you to specify the class name as a generic type argument.

var users = dbContext.Users
    // In this case, auto-generate a class called UserDto
    .SelectExpr<User,UserDto>(u => new
    {
        Id = u.Id,
        Name = u.Name,
        Posts = u.Posts.Select(p => new { Title = p.Title }).ToList()
    })
    .ToList();

// ---
// A class like this is auto-generated
public class UserDto
{
    public int Id { get; set; }
    public string Name { get; set; }
    public List<PostDto_Hash1234> Posts { get; set; }
}
// Child classes are also auto-generated
// Hash value is automatically added to avoid name conflicts
public class PostDto_Hash1234
{
    public string Title { get; set; }
}

You just look at the elements of the passed anonymous type and generate the corresponding class definition using Roslyn API (though it's quite difficult!). Simple, right?

At this point, we've achieved automatic class generation, but we need to replace the behavior of the called SelectExpr to work like a normal Select.
This is where interceptors come in.

Replacing Processing with Interceptors

Did you know that C# has a feature called interceptors?
Since it's such a niche area, few people probably know about it, but it's a feature that allows you to hook specific method calls and replace them with arbitrary processing.
It was preview-released in .NET 8 and became stable in .NET 9.

Even if I say that, it might be hard to imagine, so let's consider code like this:

// Pattern calling a very time-consuming process with constant values
var result1 = "42".ComputeSomething();   // case 1
var result2 = "420".ComputeSomething();  // case 2
var result3 = "4200".ComputeSomething(); // case 3

Since it's being called with constant values, we should be able to calculate the results at compile time. In such cases, by pre-implementing interceptors in combination with source generators, you can replace calls like this:

// Imagine this class is auto-generated by Source Generator.
// Public level can be file
file static class PreExecutedInterceptor
{
    // Get the hash value of the call site using Roslyn API and attach InterceptsLocationAttribute
    [global::System.Runtime.CompilerServices.InterceptsLocationAttribute(1, "(hash of case1)")]
    // Function name can be random. Arguments and return value should be the same as the original function
    public static int ComputeSomething_Case1(this string value)
    {
        // Pre-calculate and return the result for case 1
        return 84;
    }

    // Same for case 2 and 3
    [global::System.Runtime.CompilerServices.InterceptsLocationAttribute(1, "(hash of case2)")]
    public static int ComputeSomething_Case2(this string value) => 168;

    [global::System.Runtime.CompilerServices.InterceptsLocationAttribute(1, "(hash of case3)")]
    public static int ComputeSomething_Case3(this string value) => 336;
}

While defining as a regular extension method would cause definition duplication, using interceptors allows you to replace different processing for each call site.

Linqraft uses this mechanism to intercept SelectExpr calls and replace them with regular Select.

// Suppose there's a call like this
var orders = dbContext.Orders
    .SelectExpr<Order,OrderDto>(o => new
    {
        Id = o.Id,
        CustomerName = o.Customer?.Name,
        CustomerAddress = o.Customer?.Address?.Location,
    })
    .ToList();

// Example of generated code
file static partial class GeneratedExpression
{
    [global::System.Runtime.CompilerServices.InterceptsLocationAttribute(1, "hash of SelectExpr call")]
    // Need to keep the base anonymous type conversion query, so selector is also taken as an argument (not actually used)
    public static IQueryable<TResult> SelectExpr_0ED9215A_7FE9B5FF<TIn, TResult>(
        this IQueryable<TIn> query,
        Func<TIn, object> selector)
    {
        // Can only receive <TIn> by specification, but we actually know the original type so cast it
        var matchedQuery = query as object as IQueryable<global::Order>;
        // Convert the pseudo-query to a regular Select
        // Map to the auto-generated DTO class created earlier
        var converted = matchedQuery.Select(s => new global::OrderDto
        {
            Id = s.Id,
            // Mechanically replace null-conditional operator with regular ternary operator check
            CustomerName = s.Customer != null ? s.Customer.Name : null,
            CustomerAddress = s.Customer != null && s.Customer.Address != null
                ? s.Customer.Address.Location
                : null,
        });
        // Can only return <TResult> by specification so cast again
        return converted as object as IQueryable<TResult>;
    }
}

This allows users to write queries easily with the feeling of a regular Select!

And Towards Zero Dependencies

With the above measures, all calls to SelectExpr are completely intercepted by separately generated code. As a result, the original SelectExpr body has nothing to do and exists only for editor completion.

If so, if we output that dummy method itself with a source generator, we shouldn't need a reference to Linqraft itself! So that's what we do.

public static void ExportAll(IncrementalGeneratorPostInitializationContext context)
{
    context.AddSource("SelectExprExtensions.g.cs", SelectExprExtensions);
}

const string SelectExprExtensions = $$""""
    {{CommonHeader}}

    using System;
    using System.Collections.Generic;
    using System.Linq;

    /// <summary>
    /// Dummy expression methods for Linqraft to compile correctly.
    /// </summary>
    internal static class SelectExprExtensions
    {
        /// <summary>
        /// Create select expression method, usable nullable operators, and generate instance DTOs.
        /// </summary>
        public static IQueryable<TResult> SelectExpr<TIn, TResult>(this IQueryable<TIn> query, Func<TIn, TResult> selector)
            where TIn : class => throw InvalidException;

        // Other variants are also included here
    }
    """";

Then, if you enable DevelopmentDependency, you can make it a package that's not included in the actual build output at all!

<PropertyGroup>
  <DevelopmentDependency>true</DevelopmentDependency>
</PropertyGroup>

In fact, when you install Linqraft via nuget etc., it should look like this. This means it's a development-only package.

<PackageReference Include="Linqraft" Version="0.4.0">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>

Analyzer for Replacing Existing Code

Now, some of you who have heard the story so far may want to try it right away!
For those people, Linqraft also provides a Roslyn Analyzer that automatically replaces existing Select queries with SelectExpr.
It's very easy to use - just right-click on the Select query part and replace it in one go from Quick Actions.

Summary

So, by using Linqraft to write queries simply like this:

Corresponding DTO classes are automatically generated,
You can write without worrying about null checking,
Plus it has zero dependencies, so it's no different from hand-written code,
Migration is reasonably easy.

// Zero dependencies!
var orders = dbContext.Orders
    .SelectExpr<Order, OrderDto>(o => new
    {
        Id = o.Id,
        // You can write with ?.!
        CustomerName = o.Customer?.Name,
        CustomerAddress = o.Customer?.Address?.Location,
    })
    .ToList();
// OrderDto class and its contents are auto-generated!

I hate to say it myself, but I think we've created a pretty useful library.
Please try it out! If you like it, please give us a star.
https://github.com/arika0093/Linqraft

Side Note

I also put some effort into the introduction web page. Specifically, you can test functionality on the web page!
I also implemented a feature that parses Token information with Roslyn and feeds it into Monaco Editor for syntax highlighting.

Please check this out as well.
https://arika0093.github.io/Linqraft/

Think of it as defining the schema (Prisma's schema) as classes in C#. This part isn't too painful. ↩

Automate Versioning and Releases with Nerdbank.GitVersioning

arika — Mon, 23 Jun 2025 19:05:02 +0000

Managing NuGet package or application versions manually can be tedious. In this article, I'll explain how to automate versioning using Nerdbank.GitVersioning.

What is Nerdbank.GitVersioning?

In short, it's a tool that automatically generates version numbers based on your Git commit history. It's not just for NuGet packages—you can use it with any .NET project. As it's maintained under the dotnet organization, it's an official tool and is widely considered a de facto standard.

Setup

First, install the CLI tool:

dotnet tool install -g nbgv

Next, add Nerdbank.GitVersioning to your project:

dotnet add package Nerdbank.GitVersioning

If you have multiple projects, you can add the following to your Directory.Build.props to enable it for all projects:

<Project>
  <ItemGroup>
    <PackageReference Include="Nerdbank.GitVersioning" Version="3.*" Condition="!Exists('packages.config')" >
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>
</Project>

Finally, create a version.json file at the root of your project.

version.json

This is a simple JSON file. Here's an example configuration:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/Nerdbank.GitVersioning/main/src/NerdBank.GitVersioning/version.schema.json",
  "version": "0.1-alpha.{height}",
  "pathFilters": [
    "src/"
  ],
  "publicReleaseRefSpec": [
    "^refs/heads/main",
    "^refs/heads/release/v\\d+(?:\\.\\d+)?$"
  ],
  "release": {
    "branchName": "release/v{version}"
  },
  "nuGetPackageVersion": {
    "semVer": 2.0
  },
  "cloudBuild": {
    "buildNumber": {
      "enabled": true
    }
  }
}

Let's break down the main parts of the configuration:

version

"version": "0.1-alpha.{height}"

This is the version number template. {height} represents the height of the Git commit history. For example, if you specify 0.1-alpha.{height}, the first commit will be 0.1-alpha.1, the next commit will be 0.1-alpha.2, and so on. When you later run the prepare-release command (explained below), the version will bump to 0.2-alpha.1. This way, version numbers are automatically incremented as you make changes.

pathFilters

"pathFilters": [
    "src/"
    // To exclude only version.json itself:
    // ":!version.json",
]

This property specifies which files should trigger a version update. In the example above, only changes under the src/ directory will cause the version to update. This prevents changes to documentation or configuration files from bumping the version.

Even if you don't want to restrict to a specific directory, it's a good idea to exclude version.json itself from triggering version updates. The reason for this is explained later.

publicReleaseRefSpec

"publicReleaseRefSpec": [
    "^refs/heads/main",
    "^refs/heads/release/v\\d+(?:\\.\\d+)?$"
]

By default, the version number will include a commit hash suffix, like 0.1-alpha.1+8378bd9a46. This is useful for development branches, where the same version number might correspond to different content. However, for release branches (such as main or release/v1.0), you typically want to omit the commit hash. The publicReleaseRefSpec setting controls this behavior.

You can use regular expressions to match dynamically generated branch names, such as:

// Matches release/v1.0, release/v1.1, etc.
"^refs/heads/release/v\\d+(?:\\.\\d+)?$"

release/branchName

"release": {
    "branchName": "release/v{version}"
}

This specifies the naming pattern for release branches. In this example, release branches will be created under the release/ prefix. If you change this pattern, remember to update the corresponding publicReleaseRefSpec as well.

Accessing Version Information in Code

Nerdbank.GitVersioning generates a ThisAssembly class at build time, which you can use to access version info:

internal static partial class ThisAssembly {
    internal const string AssemblyConfiguration = "Debug";
    internal const string AssemblyFileVersion = "1.1";
    internal const string AssemblyInformationalVersion = "1.1.0-alpha.13+1938044917";
    internal const string AssemblyName = "BlazorLocalTime";
    internal const string AssemblyTitle = "BlazorLocalTime";
    internal const string AssemblyVersion = "1.1.0.0";
    internal static readonly global::System.DateTime GitCommitAuthorDate = new global::System.DateTime(638862085700000000L, global::System.DateTimeKind.Utc);
    internal static readonly global::System.DateTime GitCommitDate = new global::System.DateTime(638862089820000000L, global::System.DateTimeKind.Utc);
    internal const string GitCommitId = "19380449172beecd6c25c229e8df9a07ed310cbe";
    internal const bool IsPrerelease = true;
    internal const bool IsPublicRelease = true;
    internal const string RootNamespace = "BlazorLocalTime";
}

To get the version string (e.g., 1.1.0-alpha.13), you can split the AssemblyInformationalVersion:

var v = ThisAssembly.AssemblyInformationalVersion.Split('+')[0];
// "1.1.0-alpha.13"

Creating a Release

Use the nbgv CLI to prepare a release:

nbgv prepare-release

At this point, your branches will split as shown below, with each branch having its own updated version.json:

What’s happening here is that the current branch is branched off into something like release/v0.1, and the version.json version number is updated. A commit updating version.json is automatically generated at this stage, so when you build in this state, the version number will be 0.1.1. If you want your versions to start from 0, it’s a good idea to exclude version.json from triggering version bumps.

If you want to insert an intermediate version name like rc instead of moving directly to 0.1.1, you can do so as follows.

nbgv prepare-release rc
# -> release/v0.1-rc.1

Using with CI/CD

You can automate releases using GitHub Actions.

Get Version Info in GitHub Actions

Use dotnet/nbgv@master to retrieve version info:

- uses: dotnet/nbgv@master
  id: nbgv
- name: Get version
  run: echo "${{ steps.nbgv.outputs.SemVer2 }}"
  # -> 0.1.1

Creating a GitHub Release

Use softprops/action-gh-release to create a GitHub Release. Important points:

Set `fetch-depth` to 0

By default, GitHub Actions checks out only the latest commit. Since Nerdbank.GitVersioning generates version numbers based on the full commit history, you need to fetch all commits. Set fetch-depth to 0 in actions/checkout@v4:

- name: Checkout repository
  uses: actions/checkout@v4
  with:
    fetch-depth: 0

Specify the `prerelease` Option

If the output from nbgv contains a hyphen (e.g., 0.1-alpha.1), you likely want to treat it as a prerelease. Set the option as follows:

prerelease: ${{ contains(steps.nbgv.outputs.SemVer2, '-') }}

Specify `target_commitish`

If you don't specify this, the tag will be attached to the latest commit on the main branch. To create a release on a branch like release/v0.1, explicitly set the commit hash:

target_commitish: ${{ github.ref }}

Set Action Permissions

To create a GitHub Release, the workflow must have contents: write permissions:

permissions:
  contents: write

Complete Example

Taking the above into account, here is a sample GitHub Actions workflow file to publish a NuGet package as a GitHub Release:

name: Release Package to GitHub

on:
  workflow_dispatch:
  push:
    branches:
      - main
      - release/*

permissions:
  contents: write

jobs:
  release-github:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "9.x"

      - uses: dotnet/nbgv@master
        id: nbgv

      - name: Restore dependencies
        run: dotnet restore --locked-mode
      - name: Build
        run: dotnet build --no-restore -c Release
      - name: Generate Nuget Package
        run: dotnet pack --no-build -c Release --output ./artifacts

      - name: Create Release
        id: create_release
        uses: softprops/action-gh-release@v1
        with:
          name: ${{ steps.nbgv.outputs.SemVer2 }}
          tag_name: ${{ steps.nbgv.outputs.SemVer2 }}
          target_commitish: ${{ github.ref }}
          generate_release_notes: true
          files: ./artifacts/*.nupkg
          prerelease: ${{ contains(steps.nbgv.outputs.SemVer2, '-') }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Publishing to NuGet

Publishing to NuGet is similar. Register your NUGET_API_KEY as a GitHub Secret. Since NuGet packages can't be deleted, it's best to use workflow_dispatch to trigger the workflow manually.

name: Release Package to NuGet

on:
  workflow_dispatch:

jobs:
  release-nuget:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "9.x"

      - name: Restore dependencies
        run: dotnet restore --locked-mode
      - name: Build
        run: dotnet build --no-restore -c Release
      - name: Generate Nuget Package
        run: dotnet pack --no-build -c Release --output ./artifacts

      - name: Publish Nuget Package
        run: dotnet nuget push ./artifacts/*.nupkg --source https://api.nuget.org/v3/index.json --api-key $NUGET_API_KEY
        env:
          NUGET_API_KEY: ${{ secrets.NUGET_API_KEY }}

Updating After Release

After running prepare-release, a release branch is created. If you want to update the release, you can cherry-pick commits from main to the release branch. To keep version numbers sequential, you might:

Develop on main as usual.
When you need to update a release, create a branch from the release branch (e.g., v0.1-next).
Cherry-pick the desired commits.
Push the branch and open a PR targeting the release branch.
Use squash merge to keep the commit history clean.
Delete the temporary branch after merging.

Conclusion

This article explained how to automate versioning and releases for .NET projects using Nerdbank.GitVersioning and GitHub Actions. I hope this helps streamline your release process!

Display and Edit DateTime Correctly with Time Zone Awareness in Blazor Server

arika — Mon, 23 Jun 2025 18:17:53 +0000

Blazor Server makes it easy to build web apps with intuitive syntax, but handling dates and times (DateTime) requires special attention.

The Problem

Can you spot the bug in the following code?

<p>@DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss")</p>

The answer: This displays the current time on the server, not the user's local time. The time is formatted according to the Blazor host server's time zone, which may not match the user's time zone.

This bug occurs when the Blazor host server's time zone ≠ user's time zone. It's a subtle issue that's easy to miss during development.

A similar problem arises with date/time input fields. You can't tell which time zone the entered value refers to.

<InputDate Type="InputDateType.DateTimeLocal" @bind-Value="dt" />
@code {
    private DateTime dt { get; set; }
    private void SaveToDatabase()
    {
        // Can't correctly convert to UTC (uses server's TZ)
        var utc = dt?.ToUniversalTime();
    }
}

The Solution

To quickly solve these issues, I created a library called BlazorLocalTime:
https://github.com/arika0093/BlazorLocalTime

You can see a live demo here:
https://arika0093.github.io/BlazorLocalTime/

Setup

First, install BlazorLocalTime from NuGet:

dotnet add package BlazorLocalTime

Next, register the service in your Program.cs:

builder.Services.AddBlazorLocalTimeService();

Finally, add the following component to Routes.razor (or MainLayout.razor, etc.):

@using BlazorLocalTime
<BlazorLocalTimeProvider />

Usage

To display a date/time as a string in the user's local time:

<LocalTimeText Value="@dt" Format="yyyy-MM-dd HH:mm:ss" />

To get the converted value as a DateTimeOffset:

<LocalTime Value="@DateTime.UtcNow" Context="dt">
    @dt.ToString("yyyy-MM-dd HH:mm:ss")
</LocalTime>

You can also convert in code:

@inject ILocalTimeService LocalTimeService
@code {
    private void ButtonClicked()
    {
        var localNow = LocalTimeService.ToLocalTime(DateTime.UtcNow);
    }
}

For input forms:

<LocalTimeForm @bind-Value="Dt" Context="dtf">
    <InputDate Type="InputDateType.DateTimeLocal" @bind-Value="dtf.Value" />
    @* or *@
    <InputDate Type="InputDateType.Date" @bind-Value="dtf.Date" />
    <InputDate Type="InputDateType.Time" @bind-Value="dtf.Time" />
</LocalTimeForm>

@code {
    private DateTime Dt { get; set; } = DateTime.UtcNow;
}

You can use it with component libraries like MudBlazor as well.

How It Works

The approach is similar to this article.

First, you need to get the user's time zone. Since Blazor can't do this directly, you need to use JavaScript:

export function getBrowserTimeZone() {
    return Intl.DateTimeFormat().resolvedOptions().timeZone;
}

Prepare this function in a .js file, then call it from Blazor using JS interop (IJSRuntime). Pass the result to ILocalTimeService. That's why you need to add <BlazorLocalTimeProvider /> somewhere in your app.

public interface ILocalTimeService
{
    TimeZoneInfo? TimeZoneInfo { get; set; }
    public DateTime ToLocalTime(DateTime utcDateTime);
    // and more ...
}

public class BlazorLocalTimeProvider : ComponentBase
{
    private const string JsPath = "./wwwroot/BlazorLocalTimeProvider.razor.js";

    [Inject]
    private IJSRuntime JsRuntime { get; set; } = null!;
    [Inject]
    private ILocalTimeService LocalTimeService { get; set; } = null!;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            await using var module = await JsRuntime.InvokeAsync<IJSObjectReference>("import", JsPath);
            var timeZoneString = await module.InvokeAsync<string>("getBrowserTimeZone");
            var timeZone = TimeZoneInfo.FindSystemTimeZoneById(timeZoneString);
            LocalTimeService.TimeZoneInfo = timeZone;
        }
    }
}

Since you want a separate ILocalTimeService per user, register it as scoped in DI. That's what builder.Services.AddBlazorLocalTimeService() does:

public static class BlazorLocalTimeExtension
{
    public static IServiceCollection AddBlazorLocalTimeService(
        this IServiceCollection services)
    {
        services.AddScoped<ILocalTimeService, LocalTimeService>();
        return services;
    }
}

Now you can convert from UTC using the obtained TimeZoneInfo:

public class LocalTimeService : ILocalTimeService
{
    public DateTime ToLocalTime(DateTime utcDateTime)
        => TimeZoneInfo.ConvertTimeFromUtc(utcDateTime, TimeZoneInfo!);
    // and more...
}

Note: On the initial render (OnInitialized), the JavaScript function hasn't run yet, so conversion will fail. To handle this, an event handler is used to refresh the component when the time zone is set:

public class LocalTimeService : ILocalTimeService
{
    private TimeZoneInfo? _timeZoneInfo;
    public TimeZoneInfo? TimeZoneInfo
    {
        get => _timeZoneInfo;
        set
        {
            _timeZoneInfo = value;
            LocalTimeZoneChanged.Invoke(this, EventArgs.Empty);
        }
    }
    public event EventHandler LocalTimeZoneChanged = delegate { };
}

public sealed partial class LocalTimeText : ComponentBase, IDisposable
{
    [Inject]
    private ILocalTimeService LocalTimeService { get; set; } = null!;

    protected override void OnInitialized()
    {
        LocalTimeService.LocalTimeZoneChanged += OnLocalTimeZoneChanged;
    }

    public void Dispose()
    {
        LocalTimeService.LocalTimeZoneChanged -= OnLocalTimeZoneChanged;
    }

    private void OnLocalTimeZoneChanged(object? sender, EventArgs e)
    {
        StateHasChanged();
    }
}

For input forms, different UI libraries use different types (DateTime, DateOnly, TimeOnly, TimeSpan), so the library provides a wrapper class to handle all cases:

// Class passed to children of <LocalTimeForm>
public record LocalTimeFormValue
{
    private DateTime? _innerValue;

    public required DateTime? Value
    {
        get => _innerValue;
        set
        {
            _innerValue = value;
            ValueChanged.InvokeAsync(value);
        }
    }

    public DateOnly? Date
    {
        get =>
            Value.HasValue
                ? new DateOnly(Value.Value.Year, Value.Value.Month, Value.Value.Day)
                : null;
        set => DateChanged.InvokeAsync(value);
    }

    public TimeOnly? Time
    {
        get =>
            Value.HasValue
                ? new TimeOnly(Value.Value.Hour, Value.Value.Minute, Value.Value.Second)
                : null;
        set => TimeChanged.InvokeAsync(value);
    }

    public TimeSpan? TimeSpan
    {
        get =>
            Value.HasValue
                ? new TimeSpan(Value.Value.Hour, Value.Value.Minute, Value.Value.Second)
                : null;
        set => TimeSpanChanged.InvokeAsync(value);
    }

    public required EventCallback<DateTime?> ValueChanged { get; init; }
    public required EventCallback<DateOnly?> DateChanged { get; init; }
    public required EventCallback<TimeOnly?> TimeChanged { get; init; }
    public required EventCallback<TimeSpan?> TimeSpanChanged { get; init; }
}

Conclusion

Handling time zones in Blazor Server is tricky and repetitive. That's why I made this library. Give it a try!
https://github.com/arika0093/BlazorLocalTime

DEV Community: arika

Achieve Prisma-like Developer Experience in EF Core! Introduction to Linqraft

Motivation

What I Wanted

Attempting the Implementation

Using Anonymous Types

Auto-generating Corresponding Classes

Replacing Processing with Interceptors

And Towards Zero Dependencies

Analyzer for Replacing Existing Code

Summary

Side Note

Automate Versioning and Releases with Nerdbank.GitVersioning

What is Nerdbank.GitVersioning?

Setup

version.json

version

pathFilters

publicReleaseRefSpec

release/branchName

Accessing Version Information in Code

Creating a Release

Using with CI/CD

Get Version Info in GitHub Actions

Creating a GitHub Release

Set fetch-depth to 0

Specify the prerelease Option

Specify target_commitish

Set Action Permissions

Complete Example

Publishing to NuGet

Updating After Release

Conclusion

Display and Edit DateTime Correctly with Time Zone Awareness in Blazor Server

The Problem

The Solution

Setup

Usage

How It Works

Conclusion

Set `fetch-depth` to 0

Specify the `prerelease` Option

Specify `target_commitish`