What can Entity Framework Migrations do that FluentMigrator cannot?

Question

I have several databases currently using FluentMigrator and am curious to know how Entity Framework Migrations compare.

Can EF Migrations seed data in migrations and selectively run migration scripts based on environments like FluentMigrator can with tags and profiles?

I am already using EF Database First as the ORM to my application, and I think I read somewhere that EF Migrations are supported for non-Code First EF as well now, but my team has been thinking about refactoring to a Code First approach anyway because of some of the limitations with the Database First approach. So would EF Migrations just make more sense to use rather than have another 3rd party migration framework when going with a code first approach?

Stickinthemud

Well, primarily, FM can't generate migrations automatically.. Ie, it doesn't scan the database, determine what changed, and create the script based on the diff. EFM does that. – Cicala

Now three years later, I'm curious to see whether you attempted the switch, and what your experience was. It seems like most who use migrations use one or the other, and don't really have an opinion about the other. – Maneuver

Answer 1

Entity Framework automatically generates migration files and supports LINQ-to-SQL. FluentMigrations, in contrast, only scripts migrations and doesn't automatically generate migration files. FluentMigrations was developed several years before Entity Framework Code-First.

Foolproof

Answer 2

I don't have any experience with FluentMigrator but after a brief skim of the documentation, it looks like you have to create your migrations manually?

EF will prompt for a migration every time your model changes and the app is run. This makes it kind of easy, but annoying at the same time. Once you've turned on Migrations, any changes to your model that would involve a database change will require a migration. You can modify the migration tho, and it's auto generated. Just watch the "down" version... I've had issues.

Code first is pretty seamless tho. Even handles more complex object models like subclasses. You can even specify how the tables are generated (table for each type, base table and a table for each type, or single table and a type key).

All that to say, if you're gonna always generate c# code to update your database, I'd go with EF's built in migrations. They do most of the work for you.

Embankment

i fail to see what's the real difference between the two; not sure if I should use one over the other on my case – Harmful