Setup

Get the solution building, connected to a database, and running locally.

Project Files

The solution lives under eCommerceMVCCore/ and is composed of five projects:

Prerequisites

• .NET 10 SDK
• SQL Server, or SQL Server LocalDB (used by default)

Build & run

cd eCommerceMVCCore
dotnet build eCommerceMVCCore.slnx
dotnet run --project eCommerce.Web

The app listens on http://localhost:5209 (and https://localhost:7156) per eCommerce.Web/Properties/launchSettings.json, in the Development environment.

Publish for production

dotnet publish eCommerce.Web -c Release -o ./publish

Database Setup

The connection string lives in eCommerce.Web/appsettings.json:

"ConnectionStrings": {
  "eCommerceConnectionString": "Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=ecommercedb_core;Integrated Security=True;TrustServerCertificate=True;"
}

On first run, Program.cs automatically:

1. Applies all pending EF Core migrations (context.Database.Migrate()) — creates the database if it doesn’t exist yet
2. Seeds roles (Administrator, Moderator, User), a default admin account, languages, and default site configuration (eCommerceDbSeeder)

Database Providers

The database engine is a configuration choice, not a code change: set DatabaseProvider in appsettings.json to one of SqlServer (default), MySql, PostgreSql, or Sqlite, and point eCommerceConnectionString at a connection string in that provider’s format.

Each provider has its own EF Core migration history under eCommerce.Data/Migrations/<Provider> (SQL Server’s is the original, unprefixed Migrations/ folder) and its own eCommerceContext subclass under eCommerce.Data/Providers/ — see Code Structure for why a migration scaffolded for one provider can’t simply be replayed against another (it bakes in that provider’s column types and auto-increment annotations). All four are wired up centrally in DatabaseProviderConfigurator.

Adding support for another EF Core provider follows the same pattern: a subclass in Providers/, a design-time factory in Providers/DesignTime/ for scaffolding, a case in DatabaseProviderConfigurator and the DatabaseProvider enum, and a scaffolded InitialCreate migration under its own Migrations/<Provider> folder.

Default Roles & Users

Three roles are seeded: Administrator, Moderator, User. A single seeded account has all three:

New storefront registrations (via /register or the API) are assigned the User role only. Roles and per-user role assignment are managed from the dashboard — see Users, Roles & Comments.

Go-Live Checklist

Things worth checking before you point this at real traffic:

• JWT signing key — Jwt:Key in appsettings.json ships as the placeholder CHANGE_THIS_TO_A_LONG_RANDOM_SECRET_BEFORE_PRODUCTION_USE_.... Replace it with a real random secret (and keep it out of source control for production — use environment variables, Azure App Configuration/Key Vault, or a user-secrets equivalent).
• Connection string — point eCommerceConnectionString at your real database, not LocalDB.
• Environment configuration key — a custom setting ("Environment": "LIVE" in appsettings.json, read via ConfigurationsHelper.Environment) is separate from ASP.NET Core’s own ASPNETCORE_ENVIRONMENT. When it’s LIVE, the API area’s exception filter swallows unhandled exceptions into a generic 500 response instead of leaking stack traces — correct for production, but it also means API bugs won’t show up in request/response bodies, only in server-side logs (they aren’t even written to the standard ASP.NET Core diagnostic log — see API → Response Envelope).
• SendGrid — SendGrid_APIKey defaults to empty. Until it’s set (Dashboard → Configurations), account-registration, forgot-password, and order-notification emails will silently fail to send rather than error out loudly.
• Admin email — set AdminEmailAddress so order-placed notifications actually reach someone.
• HTTPS — the app calls UseHsts()/UseHttpsRedirection() outside Development; make sure your deployment target terminates TLS somewhere.
• Error pages — unhandled exceptions and 404s are served from static wwwroot/500.html / 404.html, not a Razor view. Customize those files directly if you want your own branding.