You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SchemaKit: fail at startup when another package has replaced the model differ or the migrations SQL generator #57
When another package calls ReplaceService<IMigrationsModelDiffer, …> or ReplaceService<IMigrationsSqlGenerator, …> after SchemaKit's registration, EF Core uses that package's service, and every SchemaKit declaration disappears from migrations without an error. EFCore.ComplexIndexes 5.x has the same exposure today.
Change
When the two services are first resolved, at runtime and at design time, check that the resolved differ and SQL generator are SchemaKit's. If they aren't, throw, naming the type that replaced them and pointing to the plugin contract (#56).
Cover runtime ReplaceService, registration through design-time IDesignTimeServices, and a provider that registers its own after ours.
Tests
A context that replaces each service after SchemaKit's registration throws at the first migrations operation, with the replacing type's name; one test per entry point (runtime, design time). Remove the check and show that migrations add then loses the declaration silently.
Not covered
A package that replaced the services before SchemaKit loses to SchemaKit's replacement, and the check can't see it. The README says so. The answer there is the other package's own guard: CodoMetis packages never replace either service (CodoMetis.ValueRanges enforces this with a convention test, CaffeinatedCoder/CodoMetis.ValueRanges#334).
Activity