SQL Table to C# Entity Generator

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.

Worked example

With the default options (class, no nullable reference types, no EF Core config), this SQL:

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()
)

generates:

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; }
}

Notice Id maps to int, and value-typed columns always reflect their real NULL/NOT NULL (a NULL DATETIME2 column would generate DateTime? regardless of any toggle). Reference types are different: with the Nullable reference types toggle off, Description — a nullable column — still generates as plain string with no default value, since the toggle controls ? on every reference-type property as a single on/off switch, not per-column. Turn the toggle on and it becomes string? Description { get; set; } instead. 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 with [Key], [Required], [MaxLength], [Column(TypeName = ...)], and [DatabaseGenerated] — quick to read alongside the property it describes, but it couples your domain model to EF Core attributes. Choosing Fluent API instead generates a separate IEntityTypeConfiguration<T> class that your DbContext picks up via modelBuilder.ApplyConfigurationsFromAssembly(...) — your entity class stays a plain POCO with zero EF Core references, and all mapping rules live in one place per entity. Fluent API also supports configuration that data annotations can't express at all, like alternate keys, table splitting, or owned entity types.

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 });.

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.

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.