DEV Community

Cover image for How I Built a Smarter EF Core Migration CLI for Multi-Project Solutions
Adrian Menegatti
Adrian Menegatti

Posted on

How I Built a Smarter EF Core Migration CLI for Multi-Project Solutions

#cli #dotnet #tooling #entityframework

If you've worked with Entity Framework Core in real-world architectures, you've probably written commands like this:

dotnet ef migrations add InitialCreate \
  --project src/MyApp.Infrastructure \
  --startup-project src/MyApp.Api \
  --context AppDbContext
Enter fullscreen mode Exit fullscreen mode

And maybe this worked fine...

Until your architecture started growing.

Suddenly you have:

  • multiple APIs
  • worker services
  • separate infrastructure projects
  • multiple DbContexts
  • different migration folders
  • multiple bounded contexts

And then running migrations becomes surprisingly annoying.

You forget the startup project.

You point to the wrong DbContext.

You generate empty migrations.

You have no quick visibility into which migrations are applied or pending.

And every time you need to run a migration command, you have to remember a long list of arguments.

That friction kept happening to me while working on a multi-tenant SaaS platform I'm currently building, so I decided to build a tool to simplify the workflow.

That tool became EfPilot.

The goal

I wanted migrations to feel like this:

efpilot init
efpilot add
efpilot remove
efpilot update
efpilot status
efpilot diff
Enter fullscreen mode Exit fullscreen mode

Simple.

Minimal.

No memorizing paths.

No repeated boilerplate.

Problem: EF Core works great... until your architecture gets real

In small demos, EF migrations are straightforward.

But modern architectures often look more like this:

apps/
 ├── identity/
 │   ├── api/
 │   ├── application/
 │   ├── infrastructure/
 │   └── domain/
 │
 ├── raterisk/
 │   ├── api/
 │   ├── application/
 │   ├── infrastructure/
 │   └── domain/
 │
 └── worker/
Enter fullscreen mode Exit fullscreen mode

In my case:

separate APIs
infrastructure projects
background workers
multiple DbContexts
multi-tenant architecture

At that point, running migrations manually becomes repetitive and error-prone.

Step 1: Discovering the solution structure

Before detecting any DbContext, the tool first needed to understand the solution structure.

My initial implementation scanned directories looking for a traditional:

*.sln
Enter fullscreen mode Exit fullscreen mode

That worked...

Until I realized newer .NET versions can also generate:

*.slnx
Enter fullscreen mode Exit fullscreen mode

So I updated the solution discovery logic to support both formats.

Once the solution was found, EfPilot could scan all referenced projects automatically.

Step 2: Automatically detecting DbContexts

After discovering all projects in the solution, the next challenge was identifying actual DbContext classes.

My initial implementation parsed .cs files looking for:

class Something : DbContext
Enter fullscreen mode Exit fullscreen mode

That worked well...

Until I started detecting false positives like:

IdentityDbContextFactory
RateRiskDbContextFactory
Enter fullscreen mode Exit fullscreen mode

These implement:

IDesignTimeDbContextFactory

…but they are not actual DbContexts.

So I added filtering logic to exclude them.

That significantly improved detection accuracy.

Step 3: Inferring the correct startup project

This was probably the most interesting problem.

When multiple projects exist, how do you determine which startup project belongs to a DbContext?

I implemented a scoring system based on heuristics:

  • Uses Web SDK → higher score
  • Contains Program.cs
  • Contains appsettings.json
  • Project name contains Api
  • Folder proximity
  • Same bounded context naming

Example:

RateRiskDbContext
→ RateRisk.Api (score: 185)
→ RateRisk.Worker (score: 125)
Enter fullscreen mode Exit fullscreen mode

This made the CLI smart enough to suggest the correct startup project automatically.

Without forcing manual configuration every time.

Step 4: Generating config profiles

After detection, EfPilot creates a configuration file like this:

{
  "version": 1,
  "solution": "MyProject.slnx",
  "profiles": [
    {
      "name": "RateRiskDbContext",
      "dbContext": "RateRiskDbContext",
      "project": "apps/raterisk/infrastructure/RateRisk.Infrastructure.csproj",
      "startupProject": "apps/raterisk/api/RateRisk.Api.csproj",
      "migrationsFolder": null
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

This allows future commands to be extremely simple.

Step 5: Preventing empty migrations

This solved one of my biggest frustrations.

Sometimes you run:

dotnet ef migrations add SomeMigration
Enter fullscreen mode Exit fullscreen mode

...and EF generates an empty migration because nothing actually changed.

Now you have useless migration files polluting your repository.

EfPilot solves this by:

  1. Generating the migration
  2. Inspecting the generated Up() and Down() methods
  3. Detecting if they're empty
  4. Automatically removing the migration

If nothing changed:

No schema changes detected.
Migration automatically removed.
Enter fullscreen mode Exit fullscreen mode

Small feature.

Huge quality of life improvement.

Step 6: Building migration diff preview

This became one of my favorite features.

Before applying migrations, I wanted visibility into what was about to happen.

So I added:

efpilot diff
Enter fullscreen mode Exit fullscreen mode

The tool analyzes migration files and extracts operations like:

  • AddColumn
  • DropColumn
  • CreateTable
  • CreateIndex

Example output:

✔ Add column 'Code' to 'Loans'
✔ Create index 'IX_Loans_Code'
Enter fullscreen mode Exit fullscreen mode

Step 7: Improving CLI UX

I didn't want ugly terminal output.

So I used Spectre.Console to improve the experience.

That gave me:

cleaner headers
colored output
migration tables
applied/pending summaries

Example:

✔ Applied: 5
⏳ Pending: 2
Enter fullscreen mode Exit fullscreen mode

Step 8: Refactoring and testing

At some point I realized I had built a lot of features quickly...

but needed better architecture.

I refactored:

  • command abstractions
  • dependency injection
  • output handling
  • test coverage

This was probably less exciting than the feature work...

but arguably more important.

What I learned

A few things surprised me while building this:

Developer tooling UX matters a lot

Small frustrations repeated every day are worth solving.

Real-world architecture creates tooling gaps

Framework tools often work perfectly for simple examples.

Real architectures expose friction.

Side projects don't need to be massive

This started as:

"I'm tired of typing long EF commands"

And turned into a real CLI product.

Final thoughts

EfPilot started as a personal productivity tool.

But I ended up building something I'd happily use in any serious .NET project.

If you're dealing with complex EF Core migrations workflows, I'd love your feedback.

GitHub repo:

https://github.com/adrianmenegatti/efpilot

Possible future improvements

  • NuGet global tool packaging
  • Interactive mode
  • Better migration diff engine
  • Migration visualization
  • CI integration

This project reminded me that some of the best products come from solving your own recurring frustrations.

And sometimes... those frustrations start with a very long dotnet ef command 😄

Top comments (0)