EF Core: RC2 => RTM maxLength needs to be added to existing migrations

[rowanmiller]

In RC2, the column definition in a migration looked like table.Column<string>(nullable: true) and the length of the column was looked up in some metadata we store in the code behind the migration. In RTM, the length is now included in the scaffolded code table.Column<string>(maxLength: 450, nullable: true).

Any existing migrations that were scaffolded prior to using RTM will not have the maxLength argument specified. This means that in some cases the maximum length supported by the database will be used (nvarchar(max) on SQL Server).

Option 1: Re-Scaffold Migrations

The easiest option is to have EF re-scaffold migrations in the correct format.

1. Delete the Migrations folder from your project (including the model snapshot and all the migrations it contains). If you have customized the scaffolded migrations, be sure to save that code elsewhere before deleting the files.

2. Scaffold a new migration (Add-Migration InitialSchema in Visual Studio, dotnet ef migrations add InitialSchema from cmd line). You can call the migration whatever you want, InitialSchema is just a suggestion.

   This migration represents the same operations that were previously handled by the migrations you deleted in Step 1. The difference is that the code is in the format expected by RTM.

3. For any existing databases, where the migrations deleted in Step 1 were already applied, add a row to the __EFMigrationsHistory table to indicate that the operations in the new migration have already been applied.

   You will need to update the following script to specify the full name of the migration that was generated. You can copy this from the filename of the scaffolded migration - it will be something like 20160630191522_InitialSchema.

   INSERT INTO [dbo].[__EFMigrationsHistory] ([MigrationId], [ProductVersion])
   VALUES ('<migration name with timestamp>', '1.0.0-rtm-21431');
   

4. Optionally, you can delete the rows from __EFMigrationsHistory that represent the migrations that were removed in Step 1. This isn't required though, as EF will just ignore excess rows in this table.

Option 2: Manually Edit Existing Migrations

Another option is to manually edit existing migrations to include the maxLength specification. By convention, 450 is the maximum length used for keys, foreign keys, and indexed columns. If you have explicitly configured a length in the model, then you should use that length instead.

ASP.NET Identity

This change impacts projects that use ASP.NET Identity and were created from a pre-RTM project template. The project template includes a migration used to create the database.

We would recommend using Option 1 above to recreate this migration. If you chose to manually edit the migration instead, you need to specify a maximum length of 256 for the following columns.

• AspNetRoles
  • Name
  • NormalizedName
• AspNetUsers
  • Email
  • NormalizedEmail
  • NormalizedUserName
  • UserName

Failure to make this change will result in the following exception when the initial migration is applied to a database.

System.Data.SqlClient.SqlException (0x80131904): Column 'NormalizedName' in table 'AspNetRoles' is of a type that is invalid for use as a key column in an index. .

[rowanmiller]

This issue can be discussed at dotnet/efcore#5872