ASP.NET Core 1.0.0 Release Notes
We are pleased to announce the release of ASP.NET Core 1.0.0!
You can find details on the new features and bug fixes in 1.0.0 for the following components on their corresponding release pages:
We have also released Preview 2 of the ASP.NET Core Tooling for Visual Studio and the following SDK tools:
Azure App Service is ready to support ASP.NET Core 1.0 apps. More information for running ASP.NET Core apps on Azure App Service is available at https://blogs.msdn.microsoft.com/appserviceteam/2016/06/27/azure-app-service-and-asp-net-core. If you don’t have an Azure account you can still try an ASP.NET Core 1.0 sample on Azure App Service free of charge and commitment with the trial offer at https://tryappservice.azure.com/?appservice=web.
- For a list of the breaking changes for this release please refer to the issues in the Announcements repo.
Some queries, especially those with a number of includes, show a significant slow down when executed asynchronously. The workaround is to execute them synchronously (i.e. replace
For more details, see dotnet/efcore#5816
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
maxLengthargument 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.
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.
Scaffold a new migration (
Add-Migration InitialSchemain Visual Studio,
dotnet ef migrations add InitialSchemafrom cmd line). You can call the migration whatever you want,
InitialSchemais 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.
For any existing databases, where the migrations deleted in Step 1 were already applied, add a row to the
__EFMigrationsHistorytable 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
INSERT INTO [dbo].[__EFMigrationsHistory] ([MigrationId], [ProductVersion]) VALUES ('<migration name with timestamp>', '1.0.0-rtm-21431');
Optionally, you can delete the rows from
__EFMigrationsHistorythat 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
maxLengthspecification. 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.
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
256for the following columns.
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.
Attempting to run EF commands on Universal Windows Platform (UWP) projects results in the following error:
System.IO.FileLoadException: Could not load file or assembly 'System.IO.FileSystem.Primitives, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
Manually add binding redirects to the UWP project. Create a file named "App.config" in the project root folder and add redirects to the correct assembly versions.
<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.IO.FileSystem.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="184.108.40.206" newVersion="220.127.116.11"/> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Threading.Overlapped" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="18.104.22.168" newVersion="22.214.171.124"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration>
For more details, see dotnet/efcore#5471