I'm using the Entity Framework in the Code First mode with automatic migrations enabled. Now, I have one entity whose table should not be managed (migrated) by the EF. Is there a way of disabling automatic migrations for one specific entity (i.e. table)?
6 Answers
This is now possible in EF Core 5.0 using the ExcludeFromMigrations()
method, but strangely enough you have to call the ToTable()
method and then use the TableBuilder
.
public class ReportingContext : DbContext
{
public DbSet<User> Users { get; set; }
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<User>().ToTable(nameof(Users), t => t.ExcludeFromMigrations());
}
}

- 19,813
- 8
- 81
- 66
-
1This method also works with EF Core 6. – Miro J. Jul 06 '22 at 22:23
Another option that worked for me in EFCore 5.0 is to use SetIsTableExcludedFromMigrations:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<MyEntity>().Metadata.SetIsTableExcludedFromMigrations(true);
}

- 1,448
- 1
- 14
- 26
-
1
-
15With this method, you don't need to know the table name, which may or may not be `nameof(Users)` – FernAndr Aug 05 '21 at 07:58
My TEMPORARY solution, only for dev environments.
I have a separate script that runs migration and program run does not check them. So in unexpected case I was possible to invoke Ignore<ContactView>()
and run migrations with this line. When it was completed, I removed this line!
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
// comment out this code after migrations are done
modelBuilder.Ignore<ContactView>();
}

- 7,435
- 5
- 52
- 75
-
1You could use a compiler, preprocessor directive E.g: #define DEVELOPING And when set, your code block gets included #If DEVELOPING modelBuilder.Ignore
(); #endif Of course, you could use the built in directive DEBUG #If DEBUG modelBuilder.Ignore – Antony Booth May 17 '19 at 23:00(); #endif https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-if -
@AntonyBooth - in this case, it was really a "one timer". But yeah, if project policy allows it, preprocessor directives could be a way to go. – andrew.fox May 20 '19 at 06:22
It is possible by using another DbContext
to access the table in question. Migrations are bound to one DbContext
(see Is it possible to have automatic migrations for one DbContext and not for another in the same project?).
Not sure if this is the OP's exact scenario, but I had a table that I did not want a migration generated for. I accomplished this by using ToView
instead of ToTable
within the DbContext:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<MyTable>(entity => {
// Migration will not be generated for this table
entity.ToView("MyTable", "dbo");
entity.Property(e => e.FooBar).HasColumnType("DECIMAL(19,9)");
});
}
It feels a bit hacky to me, but maybe it's not -- because, after all, I'm just trying to "view" the table, not write to it...
[Tested with .NET Core EF 3.1.3]
*** update 06/17/23: the above solution is still viable if you are stuck working with EF3, but if you are using EF5+ you should use the new ExcludeFromMigrations()
function: https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-efcore-5-0-rc1/#exclude-tables-from-migrations

- 14,799
- 7
- 42
- 42
-
This method has a big problem with EF 5. If you define a table as view, then if you have any foreign key to this table it won't make them! I tested the method of @Tobias and that works in EF5 – MJBZA Apr 05 '21 at 08:32
You want to use the [NotMapped]
annotation on that class/entity.

- 6,037
- 2
- 25
- 35
-
3Unfortunately, this does not work. I get an InvalidOperationException saying "The type '...' was not mapped..." when I try to execute a query on the corresponding DbSet. – Dejan Feb 26 '14 at 12:12
-
Ah ok, so you still want it in your model but not under the control of migrations. In that case, you'll want something like this ... http://stackoverflow.com/questions/9016709/how-to-ignore-a-table-class-in-ef-4-3-migrations – Mashton Feb 26 '14 at 14:24
-
exactly. However, the answer you are referring to works only if you have an existing schema and then decide that EF should take control over it. In my case, I want EF to *never* touch that particular table. The schema of that table will evolve through the time but outside EF. – Dejan Feb 26 '14 at 15:05
-
Time for me to bow out - that's my knowledge of EF migrations stretched beyond breaking point! Good luck. – Mashton Feb 26 '14 at 15:07