EF Core 1.0 RC1 から 1.0 の RC2 にアップグレードします。Upgrading from EF Core 1.0 RC1 to 1.0 RC2

この記事では、RC2、RC1 パッケージにビルドされたアプリケーションの移動のガイダンスを提供します。This article provides guidance for moving an application built with the RC1 packages to RC2.

パッケージの名前とバージョンPackage Names and Versions

RC1 と RC2 では、間を変更しました"Entity Framework 7"から"Entity Framework Core"します。Between RC1 and RC2, we changed from "Entity Framework 7" to "Entity Framework Core". 詳細の変更の理由についてScott Hanselman によるこの投稿します。You can read more about the reasons for the change in this post by Scott Hanselman. この変更により、パッケージ名の変更からEntityFramework.*Microsoft.EntityFrameworkCore.*のバージョンから7.0.0-rc1-final1.0.0-rc2-final(または1.0.0-preview1-finalツールの)。Because of this change, our package names changed from EntityFramework.* to Microsoft.EntityFrameworkCore.* and our versions from 7.0.0-rc1-final to 1.0.0-rc2-final (or 1.0.0-preview1-final for tooling).

RC1 パッケージを完全に削除してから、RC2 をインストールする必要があるものです。You will need to completely remove the RC1 packages and then install the RC2 ones. 一般的なパッケージのマッピングを次に示します。Here is the mapping for some common packages.

RC1 パッケージRC1 Package RC2 と同等RC2 Equivalent
EntityFramework.MicrosoftSqlServer 7.0.0-rc1-finalEntityFramework.MicrosoftSqlServer 7.0.0-rc1-final Microsoft.EntityFrameworkCore.SqlServer 1.0.0-rc2-finalMicrosoft.EntityFrameworkCore.SqlServer 1.0.0-rc2-final
EntityFramework.SQLite 7.0.0-rc1-finalEntityFramework.SQLite 7.0.0-rc1-final Microsoft.EntityFrameworkCore.Sqlite 1.0.0-rc2-finalMicrosoft.EntityFrameworkCore.Sqlite 1.0.0-rc2-final
EntityFramework7.Npgsql 3.1.0-rc1-3EntityFramework7.Npgsql 3.1.0-rc1-3 NpgSql.EntityFrameworkCore.Postgres NpgSql.EntityFrameworkCore.Postgres
EntityFramework.SqlServerCompact35 7.0.0-rc1-finalEntityFramework.SqlServerCompact35 7.0.0-rc1-final EntityFrameworkCore.SqlServerCompact35 1.0.0-rc2-finalEntityFrameworkCore.SqlServerCompact35 1.0.0-rc2-final
EntityFramework.SqlServerCompact40 7.0.0-rc1-finalEntityFramework.SqlServerCompact40 7.0.0-rc1-final EntityFrameworkCore.SqlServerCompact40 1.0.0-rc2-finalEntityFrameworkCore.SqlServerCompact40 1.0.0-rc2-final
EntityFramework.InMemory 7.0.0-rc1-finalEntityFramework.InMemory 7.0.0-rc1-final Microsoft.EntityFrameworkCore.InMemory 1.0.0-rc2-finalMicrosoft.EntityFrameworkCore.InMemory 1.0.0-rc2-final
EntityFramework.IBMDataServer 7.0.0-beta1EntityFramework.IBMDataServer 7.0.0-beta1 Rc2 はまだ使用できません。Not yet available for RC2
EntityFramework.Commands 7.0.0-rc1-finalEntityFramework.Commands 7.0.0-rc1-final Microsoft.EntityFrameworkCore.Tools 1.0.0-preview1-finalMicrosoft.EntityFrameworkCore.Tools 1.0.0-preview1-final
EntityFramework.MicrosoftSqlServer.Design 7.0.0-rc1-finalEntityFramework.MicrosoftSqlServer.Design 7.0.0-rc1-final Microsoft.EntityFrameworkCore.SqlServer.Design 1.0.0-rc2-finalMicrosoft.EntityFrameworkCore.SqlServer.Design 1.0.0-rc2-final

名前空間Namespaces

パッケージの名前と名前空間の変更からMicrosoft.Data.Entity.*Microsoft.EntityFrameworkCore.*します。Along with package names, namespaces changed from Microsoft.Data.Entity.* to Microsoft.EntityFrameworkCore.*. 検索/置換では、この変更を処理できるusing Microsoft.Data.Entityusing Microsoft.EntityFrameworkCoreします。You can handle this change with a find/replace of using Microsoft.Data.Entity with using Microsoft.EntityFrameworkCore.

テーブルの命名規約の変更Table Naming Convention Changes

RC2 でしました、重要な機能の変更の名前を使用する方法が、DbSet<TEntity>テーブル名として指定されたエンティティのプロパティにマップ、クラス名だけではなく。A significant functional change we took in RC2 was to use the name of the DbSet<TEntity> property for a given entity as the table name it maps to, rather than just the class name. 詳細では、この変更に関する関連のお知らせ問題します。You can read more about this change in the related announcement issue.

既存の RC1 アプリケーションをお勧めの先頭に次のコードを追加、 OnModelCreating RC1 の命名方法を保持するメソッド。For existing RC1 applications, we recommend adding the following code to the start of your OnModelCreating method to keep the RC1 naming strategy:

foreach (var entity in modelBuilder.Model.GetEntityTypes())
{
    entity.Relational().TableName = entity.DisplayName();
}

新しい名前付け戦略を採用する場合はお勧めしますが正常に完了、残りのアップグレードの手順とし、コードを削除し、テーブルを適用する移行を作成する名前を変更します。If you want to adopt the new naming strategy, we would recommend successfully completing the rest of the upgrade steps and then removing the code and creating a migration to apply the table renames.

AddDbContext/Startup.cs の変更 (ASP.NET Core プロジェクトのみ)AddDbContext / Startup.cs Changes (ASP.NET Core Projects Only)

RC1 でアプリケーション サービス プロバイダーで Entity Framework サービスを追加する必要があるStartup.ConfigureServices(...):。In RC1, you had to add Entity Framework services to the application service provider - in Startup.ConfigureServices(...):

services.AddEntityFramework()
  .AddSqlServer()
  .AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(Configuration["ConnectionStrings:DefaultConnection"]));

RC2 への呼び出しを削除できますAddEntityFramework()AddSqlServer()など。In RC2, you can remove the calls to AddEntityFramework(), AddSqlServer(), etc.:

services.AddDbContext<ApplicationDbContext>(options =>
  options.UseSqlServer(Configuration["ConnectionStrings:DefaultConnection"]));

また、コンテキストのオプションを受け取り、基底コンス トラクターに渡して、派生コンテキストに、コンス トラクターを追加する必要があります。You also need to add a constructor, to your derived context, that takes context options and passes them to the base constructor. これを削除しました背後に忍び込んでいる恐ろしい魔法のために必要です。This is needed because we removed some of the scary magic that snuck them in behind the scenes:

public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
    : base(options)
{
}

IServiceProvider 内で渡すPassing in an IServiceProvider

渡される RC1 コードがある場合、IServiceProviderコンテキストにこれが移動したをDbContextOptions、別のコンス トラクターのパラメーターではなく。If you have RC1 code that passes an IServiceProvider to the context, this has now moved to DbContextOptions, rather than being a separate constructor parameter. 使用DbContextOptionsBuilder.UseInternalServiceProvider(...)サービス プロバイダーを設定します。Use DbContextOptionsBuilder.UseInternalServiceProvider(...) to set the service provider.

テストTesting

これを行うための最も一般的なシナリオをテストするときに、InMemory データベースのスコープを制御することでした。The most common scenario for doing this was to control the scope of an InMemory database when testing. 更新された参照テストRC2 を使用してこれを実現する例については、資料。See the updated Testing article for an example of doing this with RC2.

アプリケーション サービス プロバイダー (ASP.NET Core プロジェクトのみ) からの内部サービスを解決します。Resolving Internal Services from Application Service Provider (ASP.NET Core Projects Only)

オーバー ロードがある場合は、ASP.NET Core アプリケーションがあり、アプリケーションのサービス プロバイダーからの内部サービスを解決するのには EF をするAddDbContextこれを構成することができます。If you have an ASP.NET Core application and you want EF to resolve internal services from the application service provider, there is an overload of AddDbContext that allows you to configure this:

services.AddEntityFrameworkSqlServer()
  .AddDbContext<ApplicationDbContext>((serviceProvider, options) =>
    options.UseSqlServer(Configuration["ConnectionStrings:DefaultConnection"])
           .UseInternalServiceProvider(serviceProvider)); );

警告

アプリケーション サービス プロバイダーに EF の内部サービスを結合する理由がない限り、内部的には、独自のサービスを管理する EF を許可することをお勧めします。We recommend allowing EF to internally manage its own services, unless you have a reason to combine the internal EF services into your application service provider. 主な理由はこうしたい場合がありますがアプリケーション サービス プロバイダーを使用して、EF が内部的に使用するサービスを置換するにはThe main reason you may want to do this is to use your application service provider to replace services that EF uses internally

DNX コマンド = > .NET CLI (ASP.NET Core プロジェクトのみ)DNX Commands => .NET CLI (ASP.NET Core Projects Only)

使用していた場合、 dnx ef ASP.NET 5 プロジェクトのコマンドは、これらに移動dotnet efコマンド。If you previously used the dnx ef commands for ASP.NET 5 projects, these have now moved to dotnet ef commands. 同じコマンドの構文は引き続き適用されます。The same command syntax still applies. 使用することができますdotnet ef --help構文の詳細について。You can use dotnet ef --help for syntax information.

RC2 では、.NET CLI によって置き換えられる DNX が原因でコマンドが登録されている方法が変更されました。The way commands are registered has changed in RC2, due to DNX being replaced by .NET CLI. コマンドで登録が完了しました、toolsセクションproject.json:Commands are now registered in a tools section in project.json:

"tools": {
  "Microsoft.EntityFrameworkCore.Tools": {
    "version": "1.0.0-preview1-final",
    "imports": [
      "portable-net45+win8+dnxcore50",
      "portable-net45+win8"
    ]
  }
}

ヒント

Visual Studio を使用する場合は、(これがサポートされていません RC1 で) ASP.NET Core プロジェクトの EF コマンドを実行するパッケージ マネージャー コンソールを使用することができますようになりました。If you use Visual Studio, you can now use Package Manager Console to run EF commands for ASP.NET Core projects (this was not supported in RC1). 内のコマンドを登録する必要があります、toolsproject.jsonこれを行う。You still need to register the commands in the tools section of project.json to do this.

パッケージ マネージャーのコマンドが PowerShell 5 が必要です。Package Manager Commands Require PowerShell 5

Visual Studio でパッケージ マネージャー コンソールで、Entity Framework のコマンドを使用する場合は、PowerShell 5 がインストールされている必要があることを確認する必要があります。If you use the Entity Framework commands in Package Manager Console in Visual Studio, then you will need to ensure you have PowerShell 5 installed. これは、次のリリースで削除される一時的な要件 (を参照してください発行 #5327の詳細)。This is a temporary requirement that will be removed in the next release (see issue #5327 for more details).

Project.json での"imports"の使用Using "imports" in project.json

EF Core の依存関係のいくつかまだサポートされていません .NET Standard です。Some of EF Core's dependencies do not support .NET Standard yet. .NET Standard および .NET Core プロジェクトでの EF Core は、一時的な回避策として、project.json には、"imports"を追加する必要があります。EF Core in .NET Standard and .NET Core projects may require adding "imports" to project.json as a temporary workaround.

EF を追加するときに NuGet の復元によってこのエラー メッセージが表示されます。When adding EF, NuGet restore will display this error message:

Package Ix-Async 1.2.5 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Ix-Async 1.2.5 supports:
  - net40 (.NETFramework,Version=v4.0)
  - net45 (.NETFramework,Version=v4.5)
  - portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
Package Remotion.Linq 2.0.2 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Remotion.Linq 2.0.2 supports:
  - net35 (.NETFramework,Version=v3.5)
  - net40 (.NETFramework,Version=v4.0)
  - net45 (.NETFramework,Version=v4.5)
  - portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)

回避策では、「ポータブル net451 + win8」ポータブル プロファイルを手動でインポートします。The workaround is to manually import the portable profile "portable-net451+win8". この強制的に NuGet がこれに一致するこのバイナリを処理するは、ない場合でも、.NET Standard を使用した互換性のあるフレームワークとして指定します。This forces NuGet to treat this binaries that match this provide as a compatible framework with .NET Standard, even though they are not. 「ポータブル net451 + win8」は、.NET Standard と互換性のある 100% ではない、.NET standard PCL からの移行に十分な互換性です。Although "portable-net451+win8" is not 100% compatible with .NET Standard, it is compatible enough for the transition from PCL to .NET Standard. EF の依存関係は、最終的に .NET Standard にアップグレードする場合、インポートを削除できます。Imports can be removed when EF's dependencies eventually upgrade to .NET Standard.

複数のフレームワークは、配列の構文で、"imports"に追加できます。Multiple frameworks can be added to "imports" in array syntax. 他のインポートをプロジェクトに追加のライブラリを追加する場合は、必要があります。Other imports may be necessary if you add additional libraries to your project.

{
  "frameworks": {
    "netcoreapp1.0": {
      "imports": ["dnxcore50", "portable-net451+win8"]
    }
  }
}

参照してください発行 #5176します。See Issue #5176.