I use Entity Framework 7.0.0-beta7. If I want to update my database with 'dnx ef update database' I get a 'done'. But nothing happend.
Is there a way to manually (in code) start the migration and debug it?
Update: no it works
I moved the mode back to the web project,
called 'dnvm install latest'
called 'dnx ef database update -c myContext' because I have more
I meet a same issue in EF RC1. and i have a finding, hope it can help you.
i create a project to involve entity model and EF DBContext. then web project reference the project.
run these commands, not working:
dnx ef migrations add MyFirstMigration
dnx ef database update
results
but when i move the DBContext class to my web project, models still in other project, it working fine.New result
so in my scenario need make sure DBContext in Web project.
****Database Migration in Entity Framework 7 Asp.net 5 Mvc 6****
run cmd
C:>Path of Project>dnvm install -1.0.0-rc1-final
C:>Path of Project>dnvm use -1.0.0-rc1-final
C:>Path of Project>dnx ef migrations add InitialMigration
C:>path of Project>dnx ef database update
if you use multiple DbContext then we need to specify Dbcontext
C:>Path of Project>dnvm install -1.0.0-rc1-final
C:>Path of Project>dnvm use -1.0.0-rc1-final
C:>Path of Project>dnx ef migrations add InitialMigration -c DataContext
C:>path of Project>dnx ef database update -c DataContext
If your project is A and you put your DbContext in a separate class library say B, you need to append .MigrationsAssembly("A") after UseSqlServer(...) in the Startup.cs, please refer to https://github.com/aspnet/EntityFramework/issues/3840
Related
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
I am using EF core 2.X scaffolding existing database. I have generated models classes using "dotnet ef dbcontext scaffold" command and it generate model classes.
Database team has change some table I have to run "dotnet ef dbcontext scaffold" command again to generate model classes to pick only changes.
for example let say
I have one table called "employee" has column id, name.
I run "dotnet ef dbcontext scaffold" to generate models
After that I changed employee table and add one more column called "address" in database. How can I scaffold command to pick changes only .
Note: I know after generating models I should use migration to change database but our db team is has changed db and unfortunately, I have to do this. and advice
You can provide an optional parameter to the scaffolding command to update only the table you target.
Scaffold-DbContext "Server=(localdb)\mssqllocaldb;Database=DatabaseName;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir DirectoryNameOfYourModels -Tables employee -f
If you are using .net core cli then use.
dotnet ef dbcontext scaffold "Server=(localdb)\mssqllocaldb;Database=DatabaseName;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -o DirectoryNameOfYourModels -t employee -f
In my application I enable Code First Migrations with some migrations, Also I use SQL Server Compact for integration test.
When I run my tests, Entity Framework create an empty database and tries to run migration on that empty database and thrown The specified table does not exist.
Based on this report I think usage of Migration in Entity Framework 6 has changed.
I test all Database Initializer with Context.Database.Create(); but in all case tabale's never created.
I don't know that this is EntityFramework's bug or not, but when I made rename the namespace of Migration Configuration class from default (Projectname/Migrations) to any none default name, migration works well.
Context.Database.Create() will not execute migrations! It only creates empty db. To Update database from code to latest version you need to use DbMigrator.Update method:
var migrator = new DbMigrator(new MyMigrationsConfiguration());
migrator.Update();
Alternatively you might use MigrateDatabaseToLatestVersion
Database.SetInitializer(new MigrateDatabaseToLatestVersion<BlogContext, Configuration>());
It is described in details here: http://msdn.microsoft.com/en-us/data/jj591621.aspx#initializer
In case someone still struggles to fix the issue.
The code that follows works for me: add-migration MyFirstMigration
Meanwhile add-migration "MyFirstMigration" with the migration name ramped in quote doesn't work.
There may be previous migration files which the ide may be referring to mostly likely due to caching.
Drop backup and drop target database if it exists, and drop the migration folder.
Now add the migration and you will be good to go.
It does happens when adding model and running add-migration command.
Here is the simplest cause of this issue:
Add a newly added model property into IdentityDbContex class.
Here are the steps:
create model
add property into IdentityDbContex class
run add-migration
update-database
I have been using F# for some time, and really liking it.
I want to use type providers for data access, but would love to have entity framework migrations.
Can I use EF migrations without entity framework? I am fine with writing migration code by hand, hopefully in F#.
In the case where you want to use EFCore, it's possible to isolate only the migrations in a C# project with MigrationsAssembly.
For example in a DbContext module:
let setupOptions (optionsBuilder: DbContextOptionsBuilder) =
optionsBuilder.UseNpgsql(
"Host=localhost;Database=mydb;Username=postgres;Password=postgres",
fun opt -> opt.MigrationsAssembly "MyProject.Data.Migrations" |> ignore)
|> ignore
Services configuration:
services.AddDbContext<DbContext.MyDbName>(DbContext.setupOptions)
CLI:
dotnet ef migrations add CreateFoo -p ./MyProject.Data.Migrations -s ./MyProject.Api -v
dotnet ef database update -p ./MyProject.Data.Migrations -s ./MyProject.Api -v
There is also a work in progress project to support F# design-time:
https://github.com/bricelam/EFCore.FSharp
F# type providers imply that there is already external data source i.e. they are inherently "Db First". Using EF Code First only to automatically generate migrations is not the best idea, I recommend plain SQL and some tools to keep track of migrations such as dbup.
I answered it in details in similar but bigger question.
You can certainly use EF migrations without using EF in your app. Create a separate project and use Code First migrations.
I'm not aware that the migrations scaffolding feature supports F#. Either suffer with C# for migrations or translate the code yourself?
I am using Beta 3 of EF power tools for EF5.0 to reverse engineer an existing database.
When I select "Reverse engineer code first" from the project context menu, I get all the models and the DBContexts + mapping as expected. And all looks good.
I enabled Migrations successfully immediately after the reverse engineering process completed.
However I want to add a new property to one of the models. After adding the new property,
I run PM> Add-Migration AddMyPropertyToMyTable
a Migration file is created,
If I then try PM> Update-Database
I get an error telling me that the tables already exist.
I am following the tutorial here:> http://msdn.microsoft.com/en-us/data/jj200620
Why am I getting this error? of course the table exists, I just reverse engineered it
Am I supposed to delete the database after reverse engineering? Or in the case of a reverse engineered Db, do I have to make my changes to the actual database and just reveres engineer it again to get the desired changes in my project (so what's the point of reverse engineering in the first place?)
is there something missing from the tutorial, i.e. an extra step required to make the database updateable after model changes?
When you enabled migrations with the existing database, EF didn't add the __MigrationHistory table or initial migration (DbMigration) file.
You can add an initial migration by using the following in the package manager console:
Add-Migration Initial -IgnoreChanges
This will be an empty initial migration. Then to force EF to create the __MigrationHistory table, you can use:
update-database
This should then create the __MigrationHistory table (under System Tables)
You should now be able to make model changes, and create new migration files (or use automatic migrations by configuring it in your Configuration.cs file under the Migrations folder).
You can run these migration changes by hand by using update-database, or have the database automatically migrated to the latest migration on application startup by using the MigrateDatabaseToLatestVersion initializer.
You can set this in the app.config/web.config so that it isn't set in production for example.