Part of the EF Core migration generation epic — tracking issue #371.
Render the translated operations (from the translation-layer issue) into compilable C# migration files, plus the generated stub DbContext that hosts them. This is a small hand-rolled emitter over the stable, public MigrationBuilder fluent surface — deliberately not EF's internal CSharpMigrationsGenerator/scaffolding stack, which is "pubternal" and unsupported for programmatic use (dotnet/efcore#23595).
Files emitted
<timestamp>_<Name>.cs — partial class <Name> : Migration with generated Up(MigrationBuilder) / Down(MigrationBuilder). Down() is real, generated from Weasel's existing WriteRollback/drop logic. Carries [DbContext(typeof(...))] and [Migration("<id>")] attributes (attribute-only approach; no BuildTargetModel body — it defaults to empty and is only needed by dotnet ef migrations remove, which we don't support for Weasel-authored files).- Stub context (once per
IDatabase, e.g. MartenSchemaDbContext) — no entities; provider configured; history table relocated into the critter-stack schema (e.g. __EFMigrationsHistory in the Marten/Wolverine schema, not public/dbo) so it never collides with the user's own app-context migrations; bakes in ConfigureWarnings(w => w.Ignore(RelationalEventId.PendingModelChangesWarning)) (required on EF 9+).
- Registration snippet / doc comment showing
services.AddDbContext<...> and dotnet ef database update --context ... usage.
Details
- Migration IDs:
yyyyMMddHHmmss_Name UTC; EF orders migrations by plain string sort of the ID, so guard monotonicity when generating multiple migrations in the same second (Sable literally fudged +2s).
- Respect
.editorconfig style in generated code (4-space indent, etc.).
- Output location configurable; sensible default alongside the user's migrations directory convention.
Acceptance
- Generated files compile in a target project with only
Microsoft.EntityFrameworkCore.<Provider> referenced.
- Spike-issue verification matrix (update/script/bundle/Migrate/Down) passes against generated (not hand-written) files.
Part of the EF Core migration generation epic — tracking issue #371.
Render the translated operations (from the translation-layer issue) into compilable C# migration files, plus the generated stub
DbContextthat hosts them. This is a small hand-rolled emitter over the stable, publicMigrationBuilderfluent surface — deliberately not EF's internalCSharpMigrationsGenerator/scaffolding stack, which is "pubternal" and unsupported for programmatic use (dotnet/efcore#23595).Files emitted
<timestamp>_<Name>.cs—partial class <Name> : Migrationwith generatedUp(MigrationBuilder)/Down(MigrationBuilder).Down()is real, generated from Weasel's existingWriteRollback/drop logic. Carries[DbContext(typeof(...))]and[Migration("<id>")]attributes (attribute-only approach; noBuildTargetModelbody — it defaults to empty and is only needed bydotnet ef migrations remove, which we don't support for Weasel-authored files).IDatabase, e.g.MartenSchemaDbContext) — no entities; provider configured; history table relocated into the critter-stack schema (e.g.__EFMigrationsHistoryin the Marten/Wolverine schema, notpublic/dbo) so it never collides with the user's own app-context migrations; bakes inConfigureWarnings(w => w.Ignore(RelationalEventId.PendingModelChangesWarning))(required on EF 9+).services.AddDbContext<...>anddotnet ef database update --context ...usage.Details
yyyyMMddHHmmss_NameUTC; EF orders migrations by plain string sort of the ID, so guard monotonicity when generating multiple migrations in the same second (Sable literally fudged +2s)..editorconfigstyle in generated code (4-space indent, etc.).Acceptance
Microsoft.EntityFrameworkCore.<Provider>referenced.