Skip to main content

How to start

This is written for a configuration developer: someone building their own business application on the Kandra platform. You do not need — and by default won't have — a checkout of the Kandra platform's own source. Your configuration is its own self-contained git repo, consuming Kandra.* purely as NuGet packages.

Prerequisites​

  • .NET SDK matching net10.0.
  • Access to the Kandra-Erp NuGet feed. Kandra's packages are published to a private GitHub Packages feed, not nuget.org. You need a GitHub personal access token with read:packages scope, set as the GITHUB_PACKAGES_TOKEN environment variable — ask whoever manages your organization's Kandra-Erp access to issue you one. Without it, dotnet restore on a scaffolded configuration fails.

1. Install the scaffolding tools​

dotnet new install Kandra.ConfigTemplate

Optionally, also install the interactive wizard (a friendlier front end over the same template — it does no file manipulation of its own, it just prompts you and runs the dotnet new kandra-config command below for you):

dotnet tool install --global Kandra.ConfigCreateTool

2. Scaffold your configuration​

dotnet new kandra-config -n Acme --IncludeSqlite

or, with the wizard installed:

kandra-new-config
  • -n <Name> — your configuration's name. Every project in the scaffold is prefixed with it (Acme.Domain, Acme.Forms, Acme.WebApi, ...).
  • --IncludeSqlite (default true), --IncludeSqlServer (default false), --IncludePostgres (default false) — pick one or more EF Core providers. Picking none prints a warning and skips the restore step instead of leaving you with a solution that won't compile.

This produces an empty, buildable, 11-project solution — the same project shape as KandraWms (the platform team's own reference configuration), with every domain-specific piece stripped out, referencing the Kandra platform purely via NuGet PackageReference. There is no platform source anywhere in your new repo — see Overall architecture for exactly what that 11-project shape looks like.

3. Restore, build, run​

cd Acme
dotnet restore
dotnet build Acme.slnx
dotnet run --project src/Acme.WebApi

It starts empty — no Dictionaries, Documents, Reports, Registers, or Data Processors yet — but it's fully runnable as scaffolded: you'll see a working login and an empty nav menu.

4. Add your first entity — use the shipped skills​

Your scaffolded repo ships its own .claude/skills/ (one skill per entity kind: create-dictionary, create-document, create-register, create-report, create-data-processor, create-constant, plus create-handler, create-local-handler, post-to-accounting, add-account-subconto-field, add-interface-node, create-print-form, convert-dictionary-to-hierarchical) and its own CLAUDE.md, written specifically for someone building on this scaffold — not the same file as the platform team's own CLAUDE.md. If you're using Claude Code, prefer invoking these skills over hand-rolling an entity's shape from scratch — that's the explicit guidance the scaffold ships with, not just a suggestion from this site. The "Creating a..." guides in this section give you the conceptual background each skill assumes; the skill itself does the mechanical work in your repo.

Running tests​

dotnet test Acme.slnx

One smoke test ships by default, proving the checked-in migrations apply cleanly against SQLite in-memory — see Testing.

Database migrations​

See Database migrations — your scaffolded repo already ships the manifest kandra-migrate needs, so that's the tool to reach for; raw dotnet ef per provider is the fallback if the tool isn't installed in your setup yet.

Exploring the platform's own reference configuration (optional)​

Everything above is self-contained — you never need the Kandra platform's own source to build a configuration. The skills' worked examples intentionally reuse real entity names from a previously-built configuration (each skill says so up front) rather than a fabricated generic example, specifically so you're looking at verified working code even without that access. If you want to go further and read the platform team's own reference configuration source directly, that means access to their internal monorepo — separate from the packages feed above, and something most configuration developers won't need.

Where to go next​