Another favorite of mine: EF will sometimes generate constraints on your tables or columns, that can't really work. But the generated migrations are generated w

Another favorite of mine: EF will sometimes generate constraints on your tables or columns, that can't really work. But the generated migrations are generated with drop-reversers that don't work (ie if you try to execute them, you get SQL-errors.) BUT, EF also generates random names for these constraints, so you can't just drop them by hand - you don't know what they are called, and they will have different random names on different db instances! So you (that is, I) end up having to write convoluted stored procedures, that query the db for 'what kinds of constraints do you have that satisfy these requirements, what are they called?', THEN you can remove them in an order that makes sense (instead of the autogenerated nonsense that won't execute..) Oh, and EF's code for handling its own migration-table used to be buggy; they used to have a column they later got rid of, and some of their code would fail on this column either being or not being there. My final gripe (for today) is that their migration-table doesn't include a timestamp for when the migration was executed. This has caused me headaches, because sometimes bugs in client data would depend on, whether a migration had happened early or late, since it would determine against which version of your db model client data was processed. sigh.