We Keep Coding

Entity Framework Core Update Database - Code First Approach Without Migration

I've been searching for a way, it may or may not be supported yet, I guess I'm looking for a concrete answer.
What I've been looking for is the solution for the following requirements:
EFCore Code First Approach
With existing database table with significant amount of data already in place
Add a couple of columns to the said database table by updating my model
No migrations through PM Console, just using Context with Fluent Api at application start
No database recreation
The approach can be: Check a configuration file or some sort, compare it against the version in a version table in database to trigger the update
Project templates: Web Api 2, Uwp
If this is supported, is it advisable? If not, why? what are the disadvantages?
In my experience with the projects I was part of, either database first approach or code first but with database recreation.
The steps I have in mind are:
- Update the model
- Create migration objects
- Update config file for db version
- At application start, check the config version against version table
- If versions do not match call Update() or Migrate() or both, with Migration objects/types as parameters

This is quite opinion based, but here are my comments.
EFCore Code First Approach
Are you aware of limitations of EF Core? It's linq provider cannot do everything EF6 does. differences between EF and EF Core?
With existing database table with significant amount of data already in place
That's OK.
Add a couple of columns to the said database table by updating my model
This seems standard practice for EF (Core) apps.
No migrations through PM Console, just using Context with Fluent Api at application start
I don't recommend automatic db upgrades because of the risks of the migration done not when you want it. I'd call it accidental-updagrade-database.
No database recreation
I'm not sure what this means, but yes, EF (Core) can work without recreating a db.
The approach can be: Check a configuration file or some sort, compare it against the version in a version table in database to trigger the update
Project templates: Web Api 2, Uwp
The Uwp part seems irrelevant as I assume that all db access will be done via the api app.

What is the use of dbcontext generator in EF 6

I have a MVC project that use Entity Framework 6. I am puzzled as how it is created. Because there is no .edmx file, I guess it must be created as EF 6.x dbcontext generator. So what does dbcontext generator do? Does it create database from the model? If so, how to create database in the model? May I modify the database later and update the model? What are changed in the sources? Thanks.

It's difficult to understand everything you're saying, but it sounds like you have a project which uses the "Code First" approach. There is no .edmx file in this approach. Entity Framework Code First can be used with both new (see: https://msdn.microsoft.com/en-us/data/jj193542.aspx) and existing databases (see: https://msdn.microsoft.com/en-us/library/jj200620.aspx) and with regards to updating it, you could either manually modify the database or you could look into something called "Code First Migrations" (see: https://msdn.microsoft.com/en-us/data/jj591621.aspx), which allows you to add/remove tables and fields via code.

Update Db in EF5 with MVC5

I am working on a project using Entity Framework 5 with MVC5. My Project is currently running.
I am trying to add a column in a table. But as we know that in EF when we add a field in model it drop and recreate the database, which i can`t do.
One method for this is found code migration. But my manager is not allow me to use that(because its a big database project).
Please help me and suggest something for it.

When I start using code first with Entity Framework, I was in the same situation as you. I was always running Update-Database -F and then watching all my tables get dropped and recreated, even for something as simple as renaming a field.
Versioning databases is hard, but it's much easier with named migrations (which I think it what you mean when you refer to code migrations). I know your boss is against the idea, but it's very flexible.
Essentially you run Add-Migration -Name xxx in your Package Manager Console and Entity Framework will scaffold a configuration class for you with the default commands (both for versioning Up() and Down()) it will execute when you Update-Database. If you don't like the commands, you can change them. You can even move data around if you need to (it's a bit fiddly though).
I think you have four options available to you;
Use code-first automatic migrations: This is what you have at the moment, and doesn't give you enough control over what happens when you update your database. It's good for getting started in the earlier stages of a project, but becomes unwieldy after production.
Use code-first named migrations: Gives you the control you need via Configurations - but your boss has prevented use from using it.
Use a database-first approach: Database First allows you to reverse engineer a model from an existing database. So if you need to make a change, you would change your database first, and then regenerate your models using EF. This is usually favoured by DBA's, but it may mean that you have reimplement some aspects of your existing project.
Dont use entity framework: It's possible that you could revert back to SQL queries, which your boss might accept and gives you the flexibility you need - but who needs that kind of pain?
Let me know if I can help further.

Work flow using Code-First -vs- DB-First in starting a new project? EF6

When creating a new solution (typically ASP.Net MVC or API) I usually create a data access project and my web project. In the data access project I typically use EF6 and have been trying to use Code-First so that I can take advantage of the migrations feature.
In the data access project I create a model folder and then in that folder add my classes and my DBContext class. Then I generate my migrations and seed data. This all works ok.
What I was wondering are there more efficient ways of creating this
type of project?
Am I hampering my productivity by going code first?
I know I am not using code generation that the database first process
would use. Can I gain efficiencies by switching to DB first?
What are typical work flows that others use?
OR is there a hybrid approach that people find successful?
I understand that this has been addressed in other posts but my questions is more in context of EF6 and those all seem to be based on EF4.
TIA

Generate DDL Script to create database in Entity Framework

I am creating an application using Entity Framework code-first.
How can I create the database using this model? Is it possible to create the DDL scripts from a code-first approach just like the DDL scripts that can be generated from a model first approach?
Update : Generate a sql server script from Entity Framework code-first architecture

Using Entity Framework Code-First the application, when run, will create the database and tables that support your .Net model classes. Therefore using this approach you don't need DDL scripts as the work will be done for you by the application.
In Entity Framework there has been a lot of effort put into the Migrations tool to enable the deployment of db changes. This is detailed here:
Automatic Code First Migrations
Code First Migrations
This seems to offer the most effective way of deploying db changes to multiple target environments.
Code First is not particularly capable when it comes to local database deltas. If you are doing anything with OnModelCreating within your db context then this will require your database to be deleted then recreated by the code first application. This is required by code first to ensure that the code model and the persistence model are kept synchronised.
These are two good starter tutorials on MVC with an EF component.
Code-First Development with Entity Framework 4
Intro to ASP.NET MVC 3