--- title: EF Core Plugins: When Migrations Go Wrong — Daily DevOps... description: When a host ASP.NET Core application references plugin assemblies, EF Core's automatic entity discovery can pull plugin-owned tables into the host's migration... canonical: https://daily.dev/posts/ef-core-plugins-when-migrations-go-wrong-daily-devops-net-tonjsxygr twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: EF Core Plugins: When Migrations Go Wrong — Daily DevOps & .NET | daily.dev og:description: When a host ASP.NET Core application references plugin assemblies, EF Core's automatic entity discovery can pull plugin-owned tables into the host's migration... og:url: https://daily.dev/posts/ef-core-plugins-when-migrations-go-wrong-daily-devops-net-tonjsxygr og:image: https://api.daily.dev/og/posts/tOnJsxygr.png og:image:alt: EF Core Plugins: When Migrations Go Wrong — Daily DevOps & .NET og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # EF Core Plugins: When Migrations Go Wrong — Daily DevOps & .NET **[Daily DevOps & .NET](https://daily.dev/sources/dailydevopsnet)** · [@samtrion](https://daily.dev/samtrion) · 8 min read · 18 upvotes · 1 comments ## Summary When a host ASP.NET Core application references plugin assemblies, EF Core's automatic entity discovery can pull plugin-owned tables into the host's migration timeline. This happens via navigation property traversal, explicit modelBuilder.Entity() calls, or ApplyConfigurationsFromAssembly scanning plugin assemblies. The result is three concrete failure modes: duplicate schema creation when both host and plugin migrations try to create the same table, schema drift as the two migration histories diverge, and orphaned migration history that makes plugin uninstallation dangerous. The model snapshot compounds the problem — once a plugin entity enters the snapshot, simply removing the DbSet property triggers a DROP TABLE on the next migration. Quick fixes like Ignore() or [NotMapped] eliminate EF Core's ability to query the entity, while HasNoKey().ToView() is semantically incorrect. The correct solution — ExcludeFromMigrations() — is previewed as the subject of Part 2. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does my EF Core host DbContext migration create tables for entities that belong to a plugin assembly? EF Core's OnModelCreating traverses navigation properties and applies ApplyConfigurationsFromAssembly scans automatically, so if a host DbSet has a navigation property to a plugin entity, or the host scans the plugin assembly for IEntityTypeConfiguration classes, EF Core treats those plugin entities as part of its own model and generates CREATE TABLE statements for them in the host migration. _Teams debugging cross-context EF Core migration bleed can find similar breakdowns and fixes on daily.dev._ ### What happens if I remove a plugin entity's DbSet from my EF Core host context after it already appeared in a migration? Removing the DbSet does not clean the stored model snapshot, so the next migration diffs the new model (without the entity) against the snapshot (which still has it) and generates a DROP TABLE statement, which deletes the plugin's data if that migration reaches production. _Developers untangling EF Core snapshot mistakes before a production deploy often research fixes like this via daily.dev._ ### Why doesn't calling modelBuilder.Ignore() fully solve the problem of a plugin entity contaminating host migrations in EF Core? Ignore() and the [NotMapped] attribute stop migration generation but also strip EF Core's awareness of the type entirely, meaning the host context can no longer query that entity through LINQ, forcing raw SQL or a second DbContext to join data like pages and their related posts for something like a dashboard widget. _Anyone weighing EF Core mapping trade-offs for plugin-based systems can track deeper analysis like this on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@pdfopsdev** · 2 upvotes > The snapshot DROP TABLE footgun is the nastiest part here — you remove a DbSet thinking it's inert and EF happily generates a destructive migration. ExcludeFromMigrations() is the right per-entity fix, but if plugins are genuinely independent, a cleaner architecture is a separate DbContext per plugin with its own history table (override MigrationsHistoryTable so each tracks its own __EFMigrationsHistory). Then host and plugin timelines physically can't collide, and uninstall is just dropping that plugin's tables. Curious whether Part 2 gets into multi-context, since ExcludeFromMigrations... ## Similar posts on daily.dev - [EF Core Plugins: Owning Migrations with ExcludeFromMigrations — Daily DevOps & .NET](https://daily.dev/posts/ef-core-plugins-owning-migrations-with-excludefrommigrations-daily-devops-net-nrbwcbzmy) · Daily DevOps & .NET · 0 upvotes · 0 comments - [EF Core Migration Bundles: What They Are & Why They Matter](https://daily.dev/posts/ef-core-migration-bundles-what-they-are-why-they-matter-xq9wcjnhr) · Medium · 0 upvotes · 0 comments - [6 EF Core Query Mistakes That Get Expensive in Production](https://daily.dev/posts/6-ef-core-query-mistakes-that-get-expensive-in-production-5cpkulovz) · Waseem .NET Newsletter · 9 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#.net](https://daily.dev/tags/.net) [View this post on daily.dev](https://daily.dev/posts/ef-core-plugins-when-migrations-go-wrong-daily-devops-net-tonjsxygr) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"EF Core Plugins: When Migrations Go Wrong — Daily DevOps & .NET","url":"https://daily.dev/posts/ef-core-plugins-when-migrations-go-wrong-daily-devops-net-tonjsxygr","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/ef-core-plugins-when-migrations-go-wrong-daily-devops-net-tonjsxygr"},"datePublished":"2026-07-07T21:13:45.908Z","dateModified":"2026-09-14T06:00:22.348Z","description":"When a host ASP.NET Core application references plugin assemblies, EF Core's automatic entity discovery can pull plugin-owned tables into the host's migration...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/baf63ae7f613337e6618a088910915e1?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/baf63ae7f613337e6618a088910915e1?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Daily DevOps & .NET","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Person","name":"Martin Stühmer","url":"https://daily.dev/samtrion","image":"https://avatars.githubusercontent.com/u/3283596?v=4","description":"The code you create is a valuable legacy, so it's important to build it carefully.","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":830}},"commentCount":1,"discussionUrl":"https://daily.dev/posts/ef-core-plugins-when-migrations-go-wrong-daily-devops-net-tonjsxygr","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":18},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"database,.net","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Daily DevOps & .NET","item":"https://daily.dev/sources/dailydevopsnet"},{"@type":"ListItem","position":3,"name":"EF Core Plugins: When Migrations Go Wrong — Daily DevOps & .NET"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/ef-core-plugins-when-migrations-go-wrong-daily-devops-net-tonjsxygr","comment":[{"@type":"Comment","text":"The snapshot DROP TABLE footgun is the nastiest part here — you remove a DbSet thinking it’s inert and EF happily generates a destructive migration. ExcludeFromMigrations() is the right per-entity fix, but if plugins are genuinely independent, a cleaner architecture is a separate DbContext per plugin with its own history table (override MigrationsHistoryTable so each tracks its own __EFMigrationsHistory). Then host and plugin timelines physically can’t collide, and uninstall is just dropping that plugin’s tables. Curious whether Part 2 gets into multi-context, since ExcludeFromMigrations still leaves you hand-managing the plugin schema.","datePublished":"2026-07-10T18:08:00.540Z","url":"https://daily.dev/posts/tOnJsxygr#c-sriZbVYFx","author":{"@type":"Person","name":"PDFops","url":"https://daily.dev/pdfopsdev","image":"https://media.daily.dev/image/upload/s---8isRBKc--/f_auto/v1782922291/avatars/avatar_orjMeK8QKaaVZwGq7ScPz?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/ef-core-plugins-when-migrations-go-wrong-daily-devops-net-tonjsxygr#faq","mainEntity":[{"@type":"Question","name":"Why does my EF Core host DbContext migration create tables for entities that belong to a plugin assembly?","acceptedAnswer":{"@type":"Answer","text":"EF Core's OnModelCreating traverses navigation properties and applies ApplyConfigurationsFromAssembly scans automatically, so if a host DbSet has a navigation property to a plugin entity, or the host scans the plugin assembly for IEntityTypeConfiguration classes, EF Core treats those plugin entities as part of its own model and generates CREATE TABLE statements for them in the host migration. Teams debugging cross-context EF Core migration bleed can find similar breakdowns and fixes on daily.dev."}},{"@type":"Question","name":"What happens if I remove a plugin entity's DbSet from my EF Core host context after it already appeared in a migration?","acceptedAnswer":{"@type":"Answer","text":"Removing the DbSet does not clean the stored model snapshot, so the next migration diffs the new model (without the entity) against the snapshot (which still has it) and generates a DROP TABLE statement, which deletes the plugin's data if that migration reaches production. Developers untangling EF Core snapshot mistakes before a production deploy often research fixes like this via daily.dev."}},{"@type":"Question","name":"Why doesn't calling modelBuilder.Ignore() fully solve the problem of a plugin entity contaminating host migrations in EF Core?","acceptedAnswer":{"@type":"Answer","text":"Ignore() and the [NotMapped] attribute stop migration generation but also strip EF Core's awareness of the type entirely, meaning the host context can no longer query that entity through LINQ, forcing raw SQL or a second DbContext to join data like pages and their related posts for something like a dashboard widget. Anyone weighing EF Core mapping trade-offs for plugin-based systems can track deeper analysis like this on daily.dev."}}]} ```