SQL Table to C# Entity Generator

How to use this tool

1. Paste a CREATE TABLE script into the input editor.
2. Choose records or classes, toggle nullable reference types, and pick a data-access style.
3. Click Generate.
4. Copy the output — for Fluent API, register the generated configuration class with modelBuilder.ApplyConfigurationsFromAssembly(typeof(YourDbContext).Assembly); in your DbContext.OnModelCreating.

What this tool generates

Paste a CREATE TABLE script and get a ready-to-use C# entity class or record, with the column types mapped to their .NET equivalents and, optionally, EF Core configuration as data annotations or a separate IEntityTypeConfiguration<T> class. It runs entirely within your active Blazor Server session — your schema is processed in-memory as part of this page's live connection and is never sent to a separate API, written to disk, or logged.

Before / after: what changes crossing from SQL to C#

With the default options (class, no nullable reference types, no EF Core config), this is the table definition your database sees — the before:

CREATE TABLE Products (
    Id INT PRIMARY KEY IDENTITY(1,1),
    Name NVARCHAR(100) NOT NULL,
    Description NVARCHAR(500) NULL,
    Price DECIMAL(10,2) NOT NULL,
    IsActive BIT NOT NULL DEFAULT 1,
    CreatedAt DATETIME2 NOT NULL DEFAULT GETUTCDATE()
)

and this is the entity your application code sees — the after:

public class Products
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Description { get; set; }
    public decimal Price { get; set; }
    public bool IsActive { get; set; }
    public DateTime CreatedAt { get; set; }
}

What changed, and why: INT PRIMARY KEY IDENTITY becomes a plain int Id — the identity/key behaviour moves to attributes or Fluent config, not the property type. NVARCHAR(100) NOT NULL becomes string Name with an = string.Empty; default, since a non-nullable reference-type column needs some default to satisfy C# without actually being nullable. NVARCHAR(500) NULL becomes plain string Description here because the Nullable reference types toggle is off — value-typed columns like DECIMAL and BIT always reflect their real NULL/NOT NULL regardless of that toggle, but reference types only get a ? when you turn it on, since the toggle is a single on/off switch for every reference-type property, not a per-column decision. Turning on Data annotations adds [Key] above Id, [DatabaseGenerated(DatabaseGeneratedOption.Identity)] for the IDENTITY column, and [MaxLength(100)] above Name.

Data annotations vs Fluent API

Choosing Data annotations decorates the entity's own properties directly; choosing Fluent API generates a separate IEntityTypeConfiguration<T> class instead, keeping the entity a plain POCO:

Composite primary keys

A table-level PRIMARY KEY (ColA, ColB) constraint is detected and both columns are marked as key columns. With Data annotations, this emits a class-level [PrimaryKey(nameof(ColA), nameof(ColB))] attribute (EF Core 7+, from the Microsoft.EntityFrameworkCore namespace) rather than [Key] on each property, since System.ComponentModel.DataAnnotations's own [Key] attribute doesn't support composite keys. With Fluent API, it emits builder.HasKey(x => new { x.ColA, x.ColB });.

One gap worth knowing: foreign keys and indexes

This generator reads column definitions and a single composite PRIMARY KEY (...) constraint if present. It does not currently read FOREIGN KEY, UNIQUE, CONSTRAINT, or INDEX clauses — those lines are recognized and skipped rather than misparsed as columns, but you'll need to add navigation properties and relationship configuration by hand.