DEV Community: GANESH KUMAR

Send emails in ASP.NET Core with SendGrid and a background queue

GANESH KUMAR — Wed, 14 Oct 2026 17:43:03 +0000

Customers expect an email the moment they order, and another each time the order status changes. The first version most of us write sends the email right inside the checkout request. It works until the email provider is slow, or down, and suddenly checkout is slow, or fails, for a reason that has nothing to do with the order.

Here's how to send order emails with SendGrid in ASP.NET Core, with simplified code. Order and status-update emails are part of eCommerceMVCCore, my ASP.NET Core e-commerce platform, so this is a problem I've spent time on.

Rule one: an email must never fail an order

By the time you send the confirmation, the payment is captured and the order is saved. If the email throws, the customer must still see "Thank you for your order", not an error page. So the checkout only queues the email; something else sends it.

A small in-memory queue

System.Threading.Channels makes a simple, fast queue:

public record EmailMessage(string To, string Subject, string Html);

public class EmailQueue
{
    private readonly Channel<EmailMessage> channel =
        Channel.CreateBounded<EmailMessage>(new BoundedChannelOptions(1000)
        {
            FullMode = BoundedChannelFullMode.Wait
        });

    public ValueTask EnqueueAsync(EmailMessage message) => channel.Writer.WriteAsync(message);
    public IAsyncEnumerable<EmailMessage> ReadAllAsync(CancellationToken ct) => channel.Reader.ReadAllAsync(ct);
}

await emailQueue.EnqueueAsync(new EmailMessage(
    order.Email,
    $"Order #{order.Id} confirmed",
    await templates.RenderAsync("OrderConfirmation", order)));

A background service that sends

public class EmailSenderService(EmailQueue queue, IServiceScopeFactory scopes, ILogger<EmailSenderService> log)
    : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await foreach (var message in queue.ReadAllAsync(stoppingToken))
        {
            try
            {
                using var scope = scopes.CreateScope();
                var sender = scope.ServiceProvider.GetRequiredService<IEmailSender>();
                await sender.SendAsync(message, stoppingToken);
            }
            catch (Exception ex)
            {
                log.LogError(ex, "Couldn't send email to {To}: {Subject}", message.To, message.Subject);
            }
        }
    }
}

The try/catch is inside the loop on purpose. One failed email is logged, and the service keeps sending the rest.

The scope matters too. A BackgroundService is a singleton, so anything scoped, like a DbContext or a settings service, has to come from a fresh scope.

Sending through SendGrid

The official SendGrid NuGet package keeps it short:

public class SendGridEmailSender(ISettingsService settings) : IEmailSender
{
    public async Task SendAsync(EmailMessage m, CancellationToken ct)
    {
        var client = new SendGridClient(await settings.GetAsync("SendGridApiKey"));
        var from = new EmailAddress(await settings.GetAsync("FromEmail"), await settings.GetAsync("StoreName"));
        var msg = MailHelper.CreateSingleEmail(from, new EmailAddress(m.To), m.Subject, null, m.Html);

        var response = await client.SendEmailAsync(msg, ct);
        if (!response.IsSuccessStatusCode)
            throw new InvalidOperationException($"SendGrid returned {(int)response.StatusCode}: {await response.Body.ReadAsStringAsync(ct)}");
    }
}

SendEmailAsync doesn't throw on a rejected email; it returns the status. Check IsSuccessStatusCode, or failures will pass silently. The most common one is a 403 because the sender address isn't verified.

I read the API key from database-backed settings, so the store owner can paste it into the admin dashboard instead of editing config files.

Status-update emails

When an admin moves an order from "Placed" to "Shipped", the same queue sends the update. Keep the send out of the status change itself: save the new status first, then enqueue the email.

See it end to end: with the ASP.NET Core 10 e-commerce source code, customers get an email when they order and each time an admin updates the status.

The trade-off of an in-memory queue

If the app restarts with emails still in the channel, they're lost. For a small store, the risk is low and the simplicity is worth it. If every email must be delivered, use the outbox pattern: write the email to a database table in the same transaction as the order, and have the background service send unsent rows and mark them sent. It survives restarts, and you get a record of every email for free.

Deliverability is half the job

The code is the easy part. To keep order emails out of spam, verify your domain in SendGrid (SPF and DKIM), send from an address on that domain, and include a plain, readable layout. Test with a Gmail and an Outlook address before launch.

FAQ

How do I send email from ASP.NET Core?

Use a provider's library, such as SendGrid's, or an SMTP client, wrap it behind an IEmailSender interface, and send outside the request when you can. eCommerceMVCCore uses SendGrid, with the API key set from the admin dashboard.

Why do my SendGrid emails go to spam?

Usually because the sending domain isn't authenticated. Set up SPF and DKIM through SendGrid's domain authentication, send from an address on that domain, and avoid image-only emails.

Should I use an in-memory queue, Hangfire or an outbox?

An in-memory Channel is simplest but loses queued emails on restart. Hangfire adds persistence, retries and a dashboard. An outbox table guarantees the email is recorded with the order in one transaction.

Get the source code

Order confirmation and status-update emails through SendGrid are part of eCommerceMVCCore. Get the ASP.NET Core 10 e-commerce source code.

Do you use an in-memory queue, an outbox table, or a job library like Hangfire for emails? Tell me in the comments.

ASP.NET Core production checklist: going live with an e-commerce site

GANESH KUMAR — Wed, 14 Oct 2026 17:43:02 +0000

A project that runs perfectly on localhost is set up for development: demo data, a known admin password, placeholder keys, sandbox payments. All of that is helpful locally and dangerous in production.

This is the checklist I ship with eCommerceMVCCore, my ASP.NET Core 10 store. Most of it applies to any ASP.NET Core app going live.

1. Change or remove the demo admin

Seeded demo accounts have published passwords. They're in the README, the docs, sometimes the live demo page. Before launch:

Create your real admin account with a strong password.
Delete the demo admin, or at least change its password and email.
Turn off demo seeding in production, so a fresh database doesn't recreate it.

2. Replace the JWT signing key

If your API issues JWTs, the signing key in development config is a placeholder anyone can read. With it, anyone can mint a valid token for any user, including an admin.

Generate a long random key and keep it out of source control:

# a 64-byte random key, base64-encoded
openssl rand -base64 64

Pass it in through an environment variable (Jwt__Key), your host's secret settings, or a key vault. Never commit it.

3. Point at the production database

Set the provider and connection string through environment variables rather than editing appsettings.json:

DatabaseProvider=SqlServer
ConnectionStrings__SqlServer=Server=...;Database=...;User Id=...;Password=...;Encrypt=True

Use a database user with only the permissions the app needs. And decide how migrations run in production: at startup is fine for a single instance, but a separate deployment step is safer once you scale out.

4. Set up email

Order confirmations and status updates need a real email provider. For SendGrid, that means:

Add your API key in the admin settings (or in configuration).
Verify your sending domain with SPF and DKIM records. Without it, order emails land in spam.
Set the admin notification address.
Place one test order and check the email arrives, including on a mobile mail app.

5. Switch payments from Sandbox to Live

Create live PayPal app credentials. Sandbox ones won't work in production, and live ones should never be used for testing.
Flip the Sandbox / Live switch.
Register the webhook URL for the live app and confirm verification passes.
Make one small real purchase and refund it from the dashboard. It's the only way to know the whole loop works.

Want payments ready to switch on? The ASP.NET Core e-commerce source code has a PayPal Sandbox / Live switch and one-click refunds in the dashboard.

6. HTTPS and security headers

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
    app.UseHsts();
}
app.UseHttpsRedirection();

Make sure ASPNETCORE_ENVIRONMENT is Production. In Development, the detailed error page shows stack traces and configuration details to anyone who triggers an error.

7. Persist Data Protection keys

ASP.NET Core encrypts login cookies and antiforgery tokens with Data Protection keys. In containers or on hosts that reset the file system, the keys vanish on restart and everyone is logged out, or worse, forms start failing. Store them somewhere durable:

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo("/keys"))   // a mounted volume
    .SetApplicationName("my-store");

8. Logging and backups

Send logs somewhere you can search: Application Insights, Seq, or your host's log stream. You'll want them the first time a customer says "my order disappeared".
Turn on automated database backups, and test a restore once. A backup you've never restored is a hope, not a backup.

9. Replace the demo content

Demo products, sample prices, placeholder contact details, the default store name and logo, and the terms and privacy pages. It's easy to miss one, so click through every footer link before launch.

Print it, tick it

None of these steps takes long. Missing one can cost far more than the time it would have taken.

FAQ

How do I deploy an ASP.NET Core app to production?

Publish a Release build, set ASPNETCORE_ENVIRONMENT to Production, pass secrets through environment variables, enable HTTPS, apply migrations and set up logging. Azure App Service, a Linux server behind Nginx, and Docker all work. eCommerceMVCCore comes with documentation that walks through these steps.

Why are users logged out after every deployment?

The Data Protection keys aren't persisted, so each new instance creates new keys and old cookies can't be read. Store the keys on a mounted volume, in blob storage or in a database.

Is it safe to run with ASPNETCORE_ENVIRONMENT=Development?

No. The developer exception page shows stack traces and configuration details to anyone who triggers an error.

Get the source code

A go-live checklist with step-by-step instructions is part of the documentation for eCommerceMVCCore. Get the ASP.NET Core 10 e-commerce source code and docs.

What's on your go-live list that isn't on mine? Add it in the comments.

ASP.NET Core MVC project structure: a practical layered architecture

GANESH KUMAR — Wed, 14 Oct 2026 17:42:26 +0000

Architecture debates online tend to swing between two extremes: everything in one project, or Clean Architecture with a dozen projects and an interface for every class. For a real e-commerce app I wanted something in between that a new developer could understand in ten minutes.

My solution, eCommerceMVCCore, has five projects. Here's what each does, which way the references point, and the trade-offs.

The five projects

eCommerce.Web        MVC controllers, views, admin dashboard, REST API
eCommerce.Services   business logic: pricing, orders, payments, email
eCommerce.Data       EF Core DbContext, migrations, configurations
eCommerce.Entities   domain classes: Product, Order, Category, PromoCode
eCommerce.Shared     helpers, constants, localization keys

References only point "down":

Web  →  Services  →  Data  →  Entities
  ↘        ↓          ↓
           Shared  ←──┘

Entities and Shared depend on nothing in the solution. Web never touches the DbContext directly; it goes through Services.

Why controllers don't use the DbContext

This is the rule that pays off most. When the website's checkout and the mobile API's checkout both call IOrderService.PlaceOrderAsync, the rules for prices, stock and promo codes exist exactly once:

public class CheckoutController(IOrderService orders) : Controller
{
    [HttpPost]
    public async Task<IActionResult> PlaceOrder(CheckoutForm form)
    {
        var result = await orders.PlaceOrderAsync(User.GetUserId(), form.ToRequest());
        return result.Succeeded
            ? RedirectToAction("Confirmation", new { id = result.OrderId })
            : View("Index", form.WithError(result.Error));
    }
}

The controller translates HTTP into a service call and back. Nothing else.

Why I didn't add a repository layer

EF Core's DbContext is already a unit of work, and each DbSet is already a repository. Wrapping them in IProductRepository with GetById, Add and Update mostly adds code, and it tends to hide the features that make EF Core good: projections, Include, ExecuteUpdateAsync.

Services use the DbContext directly. When a query is reused in several places, it becomes an extension method on IQueryable<Product>, for example .Published() or .InCategory(id), not a repository class.

Entities stay plain

Entities are plain classes with no EF attributes. Mapping lives in Data, in IEntityTypeConfiguration<T> classes:

public class ProductConfiguration : IEntityTypeConfiguration<Product>
{
    public void Configure(EntityTypeBuilder<Product> b)
    {
        b.Property(p => p.Price).HasPrecision(18, 2);
        b.HasIndex(p => p.Sku).IsUnique();
    }
}

That keeps Entities free of database concerns, which matters when one model has to work on SQL Server, PostgreSQL, MySQL and SQLite.

View models live in Web

Views never get entities directly. A ProductDetailsViewModel contains exactly what the page shows. That avoids accidentally rendering fields you didn't mean to, and stops model binding from writing to properties like Price or IsAdmin that a form should never set (the over-posting problem).

Browse the structure: the eCommerceMVCCore source code is 100% C# and Razor, organised exactly like this.

What I deliberately left out

MediatR and CQRS. Useful in big systems, but for this app it would double the number of classes without changing behaviour.
A separate Application and Domain layer. Services plays both roles. If it grows too big, it can be split by feature later.
Interfaces for everything. Services that need to be swapped or mocked get one, like IPaymentGateway or IEmailSender. Plain helpers don't.

Would I structure it differently next time?

Maybe by feature inside each project (Orders/, Catalog/, Payments/) rather than by type (Controllers/, Services/). The project boundaries, though, have held up well through a full .NET 10 upgrade.

FAQ

Do I need the repository pattern with EF Core?

Usually not. DbContext is already a unit of work and each DbSet is a repository. Add your own abstraction only where you really need to swap the data source or hide complex queries.

What's the difference between Clean Architecture and a layered architecture?

Clean Architecture inverts the dependencies, so the core has no reference to infrastructure. A layered architecture lets references point down to the data layer. It's simpler, and fine for most data-driven web apps.

How should I organise an ASP.NET Core solution?

Split by responsibility into a few projects, and organise by feature inside them. eCommerceMVCCore uses five projects: Web, Services, Data, Entities and Shared.

Get the source code

That clean five-project solution, 100% source code, is eCommerceMVCCore. Explore the ASP.NET Core 10 e-commerce platform.

How do you structure your ASP.NET Core apps? Repository layer or not? Let me know in the comments.

ASP.NET Core settings in the database: change config without a redeploy

GANESH KUMAR — Wed, 14 Oct 2026 17:42:24 +0000

appsettings.json is great for things developers change: connection strings, logging levels. It's a poor fit for things a store owner changes: the contact email, whether PayPal is enabled, the shipping fee, the SendGrid key. Asking the owner to edit JSON and redeploy for each of those isn't realistic.

So eCommerceMVCCore, my ASP.NET Core store, keeps those settings in a database table, editable from Dashboard → Configurations. Here's the design, with simplified code.

A simple key/value table

public class Configuration
{
    public int Id { get; set; }
    public string Key { get; set; } = "";
    public string? Value { get; set; }
    public string? Description { get; set; }   // shown in the admin UI
    public bool IsSecret { get; set; }
}

Each row carries a description, so the admin page can explain what "EnablePayPal" or "PayPalClientSecret" does right next to the field. A unique index on Key prevents duplicates.

A cached settings service

Reading the database on every request would be wasteful, so a small service loads all settings once and caches them:

public class SettingsService(AppDbContext db, IMemoryCache cache) : ISettingsService
{
    const string CacheKey = "site-settings";

    public async Task<IReadOnlyDictionary<string, string?>> GetAllAsync() =>
        (await cache.GetOrCreateAsync(CacheKey, async entry =>
        {
            entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(30);
            return await db.Configurations.AsNoTracking()
                .ToDictionaryAsync(c => c.Key, c => c.Value);
        }))!;

    public async Task<string?> GetAsync(string key) =>
        (await GetAllAsync()).GetValueOrDefault(key);

    public async Task<bool> GetBoolAsync(string key) =>
        bool.TryParse(await GetAsync(key), out var b) && b;

    public void Invalidate() => cache.Remove(CacheKey);
}

When the admin saves a setting, call Invalidate(). The next request reloads fresh values, and the change is live immediately.

The 30-minute expiry is a safety net. If you run more than one instance, a memory cache is per instance, so other instances pick up the change when their cache expires. For instant changes across a farm, use a distributed cache or a change-notification message.

Never send secrets back to the browser

Some settings are secrets: the PayPal client secret, the SendGrid API key. The admin page should let you set them, but never show them:

When rendering the form, show a masked placeholder such as •••••••• for secret rows, never the real value.
When saving, treat an empty secret field as "keep the current value".

foreach (var input in form.Settings)
{
    var row = await db.Configurations.SingleAsync(c => c.Key == input.Key);
    if (row.IsSecret && string.IsNullOrWhiteSpace(input.Value))
        continue;                       // left empty: keep the existing secret
    row.Value = input.Value?.Trim();
}
await db.SaveChangesAsync();
settings.Invalidate();

That way a secret never travels to the browser, never shows in the page source, and isn't wiped by accidentally saving the form.

Encrypting secret values at rest is a good next step. ASP.NET Core's Data Protection API (IDataProtector.Protect and Unprotect) does it in a few lines, as long as the key ring is persisted somewhere that survives restarts.

See the settings page: the eCommerceMVCCore admin dashboard lists each setting with its description, and secrets stay masked.

Who can change what

Settings change how the store takes money, so the page is restricted to the Administrator role, not Moderators:

[Authorize(Roles = "Administrator")]
public class ConfigurationsController : Controller { ... }

The same idea for translations

UI translations work the same way: a table of key, culture and text, loaded into a cache and edited from the dashboard. Admins can fix a typo in the Arabic checkout page, or import a whole language pack, without touching code.

What stays in appsettings.json

Anything needed before the database is reachable stays in configuration: the connection string, the database provider, the JWT signing key and logging. Database settings are for the business; file settings are for the infrastructure.

FAQ

Should settings live in appsettings.json or the database?

Infrastructure settings that are needed before the database is reachable, such as connection strings, signing keys and logging, belong in configuration. Business settings that the owner changes belong in the database.

How do I change ASP.NET Core settings without restarting?

For files, reloadOnChange plus IOptionsMonitor picks up edits. For database settings, cache them and invalidate the cache when they're saved, as shown above.

How should I store API keys in ASP.NET Core?

User secrets in development; environment variables or a key vault in production. If keys live in the database, encrypt them with the Data Protection API and never send them back to the browser. In eCommerceMVCCore, the PayPal and SendGrid secrets are masked in the dashboard after saving.

Get the source code

Database-backed settings and translations, editable from the admin dashboard with secrets masked, are part of eCommerceMVCCore. Get the ASP.NET Core 10 e-commerce source code.

Where do you draw the line between file configuration and database settings? I'd like to hear your rule.

Prevent overselling in EF Core: concurrency-safe stock updates

GANESH KUMAR — Wed, 14 Oct 2026 17:41:52 +0000

Stock tracking looks like the easiest part of an online store. Every product has a quantity, and each order subtracts from it. Then a sale goes live, two people buy the last item in the same second, and you've sold something you don't have.

Here's why the obvious code fails, and the small change that fixes it on SQL Server, PostgreSQL, MySQL and SQLite alike. Stock tracking is a core part of eCommerceMVCCore, my ASP.NET Core e-commerce platform, so it's a problem I've had to think through. The code is simplified.

The obvious code

var product = await db.Products.FindAsync(productId);
if (product.StockQuantity < quantity)
    return Fail("Not enough stock.");

product.StockQuantity -= quantity;
await db.SaveChangesAsync();

Run it for two requests at once with one item in stock:

Request A reads StockQuantity = 1. The check passes.
Request B reads StockQuantity = 1. The check passes.
A saves 0.
B saves 0.

Two orders, one item, and the stock says 0 as if nothing went wrong. It's the classic lost update, and nothing in that code will warn you.

Fix 1: a conditional update

Let the database check and subtract in one statement:

var updated = await db.Products
    .Where(p => p.Id == productId && p.StockQuantity >= quantity)
    .ExecuteUpdateAsync(s => s.SetProperty(p => p.StockQuantity, p => p.StockQuantity - quantity));

if (updated == 0)
    return Fail("Sorry, that item just sold out.");

That becomes a single UPDATE ... SET StockQuantity = StockQuantity - @qty WHERE Id = @id AND StockQuantity >= @qty. The database locks the row while it runs, so only one of the two requests can match the WHERE clause. The other updates zero rows and gets a friendly message instead of an order.

This is my default. It's short, fast, needs no schema change, and behaves the same on every provider.

Fix 2: optimistic concurrency

If you'd rather keep the load-modify-save style, add a concurrency token. EF Core then includes the original value in the UPDATE and throws if the row changed in the meantime:

modelBuilder.Entity<Product>()
    .Property(p => p.StockQuantity)
    .IsConcurrencyToken();

try
{
    product.StockQuantity -= quantity;
    await db.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException)
{
    // someone else changed the stock: reload and check again, or tell the shopper
}

On SQL Server you could use a rowversion column instead, but that's SQL Server-specific. Marking the stock column itself as the token works on all four databases.

Multiple items in one order

A cart with three products needs all three decrements to succeed, or none. Wrap them, and saving the order, in one transaction:

await using var tx = await db.Database.BeginTransactionAsync();

foreach (var line in cart.Lines)
{
    var ok = await db.Products
        .Where(p => p.Id == line.ProductId && p.StockQuantity >= line.Quantity)
        .ExecuteUpdateAsync(s => s.SetProperty(p => p.StockQuantity, p => p.StockQuantity - line.Quantity));

    if (ok == 0)
    {
        await tx.RollbackAsync();
        return Fail($"{line.ProductName} doesn't have enough stock left.");
    }
}

db.Orders.Add(order);
await db.SaveChangesAsync();
await tx.CommitAsync();

If anything fails, the rollback puts the earlier lines' stock back.

Building a store? eCommerceMVCCore gives you stock tracking, a low-stock filter and a server-checked checkout in ASP.NET Core 10.

Where payments fit in

With online payments there's a second race: the stock can run out between "Pay" and the payment being captured. My order is: re-check stock, capture the payment, then save the order and decrement stock in one transaction. If that final step fails, refund automatically. I covered that flow in my article on taking PayPal payments safely.

Show low stock before it's zero

The other half of stock is the admin side. A "low stock" filter on the product list, for example StockQuantity <= 5, tells the store owner what to reorder before customers see "sold out".

FAQ

What is a lost update?

Two transactions read the same value, both change it, and the second save overwrites the first. Neither fails, so the bug stays silent until the numbers don't add up.

Should I use ExecuteUpdateAsync or a concurrency token?

ExecuteUpdateAsync (EF Core 7 and later) checks and changes stock in one statement with no retry logic. A concurrency token keeps the load-modify-save style but needs you to catch DbUpdateConcurrencyException and retry. Both work on every major provider.

Should I reserve stock when an item is added to the cart?

Usually not for a small store: reserving at checkout is simpler. Cart reservations need expiry times and clean-up, or abandoned carts lock up stock. eCommerceMVCCore shows stock on every product page and lets admins filter for low stock.

Get the source code

Stock tracking with a low-stock filter in the admin dashboard is part of eCommerceMVCCore. Get the ASP.NET Core 10 e-commerce source code.

Have you been bitten by a lost update in production? Tell me how you found it.

Docker Compose profiles for ASP.NET Core: one file, four databases

GANESH KUMAR — Wed, 14 Oct 2026 17:41:50 +0000

My ASP.NET Core project, eCommerceMVCCore, supports four databases. I wanted anyone, buyer or contributor, to try any of them with one command and no local database install.

The answer was Docker Compose profiles. One docker-compose.yml, one profile per database:

docker compose --profile sqlite up --build
docker compose --profile postgres up --build
docker compose --profile mysql up --build
docker compose --profile sqlserver up --build

Here's how it's put together. The YAML below is simplified.

Profiles in one sentence

A service with profiles: [postgres] only starts when you pass --profile postgres. Services without a profile always start. That lets one file describe four different setups without them all starting at once.

The database services

services:
  postgres:
    image: postgres:17
    profiles: [postgres]
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD:-Dev_Passw0rd!}
      POSTGRES_DB: shop
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d shop"]
      interval: 5s
      retries: 20

  mysql:
    image: mysql:8.4
    profiles: [mysql]
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD:-Dev_Passw0rd!}
      MYSQL_DATABASE: shop
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 5s
      retries: 20

  sqlserver:
    image: mcr.microsoft.com/mssql/server:2022-latest
    profiles: [sqlserver]
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: ${DB_PASSWORD:-Dev_Passw0rd!}
    healthcheck:
      test: ["CMD-SHELL", "/opt/mssql-tools18/bin/sqlcmd -C -S localhost -U sa -P \"$$MSSQL_SA_PASSWORD\" -Q 'SELECT 1'"]
      interval: 10s
      retries: 20

Two details are worth calling out. SQL Server's newer images ship sqlcmd under mssql-tools18, and it needs -C to trust the self-signed certificate. And $$ escapes the dollar sign, so the variable is read inside the container, not by Compose.

One app service per profile

The app needs to wait for a different database in each profile, so I define one app service per profile. A YAML anchor keeps the shared parts in one place:

x-app: &app
  build: .
  ports: ["8080:8080"]

services:
  app-postgres:
    <<: *app
    profiles: [postgres]
    environment:
      DatabaseProvider: PostgreSQL
      ConnectionStrings__PostgreSQL: Host=postgres;Database=shop;Username=postgres;Password=${DB_PASSWORD:-Dev_Passw0rd!}
    depends_on:
      postgres:
        condition: service_healthy

  app-sqlite:
    <<: *app
    profiles: [sqlite]
    environment:
      DatabaseProvider: Sqlite
      ConnectionStrings__Sqlite: Data Source=/data/shop.db
    volumes: ["sqlite-data:/data"]

volumes:
  sqlite-data:

ConnectionStrings__PostgreSQL uses the double underscore that ASP.NET Core maps to ConnectionStrings:PostgreSQL. No config file changes are needed per environment.

Try the profiles: download the ASP.NET Core store with a Docker Compose profile for every database and run docker compose --profile sqlite up --build.

Why the healthcheck matters

Without condition: service_healthy, depends_on only waits for the database container to start, not for the database to accept connections. SQL Server in particular takes several seconds to get ready. The app would start, try to run migrations, fail and exit. With healthchecks, the app starts only when the database answers.

I still keep EF Core's retry logic on for the providers that support it, such as EnableRetryOnFailure() for SQL Server. That covers short network blips in production too, not just the startup race.

SQLite needs a volume

SQLite is just a file. If it lives inside the container, it disappears on every rebuild. A named volume keeps the demo data between runs. It's the profile I recommend for a first try: no database container, fastest start.

Migrations and seeding on startup

On first start, the app applies the right migrations for the chosen provider and seeds demo data. So docker compose --profile sqlite up --build ends with a working store at http://localhost:8080, products and all. How the seeding works is a separate article.

Development defaults, not production settings

The default passwords above are for local use only. For anything public, pass real secrets through an .env file that isn't committed, or through your host's secret store, and don't expose database ports.

FAQ

What are Docker Compose profiles?

Optional groups of services. A service with a profiles list only starts when one of its profiles is active, through --profile or the COMPOSE_PROFILES variable. Services without profiles always start.

How do I make an ASP.NET Core container wait for its database?

Give the database service a healthcheck, and use depends_on with condition: service_healthy on the app. Keep EF Core's retry-on-failure enabled as well, for short outages after startup.

How do I pass a connection string to ASP.NET Core in Docker?

Use an environment variable with a double underscore, such as ConnectionStrings__PostgreSQL. ASP.NET Core maps it to ConnectionStrings:PostgreSQL, which is how eCommerceMVCCore configures each database profile.

Get the source code

This Compose setup ships with eCommerceMVCCore, with a profile for every supported database. Get the ASP.NET Core 10 e-commerce source code with Docker support.

Have you used Compose profiles, or do you keep a separate compose file per setup? Let me know in the comments.

ASP.NET Core JWT and cookie authentication in one project

GANESH KUMAR — Wed, 14 Oct 2026 17:41:16 +0000

My store has two kinds of clients. Shoppers use the website, where a normal Identity login cookie is the right choice. Mobile apps use a REST API, where a cookie is awkward and a bearer token is the norm.

I didn't want two backends, two user tables or two copies of the business logic. Both live in one ASP.NET Core project and share the same services. This is how eCommerceMVCCore, my ASP.NET Core e-commerce platform, does it, with simplified code.

1. Keep Identity cookies as the default

AddIdentity (or AddDefaultIdentity) already registers cookie authentication and makes it the default scheme. Leave that alone. The website keeps working exactly as before.

2. Add JWT bearer as a second scheme

builder.Services.AddAuthentication()
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
    {
        var key = builder.Configuration["Jwt:Key"]!;
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = builder.Configuration["Jwt:Issuer"],
            ValidateAudience = true,
            ValidAudience = builder.Configuration["Jwt:Audience"],
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(key)),
            ValidateLifetime = true,
            ClockSkew = TimeSpan.FromMinutes(1)
        };
    });

Calling AddAuthentication() with no arguments adds the scheme without changing the default.

3. Tell the API controllers to use JWT

Put the scheme on a base controller, so every API controller gets it:

[ApiController]
[Route("api/[controller]")]
[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
public abstract class ApiControllerBase : ControllerBase { }

This also fixes the most common bug in mixed apps. With the cookie scheme, an unauthenticated request gets a 302 redirect to the login page. A mobile app expects a 401, and gets an HTML login page instead. With the JWT scheme on the API controllers, the challenge returns a clean 401.

4. Issue tokens with the same Identity users

The token endpoint checks the password with Identity's SignInManager, then builds a token with the user's roles:

[AllowAnonymous]
[HttpPost("/api/Token")]
public async Task<IActionResult> Token(LoginRequest request)
{
    var user = await userManager.FindByNameAsync(request.UserName);
    if (user is null) return Unauthorized();

    var result = await signInManager.CheckPasswordSignInAsync(user, request.Password, lockoutOnFailure: true);
    if (!result.Succeeded) return Unauthorized();

    var claims = new List<Claim>
    {
        new(JwtRegisteredClaimNames.Sub, user.Id),
        new(ClaimTypes.Name, user.UserName!)
    };
    foreach (var role in await userManager.GetRolesAsync(user))
        claims.Add(new Claim(ClaimTypes.Role, role));

    var creds = new SigningCredentials(
        new SymmetricSecurityKey(Encoding.UTF8.GetBytes(config["Jwt:Key"]!)),
        SecurityAlgorithms.HmacSha256);

    var token = new JwtSecurityToken(
        issuer: config["Jwt:Issuer"],
        audience: config["Jwt:Audience"],
        claims: claims,
        expires: DateTime.UtcNow.AddHours(2),
        signingCredentials: creds);

    return Ok(new { token = new JwtSecurityTokenHandler().WriteToken(token) });
}

Note lockoutOnFailure: true. A token endpoint is a password-guessing target, so it should respect the same lockout rules as the login page.

See the API: the ASP.NET Core REST API in eCommerceMVCCore covers catalog, cart, orders, PayPal and account endpoints, with a Postman collection.

5. Share the services, not the controllers

The MVC CartController and the API CartController are thin. Both call the same ICartService, IOrderService and pricing code. The rules for prices, stock and promo codes live in one place, so the website and the app can't disagree about what an order costs.

Things to get right before production

The signing key. Use a long random secret, kept out of appsettings.json in source control. Environment variables or a secret store are both fine. A placeholder key in production means anyone can mint admin tokens.
Token lifetime. Short-lived tokens limit the damage of a leaked one. If you need long sessions in the app, add refresh tokens rather than making access tokens last for weeks.
CORS. A native mobile app doesn't need CORS, but a browser-based client on another domain does. Allow only the origins you actually use.

Testing it

I ship a Postman collection with the project. The first request calls POST /api/Token and saves the token to a variable, and every other request sends it as Authorization: Bearer .... It's the quickest way to check that the API returns 401s, not login pages.

FAQ

Can ASP.NET Core use cookie and JWT authentication at the same time?

Yes. Register both schemes, keep the cookie as the default, and name the JWT scheme on your API controllers. For more complex rules, a policy scheme with ForwardDefaultSelector can choose the scheme per request.

Why does my ASP.NET Core API return a login page instead of 401?

Because the cookie scheme's challenge is a redirect to the login page. Authenticate API controllers with the JWT bearer scheme, and its challenge returns a plain 401.

Where should I store the JWT signing key?

In environment variables, a secret store or a key vault, never in source control. Use a long random key: at least 256 bits for HS256. The go-live checklist in eCommerceMVCCore includes replacing the placeholder key.

Get the source code

This setup, with catalog, cart, order, PayPal and account endpoints, is part of eCommerceMVCCore. Get the ASP.NET Core 10 source code with the JWT REST API.

Do you keep your API in the same project as the website, or split it out? Tell me in the comments.

ASP.NET Core localization: language URLs (/en, /ar) and RTL layouts

GANESH KUMAR — Wed, 14 Oct 2026 17:41:15 +0000

My ASP.NET Core e-commerce project, eCommerceMVCCore, sells in English, Arabic, French, Spanish and Turkish. Early on, the language lived in a cookie. It worked for shoppers, but search engines saw a single URL with five different languages behind it, and a shared link opened in whatever language the recipient had last used.

Putting the language in the URL fixed both problems: /en/products, /ar/products, /fr/products. Here's the setup, with simplified code.

1. Add the culture to the route

Make the culture the first route segment, with a constraint so random words don't match:

app.MapControllerRoute(
    name: "localized",
    pattern: "{culture:regex(^(en|ar|fr|es|tr)$)}/{controller=Home}/{action=Index}/{id?}");

// "/" on its own redirects to the default language
app.MapGet("/", () => Results.Redirect("/en"));

2. Read the culture from the route

ASP.NET Core ships a RouteDataRequestCultureProvider. Put it first, so the URL wins over cookies and the browser's Accept-Language header:

var cultures = new[] { "en", "ar", "fr", "es", "tr" };

builder.Services.Configure<RequestLocalizationOptions>(options =>
{
    options.SetDefaultCulture("en")
           .AddSupportedCultures(cultures)
           .AddSupportedUICultures(cultures);

    options.RequestCultureProviders.Insert(0, new RouteDataRequestCultureProvider
    {
        RouteDataStringKey = "culture",
        UIRouteDataStringKey = "culture"
    });
});

// after UseRouting, so route values are available
app.UseRequestLocalization();

One catch: the culture provider needs route values, so UseRequestLocalization has to run after UseRouting. If the culture is always en no matter the URL, check the middleware order first.

3. Keep the culture in every generated link

Once the culture is a route value, the tag helpers carry it along automatically for links within the same request. asp-controller="Products" asp-action="Details" on an /ar/... page produces an /ar/... link. For a language switcher, set it explicitly:

<a asp-route-culture="fr" asp-controller="Home" asp-action="Index">Français</a>

4. Flip the layout for right-to-left languages

.NET already knows which cultures are right-to-left. Use it in the layout instead of hard-coding "ar":

@using System.Globalization
@{
    var ui = CultureInfo.CurrentUICulture;
    var dir = ui.TextInfo.IsRightToLeft ? "rtl" : "ltr";
}
<html lang="@ui.TwoLetterISOLanguageName" dir="@dir">

Then load an RTL build of your CSS framework when dir is rtl. Bootstrap has an RTL stylesheet, and the bigger job is your own CSS. Anything written as margin-left or float: right needs a second look. CSS logical properties such as margin-inline-start flip on their own and save a lot of overrides.

See it live: the multilingual ASP.NET Core store switches between /en and /ar with a full right-to-left layout.

5. Tell search engines about the other languages

Add hreflang links to each page so Google shows the right language in each country:

@foreach (var c in new[] { "en", "ar", "fr", "es", "tr" })
{
    <link rel="alternate" hreflang="@c"
          href="@Url.Action(null, null, new { culture = c }, Context.Request.Scheme)" />
}

Things that tripped me up

Numbers and prices. ToString("C") uses the current culture, so a price can suddenly show with a comma as the decimal separator. Decide whether currency formatting follows the language or the store's currency, and format explicitly.
Model binding. Decimal inputs are parsed with the current culture too. A French user typing 12,50 and an English user typing 12.50 both need to work, so test your forms in each language.
Icons with direction. Arrows and "next" chevrons should mirror in RTL. A simple [dir=rtl] .icon-arrow { transform: scaleX(-1); } handles most of them.

Translations from the database

I keep the UI strings in the database, not in .resx files, so translations can be edited and imported from the admin dashboard without a redeploy. That's a separate article, but the routing above works the same either way.

FAQ

How do I add multiple languages to an ASP.NET Core MVC app?

Register localization, configure RequestLocalizationOptions with your supported cultures, choose how the culture is picked (here, from the route), and serve translated strings from .resx files or a database.

Is a URL prefix, a subdomain or a cookie better for SEO?

A URL prefix or a subdomain. Search engines need a separate URL for each language; a cookie hides the other languages from crawlers. A prefix such as /fr is the simplest to run on one domain.

Does Bootstrap support right-to-left layouts?

Yes. Bootstrap 5 ships bootstrap.rtl.min.css, and Bootstrap 4 has separate RTL builds. eCommerceMVCCore uses Bootstrap with an RTL stylesheet for Arabic.

Get the source code

All of this, including five ready language packs and full RTL support, is part of eCommerceMVCCore. Get the multilingual ASP.NET Core 10 e-commerce source code.

Do you put the language in the URL, a subdomain or a cookie? I'd like to hear what worked for you.

PayPal integration in ASP.NET Core: a safe checkout flow with Orders v2

GANESH KUMAR — Wed, 14 Oct 2026 17:40:42 +0000

Adding a PayPal button takes an afternoon. Making sure you never lose money, never ship unpaid orders and never charge for an order you didn't save takes more care.

This is the PayPal checkout flow I use in eCommerceMVCCore, my ASP.NET Core 10 e-commerce platform, with simplified C# code for each step. It works for PayPal accounts and for debit and credit cards through PayPal.

1. Never trust the browser's total

The browser can send any price it likes. Before creating a PayPal order, rebuild the cart on the server from product IDs and quantities, and read prices, discounts and promo codes from your database.

var lines = await cartService.GetLinesAsync(userId);          // product IDs + quantities
var total = await pricingService.CalculateTotalAsync(lines);  // prices from the database
var paypalOrder = await payPal.CreateOrderAsync(total, currency);
return Ok(new { id = paypalOrder.Id });

2. Capture first

After the shopper approves the payment, capture it on the server with PayPal's Orders API (POST /v2/checkout/orders/{id}/capture). Only a successful capture means you were paid.

var capture = await payPal.CaptureOrderAsync(orderId);
if (capture.Status != "COMPLETED")
    return BadRequest("Payment was not completed.");

3. Save the order only after a successful capture

If you save the order before capturing, a failed payment leaves an unpaid order in your dashboard. So save it after the capture:

try
{
    await orderService.CreatePaidOrderAsync(userId, lines, capture.CaptureId);
}
catch (Exception ex)
{
    logger.LogError(ex, "Order save failed after capture {CaptureId}", capture.CaptureId);
    await payPal.RefundCaptureAsync(capture.CaptureId); // POST /v2/payments/captures/{id}/refund
    return Problem("We couldn't save your order, so your payment has been refunded.");
}

4. Refund automatically if saving fails

That catch block is the important part. If the database is down or stock ran out at the last second, the shopper gets their money back automatically instead of waiting on a support email.

See the full flow: the ASP.NET Core PayPal checkout in eCommerceMVCCore includes one-click refunds from the admin dashboard and a Sandbox / Live switch.

5. Keep statuses in sync with verified webhooks

Refunds and disputes can also happen in the PayPal dashboard, outside your app. Subscribe to PayPal webhooks, and verify every webhook's signature with PayPal (POST /v1/notifications/verify-webhook-signature) before you change an order's status. Without verification, anyone can post fake "payment completed" events to your endpoint.

6. Test in Sandbox

Keep a Sandbox / Live switch in your settings, with separate credentials for each. Test the whole flow, including the refund path, in Sandbox. A quick way to test the refund is to make the order save throw on purpose.

Summary

Recalculate the total on the server.
Capture the payment.
Save the order after the capture.
Refund automatically if the save fails.
Verify webhooks before trusting them.

FAQ

Should I use the PayPal JavaScript SDK or a server-side integration?

Both. The JavaScript SDK renders the buttons and handles the buyer's approval. Creating and capturing the order happens on your server through the Orders v2 API, so the server, not the browser, decides the amount.

Can customers pay by card without a PayPal account?

Yes. PayPal's debit and credit card option lets guests pay by card without signing up. On the server, you create and capture the order exactly as you do for a PayPal account payment.

How do I test PayPal payments in ASP.NET Core?

Create a Sandbox app in the PayPal developer dashboard, use its credentials and Sandbox buyer accounts, and test the refund path as well as the happy path. eCommerceMVCCore has a Sandbox / Live switch in its settings for exactly this.

Get the source code

This flow, plus one-click refunds from the admin dashboard, is built into eCommerceMVCCore. Get the ASP.NET Core 10 e-commerce source code with PayPal checkout.

How do you handle the "paid but not saved" case in your apps? Let me know in the comments.

EF Core with SQL Server, PostgreSQL, MySQL and SQLite in one codebase

GANESH KUMAR — Wed, 14 Oct 2026 17:40:40 +0000

When I moved eCommerceMVCCore, my ASP.NET Core e-commerce project, to .NET 10, I wanted buyers to use whichever database they already run. Agencies often have a SQL Server licence, startups like PostgreSQL, cheap hosting usually means MySQL, and SQLite is perfect for a quick local try.

Here's how I made the provider a single config value, and the pitfalls I hit along the way.

Pick the provider from configuration

The app reads one setting, DatabaseProvider, and registers the right EF Core provider. A simplified version:

var provider = builder.Configuration["DatabaseProvider"] ?? "SqlServer";
var connectionString = builder.Configuration.GetConnectionString(provider);

builder.Services.AddDbContext<AppDbContext>(options =>
{
    switch (provider)
    {
        case "SqlServer":  options.UseSqlServer(connectionString); break;
        case "PostgreSQL": options.UseNpgsql(connectionString);    break;
        case "MySQL":      options.UseMySQL(connectionString);     break; // MySql.EntityFrameworkCore
        case "Sqlite":     options.UseSqlite(connectionString);    break;
        default: throw new InvalidOperationException($"Unknown DatabaseProvider '{provider}'.");
    }
});

Fail loudly on an unknown value. A typo that silently falls back to another database is much harder to debug.

Keep migrations per provider

Each provider generates different SQL, so one set of migrations can't serve all four. Keep a separate migrations set for each provider (for example in separate folders or assemblies), and apply the right one at startup:

using var scope = app.Services.CreateScope();
var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
db.Database.Migrate();
// then seed demo data if the database is empty

Running migrations and seeding on first start means a buyer can clone, run and see a working store without a manual setup step.

Pitfalls I hit

Decimal precision. Prices need an explicit precision, or each provider picks its own default:

modelBuilder.Entity<Product>()
    .Property(p => p.Price)
    .HasPrecision(18, 2);

SQLite and decimals. SQLite has no native decimal type. EF Core can't translate some decimal operations, such as ordering or summing in SQL, so test your sorting and totals on SQLite specifically.

PostgreSQL and DateTime. Npgsql maps DateTime to timestamp with time zone and expects UTC values. Store DateTime.UtcNow everywhere and convert for display.

Case sensitivity. PostgreSQL string comparisons are case-sensitive by default, while SQL Server's usual collation is not. A search box that works on SQL Server can miss results on PostgreSQL, so normalise the case in your search queries.

Try it yourself: the complete ASP.NET Core store ships with all four EF Core providers configured and a migration set for each.

Docker makes it easy to test all four

I added one Docker Compose profile per database, so testing a provider is one command:

docker compose --profile postgres up --build   # or sqlserver / mysql / sqlite

Each database container has a healthcheck, and the app waits for it before migrating. That removed the "app started before the database was ready" errors.

Was it worth it?

Supporting four databases costs some extra testing on every change. In return, the project fits into whatever stack a client already has, which matters a lot when you sell source code.

FAQ

Can one EF Core DbContext support multiple database providers?

Yes. The same DbContext and model work with every provider; you choose the provider at startup. What can't be shared is the migrations, because each provider generates different SQL, so keep one migrations set per provider.

Which database is best for an ASP.NET Core e-commerce site?

SQL Server fits teams already on Azure or Windows. PostgreSQL is a strong free choice for production. MySQL is what most budget hosting offers. SQLite is ideal for local development and demos, but not for a busy production store.

How do I switch EF Core from SQL Server to PostgreSQL?

Install Npgsql.EntityFrameworkCore.PostgreSQL, call UseNpgsql instead of UseSqlServer, generate PostgreSQL migrations, and store every DateTime in UTC. eCommerceMVCCore does this with a single DatabaseProvider setting.

Get the source code

The full project is eCommerceMVCCore, a production-ready ASP.NET Core 10 e-commerce platform with a storefront, admin dashboard, REST API and PayPal payments. See the live demo, documentation and source code here.

Questions about any of the pitfalls above? Ask in the comments.

ASP.NET Core promo codes: validating discounts safely with EF Core

GANESH KUMAR — Wed, 14 Oct 2026 17:40:02 +0000

A promo code looks like a small feature: a text box and a percentage. Then a code meant for 100 people gets used 3,000 times, an expired code still works because of a time-zone bug, or a 10% discount turns a $0.05 item into a negative total.

Here's how I model and apply promo codes in eCommerceMVCCore, my ASP.NET Core e-commerce store, with simplified code.

The model

public class PromoCode
{
    public int Id { get; set; }
    public string Code { get; set; } = "";          // stored upper-case
    public DiscountType Type { get; set; }           // Percent or FixedAmount
    public decimal Value { get; set; }
    public decimal MinimumOrder { get; set; }
    public DateTime? StartsAtUtc { get; set; }
    public DateTime? ExpiresAtUtc { get; set; }
    public int? MaxUses { get; set; }                // null = unlimited
    public int TimesUsed { get; set; }
    public bool IsActive { get; set; } = true;
}

Give Code a unique index, and store it upper-case so summer10 and SUMMER10 are the same code on every database. (PostgreSQL compares strings case-sensitively by default, so this matters.)

Validate everything on the server

The browser only ever sends the code. The server looks it up and recalculates the cart from the database, every time the total is shown and again at checkout:

public async Task<PromoResult> ValidateAsync(string input, decimal subtotal)
{
    var code = input.Trim().ToUpperInvariant();
    var now = DateTime.UtcNow;

    var promo = await db.PromoCodes.AsNoTracking().SingleOrDefaultAsync(p => p.Code == code);

    if (promo is null || !promo.IsActive)                  return PromoResult.Invalid("This code isn't valid.");
    if (promo.StartsAtUtc > now)                            return PromoResult.Invalid("This code isn't active yet.");
    if (promo.ExpiresAtUtc <= now)                          return PromoResult.Invalid("This code has expired.");
    if (promo.MaxUses is int max && promo.TimesUsed >= max) return PromoResult.Invalid("This code has been fully used.");
    if (subtotal < promo.MinimumOrder)                      return PromoResult.Invalid($"Spend at least {promo.MinimumOrder:0.00} to use this code.");

    return PromoResult.Valid(promo, CalculateDiscount(promo, subtotal));
}

Store dates in UTC and compare with DateTime.UtcNow. "Expires at midnight" in the admin's time zone should be converted to UTC once, when the code is saved.

Round once, and never go below zero

static decimal CalculateDiscount(PromoCode promo, decimal subtotal)
{
    var discount = promo.Type == DiscountType.Percent
        ? subtotal * promo.Value / 100m
        : promo.Value;

    discount = Math.Round(discount, 2, MidpointRounding.AwayFromZero);
    return Math.Min(discount, subtotal);   // a discount can't make the total negative
}

Use decimal, never double, for money. And round at one well-defined point. Rounding every line and then the total again gives totals that are off by a cent, and payment providers reject orders whose lines don't add up.

Count usage atomically

The classic bug: two shoppers check out at the same moment with the last use of a code. Both read TimesUsed = 99, both pass the check, both save 100.

Fix it with a conditional update, so the database does the check and the increment in one statement:

var updated = await db.PromoCodes
    .Where(p => p.Id == promoId && (p.MaxUses == null || p.TimesUsed < p.MaxUses))
    .ExecuteUpdateAsync(s => s.SetProperty(p => p.TimesUsed, p => p.TimesUsed + 1));

if (updated == 0)
    return CheckoutResult.Failed("This code has just been used up.");

ExecuteUpdateAsync works the same on SQL Server, PostgreSQL, MySQL and SQLite. If the update touches zero rows, someone got there first.

Do this as part of placing the order, in the same transaction as saving it, so a failed order doesn't burn a use.

See it in action: in the ASP.NET Core e-commerce platform, promo codes are managed from the admin dashboard and applied at checkout.

Save what was applied

Store the code and the discount amount on the order itself, not just a link to the promo. If the admin later edits the code from 10% to 20%, old orders and invoices must still show what the customer actually paid.

Small touches that reduce support emails

Explain why a code failed: expired, not active yet, minimum not reached.
Re-validate when the cart changes. Removing an item can drop the subtotal below the minimum.
Let admins deactivate a code instantly instead of deleting it, so order history stays intact.

FAQ

How do I stop a coupon code being used too many times?

Increment the usage count with a conditional update, WHERE TimesUsed < MaxUses, in the same transaction that saves the order. If it updates zero rows, the code is used up.

Should discounts be calculated in JavaScript or on the server?

On the server. JavaScript can show a preview, but the total that's charged must be rebuilt from the database at checkout. In eCommerceMVCCore, prices are re-checked on the server before any payment.

Should I use decimal or double for prices in C#?

Always decimal. double stores binary fractions, so values like 0.1 can't be represented exactly, and totals drift by a cent. Set an explicit precision on money columns too.

Get the source code

Promo codes and discounts, managed from the admin dashboard and checked on the server, are part of eCommerceMVCCore. Get the ASP.NET Core 10 e-commerce source code.

What's the strangest promo-code abuse you've seen? Share it in the comments.

EF Core seed data: demo data that works on the first run

GANESH KUMAR — Wed, 14 Oct 2026 17:40:01 +0000

When someone downloads a project, the first five minutes decide whether they keep going. An empty store with a blank product page is a bad first impression. A store with categories, pictures and 171 products looks like the real thing.

So eCommerceMVCCore, my ASP.NET Core e-commerce project, creates and seeds its database on first run. Here's how to do it without duplicate rows, race conditions or a demo password left in production. The code is simplified.

Migrations first, then seed

Run migrations at startup, then seed only if the data isn't there yet:

using (var scope = app.Services.CreateScope())
{
    var services = scope.ServiceProvider;
    var db = services.GetRequiredService<AppDbContext>();

    await db.Database.MigrateAsync();
    await DemoData.SeedAsync(db,
        services.GetRequiredService<UserManager<AppUser>>(),
        services.GetRequiredService<RoleManager<IdentityRole>>());
}

app.Run();

MigrateAsync creates the database if it doesn't exist, so there's no separate "create database" step.

Make every seed step idempotent

Each step checks before it inserts. Running the app twice must never create two copies of anything:

public static async Task SeedAsync(AppDbContext db, UserManager<AppUser> users, RoleManager<IdentityRole> roles)
{
    foreach (var role in new[] { "Administrator", "Moderator", "User" })
        if (!await roles.RoleExistsAsync(role))
            await roles.CreateAsync(new IdentityRole(role));

    if (await users.FindByNameAsync("admin") is null)
    {
        var admin = new AppUser { UserName = "admin", Email = "admin@example.com", EmailConfirmed = true };
        await users.CreateAsync(admin, "Change_Me_123!");
        await users.AddToRoleAsync(admin, "Administrator");
    }

    if (!await db.Categories.AnyAsync())
    {
        db.Categories.AddRange(DemoCatalog.Categories());
        await db.SaveChangesAsync();
    }

    if (!await db.Products.AnyAsync())
    {
        db.Products.AddRange(DemoCatalog.Products(db.Categories.ToList()));
        await db.SaveChangesAsync();
    }
}

Roles and users go through Identity's managers, not straight into the tables. That way passwords are hashed and normalised names are set correctly.

HasData or runtime seeding?

EF Core's HasData puts seed rows into migrations. It's great for small, fixed lookup data, such as order statuses. For demo data it's a poor fit:

Every change to the demo catalog produces a new migration, with every row in it.
It needs fixed primary keys for every row.
It can't hash passwords or call services.

For 171 products with pictures and translations, runtime seeding is much easier to maintain.

EF Core 9 also added UseSeeding and UseAsyncSeeding on the DbContext options, which run as part of EnsureCreated and Migrate. It's a tidy place for the same idempotent code, if you'd rather keep it next to the context configuration.

Keep the demo data out of C

I keep the catalog in a JSON file that ships with the app and load it in DemoCatalog. A non-developer can edit product names and prices, and the C# stays short. Pictures go in wwwroot with matching file names.

See the result: the ASP.NET Core store demo starts with categories, pictures and 171 demo products, straight from the first run.

Watch out for multiple instances

If two instances of the app start at the same time (two containers, or a scaled-out web app), both can run the "is it empty?" check before either inserts. For production, run migrations as a separate deployment step rather than at app startup. For a demo or a single instance, startup seeding is fine.

The demo admin is a demo account

A seeded admin with a known password is perfect locally and dangerous in production. My go-live checklist starts with "change or remove the demo admin". Better still, read the initial admin password from configuration, or skip creating the admin unless an environment variable asks for it.

FAQ

Should I use HasData or custom seeding in EF Core?

Use HasData for small, fixed lookup data that belongs in migrations. Use runtime seeding, or UseSeeding / UseAsyncSeeding in EF Core 9 and later, for demo data, large catalogs and Identity users.

How do I seed Identity users and roles in ASP.NET Core?

Create a scope at startup, resolve RoleManager and UserManager, and create each role and user only if it doesn't exist yet. Going through the managers hashes passwords and sets normalised names correctly.

Should I run EF Core migrations at application startup?

For a single instance or a demo, yes. With several instances in production, apply them as a deployment step, for example with a migration bundle or a SQL script. eCommerceMVCCore migrates on startup, so the first run needs no setup.

Get the source code

Database creation and seeding on first run, for SQL Server, PostgreSQL, MySQL and SQLite, are built into eCommerceMVCCore. Get the ASP.NET Core 10 e-commerce source code and have a working store running in minutes.

Do you seed in code, from JSON or with SQL scripts? I'd like to know what works for you.