Install the CLI and Packages, Choose a Database Provider, and Verify the Toolchain

Learning outcomes

ServiceHub has a supported version contract; now it needs a toolchain that every developer and CI agent can reproduce. The goal is not “install some NuGet packages until IntelliSense turns green.” We will separate SDK tooling, the EF CLI tool, project design-time services, the relational provider, and the database engine, then verify each layer independently.

1. The toolchain has five separate pieces

A failure in one piece does not imply the others are broken. For example, dotnet ef --version can succeed even when the startup project lacks Microsoft.EntityFrameworkCore.Design. Conversely, a project can compile and run normal EF queries without dotnet-ef installed because the CLI tool is not a runtime dependency.

2. Prefer a local dotnet-ef tool for repository reproducibility

A global tool is convenient on a personal workstation, but its version can drift independently from the repository. A local tool is declared in .config/dotnet-tools.json and restored with the repository. That makes CI and developer setup explicit.

dotnet new tool-manifestdotnet tool install dotnet-ef --version 10.0.11dotnet tool list --localdotnet ef --version

Commit the tool manifest, not a machine-specific tool cache. A new checkout can run dotnet tool restore. If an organization standardizes a global tool, record its required version and still verify it in CI; “global” should not mean “unknown.”

3. Choose the provider from the production contract, not from LINQ familiarity

The provider determines database-specific type mappings, SQL generation, function translation, migrations operations, value generation, concurrency capabilities, and many diagnostics. Provider selection is therefore an architectural decision, not a cosmetic connection-string switch.

SQLite is the mandatory Chapter 01 provider because it is free and requires no server process. That does not make SQLite a universal stand-in for a production SQL Server or PostgreSQL database. Chapter 23 explains why provider-realistic integration tests matter.

4. Add aligned project packages

Create the project with the course target framework, then add the provider and design-time package at the same EF patch. Explicit versions make the lab reproducible even if a newer servicing patch is released later.

dotnet new console -n ServiceHub.EfLab -f net10.0cd ServiceHub.EfLabdotnet add package Microsoft.EntityFrameworkCore.Sqlite --version 10.0.11dotnet add package Microsoft.EntityFrameworkCore.Design --version 10.0.11dotnet restoredotnet builddotnet list package

The SQLite provider pulls the relational/core packages it needs. Inspect the resolved package graph rather than adding every EF package you have heard of. Microsoft.EntityFrameworkCore.Tools is for Visual Studio Package Manager Console; it is not required just because you use dotnet ef.

5. Verify runtime provider registration separately from tooling

A provider package being present does not configure a DbContext. EF Core needs provider services registered in the context options. For the first probe, build options directly and inspect the provider name.

using Microsoft.EntityFrameworkCore;var options = new DbContextOptionsBuilder<ProbeContext>()    .UseSqlite("Data Source=toolchain-probe.db")    .Options;await using var context = new ProbeContext(options);Console.WriteLine(context.Database.ProviderName);public sealed class ProbeContext(DbContextOptions<ProbeContext> options)    : DbContext(options);

dotnet run should print Microsoft.EntityFrameworkCore.Sqlite. This proves that the built application can construct an EF context with SQLite provider services. It does not prove migrations tooling can construct the context at design time; that is a separate path.

6. Deliberately wrong approach: run migrations without the Design package

Remove or omit Microsoft.EntityFrameworkCore.Design, then ask the EF tool to perform a project-aware design-time operation. The tool can exist and report its own version, yet the project is missing the services it needs.

dotnet remove package Microsoft.EntityFrameworkCore.Designdotnet ef migrations add ToolchainProbe

The exact diagnostic text can change across patches, but it should explain that the startup project does not reference Microsoft.EntityFrameworkCore.Design or otherwise cannot provide required design-time services. The repair is explicit:

dotnet add package Microsoft.EntityFrameworkCore.Design --version 10.0.11dotnet restoredotnet build

Do not respond by reinstalling Visual Studio, deleting every NuGet cache, or installing random global tools. First identify which layer failed: CLI discovery, project restore, build, design-time context creation, provider loading, or database connection.

7. Another common failure: package installed, UseSqlite unavailable

If UseSqlite is unresolved, inspect the provider PackageReference and the using Microsoft.EntityFrameworkCore; namespace before assuming the database is broken. If the compiler error appears only on one machine, compare the resolved package graph and target framework. Compile-time provider-extension discovery occurs before any connection to SQLite.

dotnet --versiondotnet restoredotnet builddotnet list package --include-transitivedotnet tool list --local

8. Design-time context creation is an application-construction problem

Commands such as dotnet ef migrations add need a DbContext instance at design time. In real applications EF tooling may obtain it through the application service provider, a parameterless construction path, or an IDesignTimeDbContextFactory<TContext>. Chapter 2 teaches those patterns in detail. For now, recognize the symptom: a successful build followed by “Unable to create a DbContext” is not the same failure as a missing tool or provider.

Record the full exception and startup-project/target-project selection. Multi-project solutions frequently fail because tooling executes a different startup path than the developer expected.

9. Observe provider SQL with a one-row query

Toolchain verification is stronger when it reaches the database. The following disposable probe creates a SQLite database, inserts one row, then prints the generated query text. EnsureCreated is used only as a prototype probe; migrations become the normal course schema lifecycle beginning in Lesson 4/Chapter 15.

using Microsoft.EntityFrameworkCore;var options = new DbContextOptionsBuilder<ProbeContext>()    .UseSqlite("Data Source=toolchain-probe.db")    .LogTo(Console.WriteLine, Microsoft.Extensions.Logging.LogLevel.Information)    .Options;await using var db = new ProbeContext(options);await db.Database.EnsureDeletedAsync();await db.Database.EnsureCreatedAsync();db.Items.Add(new ProbeItem { Name = "provider-ok" });await db.SaveChangesAsync();var query = db.Items.Where(x => x.Name == "provider-ok");Console.WriteLine(query.ToQueryString());Console.WriteLine(await query.CountAsync());public sealed class ProbeContext(DbContextOptions<ProbeContext> options) : DbContext(options){    public DbSet<ProbeItem> Items => Set<ProbeItem>();}public sealed class ProbeItem{    public int Id { get; set; }    public string Name { get; set; } = "";}

Expected evidence includes provider command logs, a SQLite-style quoted table/column query, and a result count of one. Exact command formatting is provider/patch dependent. Treat the output as observed behavior from your declared environment, not universal SQL text.

10. Hands-on lab: build the repository-local toolchain from zero

mkdir ServiceHubEfCoursecd ServiceHubEfCoursedotnet new globaljson --sdk-version 10.0.400 --roll-forward latestPatchdotnet new tool-manifestdotnet tool install dotnet-ef --version 10.0.11dotnet new console -n ServiceHub.EfLab -f net10.0cd ServiceHub.EfLabdotnet add package Microsoft.EntityFrameworkCore.Sqlite --version 10.0.11dotnet add package Microsoft.EntityFrameworkCore.Design --version 10.0.11dotnet restoredotnet buildcd ..dotnet tool restoredotnet ef --version

Verification checklist

• global.json and .config/dotnet-tools.json exist at the repository root.
• dotnet --version resolves according to the repository SDK policy.
• dotnet ef --version reports 10.0.11.
• The project targets net10.0 and resolves SQLite/Design 10.0.11.
• dotnet build succeeds before any database command is attempted.
• A runtime probe reports Microsoft.EntityFrameworkCore.Sqlite.
• You can explain why missing Design services is different from a provider package or database-connection failure.

11. Production judgment and next bridge

Toolchain reproducibility is a supply-chain and operations concern. Pin what must be reproducible, restore packages/tools from approved sources, patch supported components deliberately, and keep project/runtime/design-time responsibilities separate. For provider adoption, evaluate maintainer, license, support, EF major compatibility, database versions, and the behaviors your application actually uses.

Nothing in this lesson requires a paid database or IDE. SQL Server, PostgreSQL, MySQL/MariaDB, and Oracle will appear when their semantics matter, but the mandatory path remains free/local. Lesson 4 now uses this verified SQLite toolchain to build the first real ServiceHubContext, migration, insert, LINQ query, SaveChangesAsync, and generated-SQL inspection.

Authoritative references

• Installing Entity Framework Core — provider packages plus CLI/PMC tooling distinctions
• EF Core tools reference (.NET CLI) — tool installation, restore, migrations, scaffolding, and design-time commands
• Database providers — provider ecosystem, maintainers, and major-version compatibility warning
• SQLite provider — Microsoft-maintained SQLite provider and limitations
• SQL Server provider — Microsoft SQL Server/Azure SQL provider
• dotnet tool install — global/local .NET tool installation semantics
• dotnet-ef 10.0.11 — current stable tool package
• Microsoft.EntityFrameworkCore.Design 10.0.11 — current stable design-time package