Documentation on migrations with multiple projects is unclear

[garyapps]

I agree with the other commenter that this article is not very clear. I'd go so far as to say it is pretty badly written.

1. The code snippet refers to "MyApp.Migrations". What is MyApp? Is that the name of the original web project (with dbcontext), or is it the new class library?

2. And what does "startup assembly" refer to? The web app or the class library?

3. The fix for removing the circular reference does not work. If each project is supposed to reference the other, then we should expect a circular reference, which is what we get. The suggested fix does not appear to work (not sure if I am doing it wrong), and since no part of the article explains the reasoning behind any of the steps, one cannot even troubleshoot if these steps didn't work.

4. It would also help to include a few screenshots of how to add a new class library, how to add a reference, and where one can find the XML file where the circular reference fix is supposed to go. After all, we are not all Visual Studio experts.

I have been unable to successfully put migrations in a separate assembly, so I would say this article has not helped me at all.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: b545eeff-6c33-3cc0-09ce-a3ad342d7438
• Version Independent ID: 34bc1bac-7338-d8ab-390d-8c5e88a48c10
• Content: Migrations with Multiple Projects - EF Core
• Content Source: entity-framework/core/managing-schemas/migrations/projects.md
• Product: entity-framework
• GitHub Login: @bricelam
• Microsoft Alias: bricelam

[mloffer]

Seconded.

Number 3 says Move the migrations and model snapshot files to the class library.
Do I just move the files, or do I also need to change the namespace?

Number 4 says Configure the migrations assembly.
But the code listed after it looks like code I would expect to see in the original DbContext assembly. Where does this go in the Migration assembly? How about a filename?

[famoser]

With the help of https://github.com/bricelam/Sample-SplitMigrations I could create a setup which allows to use the same migrations for both my App and my unit tests. It is what I wanted to accomplish when reading the documentation, hopefully this usecase helps someone else; and possibly when enhancing the documentation.

Setup:

• Data (contains MyDbContext & entities)
• Migrations (contains Migrations; references Data)
• App (contains startable .Net Core app, references Data + Migrations)
• Test (contains unit tests, references App + Data + Migrations)

Usecase:
I want to use same migrations for both App & Test.

How to prepare:

• Create projects & link appropriately
• execute dotnet ef migrations add InitialMigration --startup-project ../App/ inside the Migrations folder
• in the App, you need to initialize MyDbContext as follows:

 services.AddDbContext<MyDbContext>(options => options.UseSqlite(connection, x => x.MigrationsAssembly("Migrations")));

Now you can

• execute dotnet ef database update inside the App folder which upgrades the App database
• use the MyDbContext in your unit tests, applying migrations manually

Unit Test example code:

[TestClass]
public class MyUnitTest
{
	[ClassInitialize]
	public static void SetUp(TestContext testContext)
	{
               //setup DI
		var services = new ServiceCollection();
		services.AddDbContext<MyDbContext>(options => options.UseSqlite("DataSource=test.sqlite", x => x.MigrationsAssembly("Migrations")));
		var serviceCollection = services.BuildServiceProvider();

		//migrate db
		var context = serviceCollection.GetService<MyDbContext>();
		context.Database.Migrate();
	}
}

[fizxmike]

... but how to migrate with continuous delivery (like in Azure DevOps)? Deployment tasks typically access build artifacts only. Is there a way to run migrations after build? Or do I need to include source in the artifacts and add dotnet SDK to task environment? Is dotnet ef database update equivalent to myDbContext.Database.Migrate();?

[famoser]

You can run any commands in the post deployment script of your release task. I did not need any special configuration (I am using a release pipeline which Visual Studio setup automatically). I do not know if its completely equivalent, but I've used both and did not run into any issues.

[fizxmike]

Azure DevOps is a bit different. The "release" pipelines begin with artifacts (from builds) only. Another complication is I'm doing a self-contained deployment (no dotnet core runtime on target machines), I essentially only have access to the compiled binaries (.exe and dll) at deploy time. I ended up adding a stage in my pipeline to call the .exe with a command line argument which triggers context.Database.Migrate(). I'm hoping this has same behavior as dotnet ef database update. What I'm seeing so far is it is "silent" (no output). Hmm...

[asad-c]

The documentation is too brief, but I've managed to get it working as follows (whilst also adhering to Onion Architecture):

1. Create a class library 'App.Core'

• Add a 'Country' domain model to this library:

public class Country
{
	public int Id { get; set; }

	public string Name { get; set; }
}

• This is just a simple class to get things working quickly

2. Create a class library 'App.Infrastructure'

• Add a DbContext to this library:

public class AppDbContext : DbContext
{
	public DbSet<Country> Countries { get; set; }

	protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
	{
		optionsBuilder.UseSqlServer(@"Server=localhost;Database=App;Trusted_Connection=True;",
			x => x.MigrationsAssembly("App.Migrations"));
	}
}

• 'App.Migrations' will be our separate class library just for migrations

• 'App.Infrastructure' needs to reference 'Microsoft.EntityFrameworkCore.SqlServer' and 'Microsoft.EntityFrameworkCore.Tools'

3. Run dotnet ef migrations add InitialCreate

• Do this from the command line in the 'App.Infrastructure' directory

• This will create a 'Migrations' folder in your 'App.Infrastructure' class library with a migration called 'InitialCreate'

4. Create a class library 'App.Migrations'

• Move the 'Migrations' folder from 'App.Infrastructure' to 'App.Migrations' - you will need to update the namespaces after the move

• Add a project reference in 'App.Migrations' to 'App.Infrastructure'

• Edit the .csproj file for 'App.Migrations' and add an output path:

<PropertyGroup>
	<TargetFramework>netcoreapp2.1</TargetFramework>
	<OutputPath>App.Infrastructure\bin\$(Configuration)\</OutputPath>
</PropertyGroup>

• The above path will be correct if 'App.Infrastructure' and 'App.Migrations' are in the same directory, if not, the output path will need to be adjusted

• On build this results in 'App.Migrations' being output to the 'App.Infrastructure' bin directory - we need to do this as we can't reference 'App.Migrations' in 'App.Infrastructure' as this results in a circular reference, so this is a workaround

5. Build the solution

6. Run dotnet ef database update from the command line in the 'App.Infrastructure' directory and this should create the database and create the 'Countries' table

7. Run dotnet ef migrations add AddCity --project App.Migrations for your next migration

• 'AddCity' is just another migration to create a 'Cities' table - this requires adding a 'City' class and updating the DbContext

• Run the command from the 'App.Infrastructure' directory and the migration will be added to the 'App.Migrations' class library

8. Remember to rebuild the solution every time a migration is added