I have an ASP.NET Core project with a data access layer using EF Core 3.1.8 and also using version 3.1.8 of the cli tools. The presentation layer and the data access layer are in different projects. To run EF commands in the cli, I open a developer command prompt, navigate to the directory containing the data access layer and run a command such as
dotnet ef migrations add MyMigrationName --startup-project ../Site/Site.csproj
or
dotnet ef database update --startup-project ../Site/Site.csproj
Site is just a placeholder here. The actual project name is longer and it is inconvenient to provide the --startup-project argument each time I want to run a command. Is there somewhere I can configure that so that I can run commands more concisely like dotnet ef database update?
Create a file named ef.cmd in the data access layer directory with the following contents:
#dotnet ef --startup-project ..\Site %*
Then you can use:
ef migrations add MyMigrationName
or
ef database update
For completeness, another option is to use response files. This isn't as simple, but can be useful when you have multiple sets of options. (e.g. for multiple DbContexts)
Create a file named something like identity.rsp with the following contents.
--startup-project=..\Site
--context=IdentityContext
And use it like this.
dotnet ef database update #identity.rsp
Related
I have .net Core 3.1 solution with WebApi and Persistance projects. WebApi is the solution's startup project, Persistance is where DbContext is defined. After a lot of reading and trying stuff, I still cannot achieve the following:
WebApi stays as the solution's startup project.
Migrations folder with all the migrations classes is in the Persistance project.
Migrations can be generated from VS Package Manager Console by typing Add-Migration <migration_name> without any additional parameters like -Project or -StartupProject.
No need to change selection in the Package Manager Console Default project dropdown.
I wanted to achieve the same result but on MAC OS. Because Visual Studio on Mac is not like Window's, We use CLI commands. In my case I had Migration Classes in another project and startup was Api project just like you so i added this to my terminal :
alias migrationfortest='dotnet ef migrations add $1 --project /Users/user/Projects/test-web/Test.Infrastructure'
and you can call this simply by typing migrationfortest "YOURMIGRATIONNAME"
NOTE : For CLI command tools you should add This
I'm using Asp.Net Boilerplate (3.8.1) with Entity Framework Core. I have 3 environments (dev, staging, production) so I have 3 appsettings.json in my .Web.Host project (each with default ConnectionStrings pointing to their respective database).
If I launch Update-Database -> my Dev Database (specified in appsettings.json) is correctly updated
Starting with EFCore 2.0, you have to set en env variable to update the staging database (see ef core don´t use ASPNETCORE_ENVIRONMENT during update-database).
I tried that (setting the env variable to staging) and it did not work with my Asp.Net Boilerplate project. I tried quickly with a simple EFCore and setting the environment does not seem to work.
Is there an other way to do that ?
The way I go about doing this is this:
if there are schema changes with a release, then I use the dotnet cli tooling to export the migration scripts.
So For example:
dotnet ef migrations script -i -o "C:\temp\mychanges.sql"
It's an idempotent script that only applies migrations if they haven't already been applied to the database. This is useful if you are deploying to multiple databases that may each be at a different migration.
I know this is that type of question that was asked before but I couldn't find a valid answer to it.
So, is there a possibility to change where migrations are stored? I'm using EF Core.
FYI: I know that if you move the first generated migration, the upcoming ones will be placed in the same location.
For core EF projects, you can specify the output directory with the '-o' or '--output-dir' option after Add-Migration.
Example:
Add-Migration -o Data\Migrations
If using the dotnet core CLI command, you can specify the same option:
dotnet ef migrations add -o Data\Migrations
Sources and more info:
https://docs.efproject.net/en/latest/miscellaneous/cli/powershell.html
https://docs.efproject.net/en/latest/miscellaneous/cli/dotnet.html
How to run those dotnet.exe ef <command> commands programmatically in .NET Core?
For example to add migration I'm running in terminal dotnet ef migrations add NewMigration and it will indeed create Migrations folder with migration classes, but to create new Migration (for example) programmatically from C# code?
Don't suggest Process.Start("cmd bla-bla") since code should be cross-platform and that dotnet ef runs some code from some EntityFrameworkCore package anyway. Question is what code?
EF Core API isn't really designed for the scenario, but if you want to do this anyways, you'll need to repeat the logic that "dotnet-ef.dll" does to gather project context and compilation output, and then instantiate and use MigrationsOperations manually.
See https://github.com/aspnet/EntityFramework/blob/1.0.0/src/Microsoft.EntityFrameworkCore.Design.Core/Design/MigrationsOperations.cs and https://github.com/aspnet/EntityFramework/blob/1.0.0/src/Microsoft.EntityFrameworkCore.Design/Internal/OperationExecutor.cs
Use caution: these are "Internal" APIs, which means their usage may break from version to version. "dotnet ef" is going to change a great deal between the current release (1.0.0-preview2) and the next release. (For example, the entire tooling implementation will change. See https://github.com/aspnet/EntityFramework/issues/5334).
I am currently playing with beta4 of EF7 using the blank ASP.NET web project template.
After having kicked off the existing migration, resulting in the tables being created in the localdb, the following occurs:
Strangely, when I clean up the migration-folder, including removing ApplicationDbContextModelSnapshot.cs and I run
dnx . ef migration add twice, I get the following error:
dnx : System.InvalidOperationException: No data stores are configured. Configure a data store by overriding OnConfiguring in your DbContext class or in the AddDbContext method when setting up services.
The second migration is not created. When I review the created migration it contains all tables whereas the database is already provisioned, so you should expect the migration being empty.
Then, when I remove the first migration and run the add migration command again more than once, all the migrations are correctly created, i.e. as empty files.
Can someone explain this to me? Is this expected behavior or is this a bug in beta4?
Tip for people coming from former EF-versions:
* Don't use the K command framework anymore.
* Don't use the Add-Migration cmdlets anymore.
Both have been replaced by dnx . (dot). (dnx = .NET execution environment)
Some references:
https://github.com/aspnet/EntityFramework/wiki/Entity-Framework-Design-Meeting-Notes---September-11,-2014
http://jameschambers.com/2015/05/project-k-dnvm-dnx-dnu-and-entity-framework-7-for-bonus-points/
Remove the constructor of ApplicationContext. It is a temporary workaround to enable deployment, but it interferes with the Migrations commands.