Code First Migrations uses a table called __MigrationHistory as a place to store metadata about the migrations that have been applied to the database. Code First creates this table when it creates a database or when migrations are enabled. In addition, when running against Microsoft SQL Server, Code First will also mark the table as a system table. However, several times recently the question has come up of how to make the table a normal user table instead of a system table. This is pretty easy to do and this post describes how.
EF Code First is great and I use it all the time, even when mapping to existing databases. However, if your intention is to use a Database First flow, then it’s important that you don’t start to use Code First unintentionally. If you do, then you might end up with exceptions like those described in this Stack Overflow question.
EF 4.2 and 4.3 were released via NuGet only—there are no MSI installers. The up-coming EF 5.0 release will continue this pattern. But why NuGet and why only NuGet? It’s not because NuGet is awesome, even though it is, or because it’s the hot new thing, even though it is. It’s because it is a great match for delivering the EF runtime. This match comes from four things that NuGet does really well: setting up apps for bin-deployment, managing dependencies, providing easy project-level and PowerShell integration, and helping developers know about and get the latest version.