14

Closed

Migrations: Allow context and migrations to be in separate projects

description

As it stands now, the Migrations tooling prevents you from creating your DbContext and DbMigrationsConfiguration classes in different projects.

Steps:
  1. Create Project1 with a DbContext in it (start-up project)
  2. Create Project2 with a DbMigrationsConfiguration that references Project1 (migrations project)
  3. Call Add-Migration
Result:
Could not load assembly 'Project2'. (If you are using Code First Migrations inside Visual Studio this can happen if the startUp project for your solution does not reference the project that contains your migrations. You can either change the startUp project for your solution or use the -StartUpProjectName parameter.)

Problem:
Because Project1 is the startup project, Migrations executes in its output directory. However, Project2.dll doesn't exist in that directory because the assembly reference goes from Project2 to Project1.

Proposed solution:
Ideally, we need a solution that can use Project1's configuration file and assembly resolution, but that can also resolve the Project2 assembly and all of its dependencies.
Closed Apr 3, 2013 at 6:34 PM by lukew
Confirmed fixed

comments

ajcvickers wrote Apr 2, 2013 at 8:52 PM

Fixed in 0fb4f1638f90

MigrationsAreEmigrating (Allow migrations and context to live in different projects)

This change adds a new option of ContextProjectName for Enable-Migrations that, when specified, makes Migrations look in the given project for the DbContext for which Migrations should be enabled. Note that both the migrations project and the context project must have the Entity-Framework package installed, and ultimately the migrations project must have a reference to the context project, although this is not needed to actually run the Enable-Migrations command.