This feature provides a single entry point for creating an EF model that shows developers all the options that are available and helps them find the option that is right for them.


The Problem

There are a number of different entry points for creating a new EF model and no easy way for a developer to see all the options that are available and make an informed decision about which to use.

  • For EF Designer based models that target a new or existing database you use Add -> New Item… -> ADO.NET Entity Data Model.
  • For Code First models that target an existing database you install the EF Power Tools and use the Reverse Engineer Code First tool. You can also just start hand writing code to map to an existing database (this is one of the benefits of Code First and will continue to be a valid and supported option).
  • For Code First that target a new database you just start writing code (this is one of the benefits of Code First and will continue to be a valid and supported option).


The Solution

Update the Add -> New Item -> ADO.NET Entity Data Model wizard to support creating Code First models. The first screen will allow developers to select a Code First model or an EF Designer model. They can also choose between a new and existing database.


  • Selecting Code First from database will use the existing wizard screens for EF Designer based models but will then use the functionality from the EF Power Tools to produce a Code First model.
  • Selecting Empty Code First model will add a template derived DbContext to the user’s project.
  • The existing functionality for EF Designer based models will remain in place

Last edited Feb 12, 2014 at 4:59 PM by RoMiller, version 7


rscholey Apr 16, 2014 at 2:27 PM 
Using PowerTools I (and I think a few thousand others) used to be able to get all the mapping files created for us automatically. Who was the person who decided we didn't need this any more? If you want to add a new dialog I think it would be good not to remove existing functionality that many people use. Well for me it's a case of back to using the PowerTools beta. At least that gives me what I need. Sad that nobody on your team was able to realize that people might not like it when you take away functionality :-(

moozzyk Mar 18, 2014 at 5:00 PM 
@rubayat: Did you install the msi from the links provided in the Adding just EF6.1 NuGet package will not update the tooling.

rubayat Mar 18, 2014 at 12:58 PM 
I am using vS2012 ultimate edition. I have installed Entity Framework 6.1 but not being able to get this feature. Is there any additional tooling I need to install? Or am I going to get this tooling feature?

bazil749 Feb 19, 2014 at 6:56 PM 
Some questions:
- Will the EF PowerTools be deprecated? If so, how would be "Generate Views" for a Context?
- Will there be an option to move back to individual mapping files vs. the large context?

gfaraj Feb 19, 2014 at 5:13 PM 
I tried this, and while there are some improvements (like being able to select the objects you want), it seems like some things need work.

- It's using a combination of annotations and Fluent API. An option to select whether you want only Fluent API or a combination would be better.
- The Fluent API mapping is getting included in the DbContext class instead of separate classes. You can imagine for a database with lots of tables, it can get huge. An option for this would be good as well.
- An option to make entity / field names in a proper C# convention (capitalized camel case).
- It's not adding HasColumnName calls to fields. An option to do this or not would be good.

As it stands I cannot use it to reverse-engineer my database the way I want it. Not everyone has the same needs, that's why adding options would be something good.

jemiller Feb 8, 2014 at 5:21 PM 
I agree with what jlerman said. I have had problems with the code generating running really slow, many hours on a model that had about 1,250 tables. I know this is a lot of tables, but, whatever it was doing seemed to be very inefficient. I ended up creating my own code generator and it runs in a matter of seconds. Also, if it's switching over using attributes instead of fluent API calls, I think that will be an improvement. That was another reason I created my own generator. While developing the generator, I found that it looked like there were holes in the ADO.NET Core API with regard to retrieving database metadata. It appeared that the key values for different metadata varied from one provider to another. For example, SQL Server had differently named keys than MySQL. I think the underlying Core API should be fixed as well, so that it works consistently across providers. There are also some cases where you can't solely use attributes. There were a few cases where I had to use the fluent API do to oddities in the legacy database schema that I was trying to generate a model for. It would be good if whatever holes there are in the attributes could be fixed as well. Ideally, you should be able to specify everything using attributes.

BriceLambson Jan 16, 2014 at 4:44 PM 
@vish2014 It will not affect the existing Database First workflow, but it will enable users who have an existing database to choose between an EDMX-based model or a Code First model.

BriceLambson Jan 16, 2014 at 4:41 PM 
@lucamorelli The current plan is to scaffold data annotations by default, but allow you to easily customize the code generation process to create fluent API calls instead.

vish2014 Jan 15, 2014 at 7:11 AM 
will it anyway benefit or affect Database first approach?

jbeckton Jul 14, 2013 at 7:15 PM 
Any idea as to when this feature will be available?

jlerman Nov 8, 2012 at 7:45 PM 
I know you know that I'm chomping at the bit for the code first reverse engineer tool to let us pick objects. I love this solution but am worried about how far off it will be. If very far, is it possible to just tweak the power tool for now? Look at this email I just got:
"I used the EF PT Beta 2 tool ... my dual-quad-core-Xeon with 24GB RAM and SSD drive ThinkStation huffed and puffed for about two hours, created 868 new classes and an equal amount of mapping classes using Fluent API … and it is still huffing and puffing … "

lucamorelli Sep 18, 2012 at 9:40 AM 
with code first may be nice the option to choose the use of attribute or EntityTypeConfiguration mapping class to define the properties

HansKrJensrud Aug 28, 2012 at 5:18 PM 
It may be an idea to set preferred "EF Model Type in charge" as an overall EF property to get more attention to selecting the preferred working environment rather than how to get started. After the preferred working environment is selected it may be specified how to get started in this environment and which options to use in this case e.g. how the to other options (if selected) should be kept current/synchronized. By using this method, it should also be possible to change the preferred working environment. By using this method all options would be presented up-front and successive choices would hopefully follow in a natural manner. A change to one of the two other options should result in a question about changing the EF Model Type in charge or make an update to the model type in charge (and keep the selected model type as preferred). This may also prepare for a future with more model types, or a fully automated synchronized model which makes no difference independent of where the changes are made (as with WPF where it is the same if changes are made on screen or in in XAML).

fujiy Aug 28, 2012 at 11:54 AM 
Would be nice if Code First from Database preserve previous manual changes as Designer Model does