Skip to content

1.0.0
Compare
Choose a tag to compare
@danroth27 danroth27 released this 27 Jun 15:13
1.0.0
93ef04d

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.

Breaking Changes

  • For a list of the breaking changes for this release please refer to the issues in the Announcements repo.

Known Issues

  • EF Core: Some queries significantly slower when executed async

    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 ToListAsync() etc. with ToList() etc.).

    For more details, see dotnet/efcore#5816

  • EF Core: Pre-RTM migrations need maxLength added to string columns

    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.

  • EF Core: Commands on UWP projects require manually adding binding redirects

    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=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

    Workaround

    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="4.0.0.0"
                         newVersion="4.0.1.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Threading.Overlapped"
                          publicKeyToken="b03f5f7f11d50a3a"
                          culture="neutral" />
        <bindingRedirect oldVersion="4.0.0.0"
                         newVersion="4.0.1.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

    For more details, see dotnet/efcore#5471

Assets 2
Loading