Running the migration in our Azure DevOps pipeline With that in place we can finally add our first migration: dotnet-ef migrations add InitialMigration -project -startup-project Return new CatalogDbContext(optionsBuilder.Options) OptionsBuilder.UseSqlServer("Data Source=localhost Initial Catalog=catalog persist security info=True Integrated Security=SSPI ") Var optionsBuilder = new DbContextOptionsBuilder() Public CatalogDbContext CreateDbContext(string args) Public class CatalogContextFactory : IDesignTimeDbContextFactory You will only need to specify a valid one if you want to update your database from your local machine using the update command. It won’t actually be used while creating the migration. You can leave the connection string as-is. Add the following class to the MigrationApp project. Therefore, we need to supply something called an IDesignTimeDbContextFactory to let the migrator know how to instantiate the DbContext. The configuring is something we will, later on, do per request and not in the constructor of the DbContext like you usually would. While adding a migration, the DbContext needs to be configured before migrations can be created. We can add this project with the following command: dotnet new console -n ĭotnet add package ĭotnet add / reference / The answer here is to add an additional project that can run, so a console app, for example, which sole purpose is to generate our migrations. A separate project for running your migrations Luckily there’s a better and easier way to do things. That means that whenever you want to add a migration, you have to authenticate with KeyVault. For example, imagine that your app uses Azure App Configuration and KeyVault, and you use a Managed Identity to authenticate them. That’s fine for a small demo application, but you’ll run into all sorts of problems when that project gets more complicated. What then happens is that the app you’re pointing to gets run. So, for our demo here, we could run the command like: dotnet-ef migrations add InitialMigration -project -startup-project DatabasePerTenant.WebApi An additional flag, –project, would then be needed to point to the project that contains the DbContext (or you would need to run that command from within the folder that contains that project file). The tooling supports pointing to a project that does have a runtime using the –startup-project flag. For more information on using the EF Core Tools with. NET Framework that references this project, and set it as the startup project using –startup-project or, update this project to cross-target. NET Command-line Tools with this project, add an executable project targeting. There is no runtime associated with this framework, and projects targeting it cannot be executed directly. Startup project ‘M圜’ targets framework ‘.NETStandard’. You would run into the following error when trying to generate the migration using ‘dotnet-ef migrations add InitialMigration’: The project containing our DbContext is a class library that cannot be run by itself. The command used to generate the migrations needs a project that has a runtime associated. The fact that we added our DbContext in a separate project does make things a little harder here. We need to install a command-line tool to do that: Install dotnet-ef using 'dotnet tool install -global dotnet-ef' It’s time to generate our first migration. Protected override void OnModelCreating(ModelBuilder modelBuilder)Įntity.Property(e => e.TenantId).HasMaxLength(128) Public CatalogDbContext(DbContextOptions options) : base(options) The ones I use here contain the data in my database-per-tenant architecture and make up the Catalog database. Time to add some entities that will represent our database tables. Install them using these commands: dotnet add package Microsoft.EntityFrameworkCoreĭotnet add package ĭotnet add package The second project needs a few NuGet packages. dotnet new webapi -n DatabasePerTenant.WebApiĭotnet new classlib -n Use the following commands to create the two separate projects. That’s what we’re going to do in this example. In most projects, you probably want to split your data layer from your API. TL DR: All code, templates, and pipelines can be found in my repository. Most of what this blog touches can still be used without reading the whole series. This blog is part of a larger series of blogs in which I explain how to set up a database-per-tenant architecture. We will also see how we can deploy those changes in your Azure DevOps pipeline on each release. We will create the models, the DbContext, and the migrations needed to upgrade your database when introducing changes. In this blog, I’ll show you how to get started with EF and Migrations. NET Core API that needs to talk to a database. Entity Framework could be a logical choice when building a.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |