Problem
The CLI migration toolkit always emits SQL Server connection strings from the original Web.config. For portable benchmark runs and many real-world migrations, SQLite is needed. Currently, every migration run requires manual post-migration fixup:
- Swap Microsoft.EntityFrameworkCore.SqlServer to Sqlite in csproj
- Update connection strings in appsettings.json
- Change UseSqlServer() to UseSqlite() in Program.cs and DbContext classes
- Add EnsureCreated() + seed data for portable runs
This was the single largest runtime repair item in Run 43, consuming ~8 minutes of a 35-minute benchmark.
Proposed Solution
Add a --database-provider flag to the CLI (default: sqlite).
What the flag should control:
| Aspect |
sqlite (default) |
sqlserver |
| NuGet package |
Microsoft.EntityFrameworkCore.Sqlite |
Microsoft.EntityFrameworkCore.SqlServer |
| Connection string |
Data Source=app.db |
Preserved from Web.config |
| DbContext config |
UseSqlite(...) |
UseSqlServer(...) |
| Program.cs |
EnsureCreated() emitted |
No EnsureCreated() |
Implementation touches:
- ProgramCsEmitter — emit correct provider package and connection config
- ProjectScaffolder — emit correct NuGet package reference
- MigrationOptions — add DatabaseProvider property
- Program.cs CLI arg parser — add --database-provider flag
Context
- Identified as G5 gap during WingtipToys Run 43 benchmark
- See dev-docs/migration-tests/wingtiptoys/run43/report.md for details
- Three places need updating per migration: csproj, Program.cs, and DbContext OnConfiguring fallbacks
Problem
The CLI migration toolkit always emits SQL Server connection strings from the original Web.config. For portable benchmark runs and many real-world migrations, SQLite is needed. Currently, every migration run requires manual post-migration fixup:
This was the single largest runtime repair item in Run 43, consuming ~8 minutes of a 35-minute benchmark.
Proposed Solution
Add a
--database-providerflag to the CLI (default:sqlite).What the flag should control:
Implementation touches:
Context