EF 4.3 Released
The information in this post is out of date.
Visit msdn.com/data/ef for the latest information on current and past releases of EF.
Over the last six months we’ve released a series of previews of our Code First Migrations work. Today we are making the first fully supported go-live release of our migrations work available as part of EF 4.3.
What Changed Between EF 4.2 and EF 4.3
The notable changes between EF 4.2 and EF 4.3 include:
- New Code First Migrations Feature. This is the primary new feature in EF 4.3 and allows a database created by Code First to be incrementally changed as your Code First model evolves.
- Removal of EdmMetadata table. If you allow Code First to create a database by simply running your application (i.e. without explicitly enabling Migrations) the creation will now take advantage of improvements to database schema generation we have implemented as part of Migrations.
- Bug fix for GetDatabaseValues. In earlier releases this method would fail if your entity classes and context were in different namespaces. This issue is now fixed and the classes don’t need to be in the same namespace to use GetDatabaseValues.
- Bug fix to support Unicode DbSet names. In earlier releases you would get an exception when running a query against a DbSet that contained some Unicode characters. This issue is now fixed.
- Data Annotations on non-public properties. Code First will not include private, protected, or internal properties by default. Even if you manually included these members in your model, using the Fluent API in previous versions of Code First would ignore any Data Annotations on these members. This is now fixed and Code First will process the Data Annotations once the private, protected, or internal properties are manually included in the model.
- More configuration file settings. We’ve enabled more Code First related settings to be specified in the App/Web.config file. This gives you the ability to set the default connection factory and database initializers from the config file. You can also specify constructor arguments to be used when constructing these objects. More details are available in the EF 4.3 Configuration File Settings blog post.
Known Issues
We’ll keep this section updated with issues that are reported on EF 4.3. A few weeks after the EF 4.3 release, we will publish an EF 4.3.1 patch release that includes fixes to some of these issues.
The known issues with the EF 4.3 release include:
- Errors using MOQ to mock DbContext. See this Stack Overflow question for more details. We will be including a fix for this issue in the 4.3.1 patch release.
- TPC mapping generating “Unknown Columnname” exceptions when accessing the database. We will be including a fix for this issue in the 4.3.1 patch release.
- Not all hard coded column data types are honored in generated databases. If you use the Column data annotation or HasColumnType Fluent API method to hard code a column data type (i.e. xml, money, etc.), this data type is not used when creating the database. We will be including a fix for this issue in the 4.3.1 patch release.
What Changed from EF 4.3 Beta 1
Aside from some minor bug fixes the changes to Code First Migrations since EF 4.3 Beta 1 include:
- Enable-Migrations will now scaffold a code-based migration if the database has already been created. If you use Code First to create a database and then later enable migrations, a code-based migration will be scaffolded that represents the objects that have already been created in the database. (See the Enabling Migrations section of the Code-Based Migrations Walkthrough for more details).
You can use the –EnableAutomaticMigrations flag to avoid a code-based migration from being scaffolded, and have the creation of these objects be treated as an automatic migration. - Added $InitialDatabase constant. This can be used in place of “0” when specifying a source or target migration. For example, migrating down to an empty database can be performed with the Update-Database –TargetMigration:$InitialDatabase command.
- Renamed Update-Database.exe to migrate.exe. The command line tool for applying migrations was originally named to be consistent with the Power Shell command. We’ve now changed it to be more consistent with other command line names.
- Updated migrate.exe so it can be invoked from the NuGet tools folder. In Beta 1 you needed to copy migrate.exe to the same directory as the assembly that contained migrations, you can now invoke it directly from the tools folder. You will need to specify the directory containing your assembly in the /StartUpDirectory parameter. For example:
C:\MyProject\packages\EntityFramework.4.3.0\tools>migrate.exe MyAssembly /StartUpDirectory:C:\MyProject\MyProject\bin\debug - Fixed errors when running migrations commands from Package Manager Console. A number of folks reported errors when using the migrations commands in certain scenarios. We’ve fixed the underlying bugs causing these issues.
- Fixed –Script issues. There were a number of bugs in the scripting functionality of EF 4.3 Beta 1 that prevented you generating a script starting from a migration other than an empty database. These bugs are now fixed.
Getting Started
You can get EF 4.3 by installing the latest version of the EntityFramework NuGet package.
These existing walkthroughs provide a good introduction to using the Code First, Model First & Database First workflows available in Entity Framework:
There are two new walkthroughs that cover the new Code First Migrations feature. One focuses on the no-magic workflow that uses a code-based migration for every change. The other looks at using automatic migrations to avoid having lots of code in your project for simple changes.
Upgrading from ‘EF 4.3 Beta 1’
If you have EF 4.3 Beta 1 installed you can upgrade to the new package by running Update-Package EntityFramework in Package Manager Console.
You may need to close and re-open Visual Studio after upgrading new package, this is required to unload the old migrations commands.
EF 5.0 (Enum support is coming… finally!)
We’ve been working on a number of features that required updates to some assemblies that are still part of the .NET Framework. These features include enums, spatial data types and some significant performance improvements.
As soon as the next preview of the .NET Framework 4.5 is available we will be shipping EF 5.0 Beta 1, which will include all these new features.
Support
This release can be used in a live operating environment subject to the terms in the license terms. The ADO.NET Entity Framework Forum can be used for questions relating to this release.
ADO.NET Entity Framework Team
Comments
Anonymous
February 09, 2012
Excelent job team! Keep up the good job!Anonymous
February 09, 2012
Can someone on the team blog about how to automatically script out the migrations as part of a packaging routine? I'm aware that it involves MigratorScriptingDecorator and DbMigrator but would love to see an example. If I get time, I'll take a swing at it :)Anonymous
February 09, 2012
Great job guys. Can't wait til EF5 beta.Anonymous
February 09, 2012
Oh thank you :)Anonymous
February 09, 2012
Great job!Anonymous
February 09, 2012
@Jarrett Vance - Here is an example of using MigratorScriptingDecorator from code; romiller.com/.../running-scripting-migrations-from-codeAnonymous
February 09, 2012
Y-Y-YEEEEESSS!Anonymous
February 09, 2012
very good .Anonymous
February 09, 2012
Great job!Anonymous
February 09, 2012
Oh great, so first you 'lifted' EF version to 4 to be in sync with .NET 4, and now you are going to go to v5 when the framework is 4.5. Your company must the only major software company that doesn't understand versioning.Anonymous
February 09, 2012
When we are talking about EF 5.0, will be this release also for CoreCLR?Anonymous
February 09, 2012
I think that it good time to close that issue in uservoice siteAnonymous
February 09, 2012
TPC mapping seems to have problems under EF 4.3. :-( I get Exceptions every time I try to access my db. (Unknown Columnname '...' for EVERY property/column in my classes !!!). Has anything changed for TPC mapping in EF 4.3 (compared to 4.2)? TPT mapping is working fine so far....Anonymous
February 09, 2012
What guidance is there regarding when to use EF Migrations and when to use Visual Studio Database projects?Anonymous
February 10, 2012
@Felix: would it be possible for you to provide a small repro? You can click on the "email blog author" link to start an email thread with us.Anonymous
February 10, 2012
@Mike: It may seem counterintuitive at first that EF 5 is EF 5, but it comes from a desire to follow established and sensible rules for versioning—namely, semantic versioning. We blogged about this here: blogs.msdn.com/.../how-we-talk-about-ef-and-its-future-versions.aspx and here: blogs.msdn.com/.../why-entity-framework-vnext-will-be-ef5-and-nothing-else.aspx. It also doesn’t make sense for us to align with the .NET Framework version when we are releasing more frequently than .NET and any point-in-time alignment will quickly become outdated. We recognize that this is confusing, especially now, but we feel that using well-known rules for versioning will help keep versioning much cleaner going forward. Thanks, ArthurAnonymous
February 10, 2012
@Slawek: done!Anonymous
February 10, 2012
Very nice, ThanksAnonymous
February 10, 2012
Absolutely wonderful and right on time!Anonymous
February 10, 2012
Great to work with EF4.3Anonymous
February 11, 2012
Can someone say if the enum support will allow you to map strings to enums, or will it only support int values? This could be bad from a reporting services perspective, where if you are querying the database without EF you would like to see strings rather than ints. It is also a problem to use with legacy databases if only int is supported. Also, I'm wondering if there are plans to improve performance for batch updates? I found that by default the DbContext API is dramatically slower than ObjectContext when working with large numbers of objects. I think this is because DbContext uses a different method of detecting changes. I'd like to switch to DbContext, but, I reluctant to do so because in addition to web apps that I have that use EF, I also have some console apps that do batch updates and DbContext is unacceptably slow. I know that the next version of EF is supposed to speed up queries, but, I'm also hoping that batch update performance isn't overlooked. I'm also wondering if ObjectContext is going to be replaced by DbContext in future versions of EF? Also, I'm wondering if the built-in validation will be supported with ObjectContext in the future, or, do you have to use DbContext for that? It would also be nice if the tools like the reverse engineer from database function, had an option to generate classes with attributes rather than using the fluent API.Anonymous
February 11, 2012
What happened to enum support that came with June 2011 CTP? Is that still functional if I upgrade to EF 4.3 ?Anonymous
February 11, 2012
The migration doesn't recognize [Column(TypeName = "xml")] and the column data type is still vchar(max) code: [Column(TypeName = "xml")] public string Data { get; set; } I asked this question in the forum over one month but no one replied me. social.msdn.microsoft.com/.../d741358c-9558-48f8-b515-7246d9f45873Anonymous
February 11, 2012
There seems to be a bug in this blog software. If you let the page sit for awhile and then attempt to post something, I think the session times out and it doesn't go through. It doesn't display an error of any kind. Also, if you don't login and you just try to enter your name and make a post it doesn't seem to work.Anonymous
February 11, 2012
The comment has been removedAnonymous
February 12, 2012
@DotNetWise: as mentioned in the post, enum support is coming in EF 5.0, which will be in beta pretty soon.Anonymous
February 12, 2012
@Scott Xu: sorry no one answered in the forums. We will look at this issue and come back here with an answer.Anonymous
February 12, 2012
@Rodrigo Juarez: we are already looking at this. We will come back here and in StackOverflow with an answer.Anonymous
February 12, 2012
@Jon Miller2: You have many questions :), so I have decided to answer them inline: >> Can someone say if the enum support will allow you to map strings to enums, or will it only support int values? This could be bad from a reporting services perspective, where if you are querying the database without EF you would like to see strings rather than ints. It is also a problem to use with legacy databases if only int is supported. EF 5.0 can only map enums to integer columns in the database. We have a separate feature in our backlog to support transformations and type conversions but we haven’t started development of that. >> Also, I'm wondering if there are plans to improve performance for batch updates? EF 5.0 won’t support batch updates but we have this as one of the highest priorities for future versions. Incidentally is #2 in our UserVoice site at http://ef.mswish.net. I encourage you to vote. >> I found that by default the DbContext API is dramatically slower than ObjectContext when working with large numbers of objects. I think this is because DbContext uses a different method of detecting changes. I'd like to switch to DbContext, but, I reluctant to do so because in addition to web apps that I have that use EF, I also have some console apps that do batch updates and DbContext is unacceptably slow. I know that the next version of EF is supposed to speed up queries, but, I'm also hoping that batch update performance isn't overlooked. We have tested DbContext and ObjectContext performance in several scenarios and we haven’t found evidence that DbContext is inherently slower than ObjectContext with a large number of object. In fact, both use the same implementation for change tracking (i.e. DbContext wraps ObjectContext and relies on its implementation). The one relevant difference between the two is that DbContext performs automatic change detection while in ObjectContext you have to call DetectChanges explicitly if you need changes to be detected before SaveChanges. You can however disable automatic change detection in DbContext when you want to perform a batch of changes without incurring in change detection overhead. See the following blog post for more information: blogs.msdn.com/.../using-dbcontext-in-ef-feature-ctp5-part-12-automatically-detecting-changes.aspx. In any case, neither of ObjectContext or DbContext currently support batching UPDATE, INSERT and DELETE operations against the database. >> I'm also wondering if ObjectContext is going to be replaced by DbContext in future versions of EF? We definitively recommend using DbContext for new applications and plan on investing the most on improving this API. We understand that replacing ObjectContext with DbContext in existing applications would be a lot of work because the APIs are different but you might want to consider this if you want to take advantage of new features. >> Also, I'm wondering if the built-in validation will be supported with ObjectContext in the future, or, do you have to use DbContext for that? We don’t have plans to add built-in validation support for ObjectContext. >> It would also be nice if the tools like the reverse engineer from database function, had an option to generate classes with attributes rather than using the fluent API. Thanks for the feedback on this. We have heard before this request for the EF Power Tools and we will look at it. >> There seems to be a bug in this blog software. If you let the page sit for awhile and then attempt to post something, I think the session times out and it doesn't go through. It doesn't display an error of any kind. Also, if you don't login and you just try to enter your name and make a post it doesn't seem to work. Thanks. I have experienced this myself. I will find someone to report it.Anonymous
February 12, 2012
@Diego B Vega - Enum support from june CTP is still functional with 4.3 go live if the .NET framework target platform is set to Microsoft Entity Framework June 2011 CTPAnonymous
February 12, 2012
@DotNetWise: Things might work by accident but this is certainly not a recommended configuration. System.Data.Entity.dll in the June 2011 CTP has Code First and DbContext functionality built in, so if you have references to both System.Data.Entity.dll and EntityFramework.dll your project you should be seeing lots of duplicate classes.Anonymous
February 12, 2012
You can't use both, especially if you are using System.Data.Objects Is there any reason System.Data.Objects doesn't show up in EntityFramework.dll ? You can't use ObjectQuery<T> from just EntityFramework.dll and I am wondering why there is not a separate full installer of EF 4.3 like it was for 4.2 (June CTP at least) - other than just NuGet with EntityFramework.dll More the less, I would like EF to be in the GAC and not in every single project as dllAnonymous
February 13, 2012
The comment has been removedAnonymous
February 13, 2012
@Diego Thanks for answering my questions. Much appreciated. Yeah, after posting that I found a document that explains what you were saying about the DetectChanges() and how DbContext calls it a lot more than ObjectContext. I did a test and inserting 10,000 rows took about 55 seconds with automatic change detection enabled. When I turned it off, it only took 3 seconds. ObjectContext took about 2.5 seconds. I think DbContext uses ObjectContext internally? Another thing that I noticed that was causing the slowness was that I used the Generate DbContext template from the EDM designer to generate my classes. I noticed that the template doesn't add virtual to the properties. Hence, it wasn't using change tracking proxies (and was using snapshots instead) which was slowing it down a lot. If I remember correctly, once I added virtuals to the properties, it cut the time down to about 20 seconds with auto detection still enabled. So, not using the proxies slows things down. I'm guessing that virtuals weren't added to make debugging easier or something? Now that I know the part about detect changes, I feel more comfortable switching to DbContext. The slowness was my main area of concern. Other than that, I prefer the simplified API surface and other niceties such as the built in validation. Keep up the good work! One other thing I was thinking is that it would be nice if the EDM designer let you set more properties than it does right now. For example, it would be nice to be able to specify that a field is required or not, specify regular expression validation rules, etc. That way you wouldn't have to specify separate metadata classes to do validation. It would also be nice to be able to specify the Display Name for entity properties and have it do something like default the value to the property name with spaces in between upper and lower case letters. e.g. default FirstName to First Name.Anonymous
February 13, 2012
Its a pain not being able to use a direct download link to update the libs in our solution (we dont use nuget because its not nice to use with Team Foundation Server and deployment scenarios). A simple download link ( that I am able to find ) would be really nice.Anonymous
February 13, 2012
The comment has been removedAnonymous
February 13, 2012
What about Auto-Compiled LINQ queries ? Is it implemented in this release ?Anonymous
February 14, 2012
@Zefo: No, auto-compiled query us coming soon in EF 5.0. Stay tuned in this blog for more details about the feature.Anonymous
February 14, 2012
@Arthur: We will try using NuGet again. I didnt know that you are able to configure nuget to use our own lib folders for its packages.. Thanks.. Greetings HolgerAnonymous
February 14, 2012
@Holger K: Sorry if I implied that NuGet will automatically use your libs folder instead of the packages folder in your solution. I don't think it does that automatically--you would have to get the package, unzip it, and manually put the assembly in your libs folder. That being said, it would be nice to allow NuGet to do this so maybe you could file a bug/DCR against NuGet to support it?Anonymous
February 14, 2012
Upgraded from EF 4.1 to EF 4.3. I installed from NuGet into one project in a solution. Started getting AccessViolationExceptions in calls to EntityFramework. These kind of issues can be tricky debug. Found through the modules list that some other projects referenced EF 4.1 still so 4.1 and 4.3 were loaded in the same process. Running install-package in each project referencing EF fixed the issue.Anonymous
February 14, 2012
Can you give some feedback on these two related issues: stackoverflow.com/.../ef-4-3-migrations-throwing-unable-to-open-configsource-file and stackoverflow.com/.../entity-framework-4-3-update-database-when-configuration-files-are-separatedAnonymous
February 14, 2012
The comment has been removedAnonymous
February 15, 2012
@Ladislav Mrnka & @ Have a problem with connectionstrings… – Our team is looking at these issues now to see if we can add support in the 4.3.1 patch release.Anonymous
February 15, 2012
Hi, I would like to ask, if there will be any changes in extensibility for EF 5.0. I noticed, that there is a method called CreateDbCommandDefinition in DbProviderServices. It has a DbCommandTree parameter. Unfortunately there is no way to rewrite that command tree, because everything is private/internal. I would like to some minor modifications to query (like WHERE clauses). Would this be possible in EF 5?Anonymous
February 15, 2012
@Vladimir: DbExpression trees become publically constructible in the EF core libraries included in .NET 4.5. You might want to take a look at DbExpressionBuilder if you have the June 2011 CTP bits available or wait for .NET 4.5 beta. There is also a public eSQL parsers. Unfortunately, we are still not going to expose the necessary public API to create expressions associated with O-space metadata, so only C-space trees are supported for now.Anonymous
February 16, 2012
I wanted to share a problem I had, and the solution I found. I had installed (quite some time ago) EF 4.1 Update 1 which installed EntityFramework.dll in the GAC. For my more recent projects, I have been using EF 4.2 through NuGet. I upgraded a project to use 4.3 because I wanted to integrate migrations (thank you so much for migrations). I changed my database initializer to inherit from MigrateDatabaseToLatestVersion. Everything worked great until I started editing a view in the WPF designer. The view would appear briefly but would quickly disappear to be replaced by stack trace from a TypeLoadException. It was telling me that DbMigrationsConfiguration could not be found in EntityFramework.dll. My Views and my ViewModels are in separate assemblies and the View assembly (which is also the EXE) does not directly reference EntityFramework.dll. After some frustrating and fruitless Googling, it occurred to me to uninstall EF 4.1 Update 1. This fixed the problem. To me this seems like more an issue with Visual Studio 2010 than with EF 4.3. But I wanted to share the issue here, in case any else had the same problemAnonymous
February 20, 2012
Does this version support table-valued functions (IQueryable) ?Anonymous
February 21, 2012
@szilardd: Table valued functions will be included in EF5.Anonymous
February 21, 2012
Does this version support .net framework 3.5 ? why? I am hate .net framework updates fastestAnonymous
February 22, 2012
@foxidea EF 4.3 requires .NET 4. EF 5.0 will require .NET 4.5.Anonymous
February 24, 2012
I have very bad experience with version 4.3, because TPC mapping is probably broken. Machine translation of my article (original in Czech): http://tinyurl.com/7k5sjyz Code for repro: http://tinyurl.com/739nmfjAnonymous
February 24, 2012
@Rene Stein: Thanks for reporting this and for the repro. What you describe seems to be a bug in TPC mapping that we are already aware of and that we are planning to fix in the upcoming EF 4.3.1. Please take a look at the list of known issues above for more information.Anonymous
February 24, 2012
Diego B Vega: Thanks for your comment. I saw the known issues before my comment, but I am confused that description of the mentioned problem "TPC mapping generating “Unknown Columnname” exceptions when accessing the database." means "TPC mapping does not work at all and you will not be able generate databaze with required schema" ;)Anonymous
February 26, 2012
Will EF 5.0 beta include EF 4.3 features?Anonymous
February 26, 2012
@Varge John: yes EF 5.0 beta will contain a superset of EF 4.3 features.Anonymous
February 26, 2012
I'm glad to hear that. Will it include 4.3.1 patch too? I'd like to be able to continue a project from Beta up to RTM, whilst retaining 4.3 support for migrations and 4.3.1 fixes that are important.Anonymous
February 26, 2012
@Varga John: yes, EF 5.0 beta will include all the same fixes as EF 4.3.1.Anonymous
February 27, 2012
What would be incredibly intriguing to me is if you somehow leveraged the SQL Server Developer Tools to provide a total solution for managing the schema and mapping within a single unified solution. Having the actual DB scripts with up down migrations between versions in source control would be awesome!Anonymous
February 27, 2012
The comment has been removedAnonymous
February 28, 2012
Where can I report issues. I think I have identified a couple of them regarding migrations: a) When a table name changes the indexes names are not changed, and this can cause troubles in future migrations. b) When you create a class with an int key, create the table, and after that you set the DatabaseGeneratedOption to none on that field, the DbMigrations ignore it. Thanks!Anonymous
March 01, 2012
The comment has been removedAnonymous
March 01, 2012
Bug in EF 4.3 Code First This: public class { [Key] public Post Post { get; set; } [Key] public string Tag { get; set; } } Creates a table with a primary key on just the second column - Tag - which can never be migrated away from because Update-Database fails with an exception trying to drop the PK constraint on the first column. See also: stackoverflow.com/.../9524822Anonymous
March 02, 2012
@Chris Moschini - Someone from our team will follow up on your Stack Overflow question shortly.Anonymous
March 03, 2012
OK so now I am really confused. I looked in June CTP - DbExpressionBuilder is public. And than I looked to .NET 4.5 beta and the System.Data.Entity.dll(4.0.30319.17020) is just some metadata library and DbExpressionBuilder is internal again. I obviously can't find proper 4.5 version of that assembly. May this be because of some problems during VS 11 beta installation? (some problems with missing multi targeting msi)?Anonymous
March 03, 2012
@Vladimir Fedorco: DbExpressionBuilder is indeed public in .NET 4.5. My guess is that you are looking at the DLL file under Reference Assemblies which contains only metadata. You should be able to find the .NET 4.5 version of System.Data.Entity.dll under %systemroot%Microsoft.NETFrameworkv4.0.30319 alongside all .NET 4.5 framework assemblies. .NET 4.5 is an in-place update, meaning that .NET 4.0 assemblies are replaced with new versions when you install it.Anonymous
March 04, 2012
Hi Diego, will there be sometimes possibility to set sorting with loading childern collection(with load) or actually also with lazy loading? I have problems with it when I use databinding with datagridview in winforms and in grid I need custom sorting on children collection.Anonymous
April 17, 2012
I don't like the NuGet only feature either. It mucked up my folder tree, source control, modified the wrong project, did not add any templates. The 4.1 download was fine. Don't force me to use NuGet.Anonymous
April 22, 2012
While I was searching for a way to programmatically automatically update the database in a way similar the "Update-Database" cmdlet, I found that a lot of people were looking for this, but nobody knew how. So I threw it into my blog. Here's the URL: joshmouch.wordpress.com/.../entity-framework-code-first-migrations-executing-migrations-using-code-not-powershell-commandsAnonymous
April 23, 2012
@Joshua R. Mouch - There is also some more information on using migrations from code here; romiller.com/.../running-scripting-migrations-from-codeAnonymous
May 03, 2012
A EF CodeFirst code generator: salardbcodegenerator.codeplex.comAnonymous
May 05, 2012
The comment has been removedAnonymous
May 07, 2012
@Marcel Bradea - I've added an item to our backlog to add this feature. It wasn't something that we were planning to add. In the meantime this post shows how to produce scripts from code, so it's pretty easy to write your own temporary utility - romiller.com/.../running-scripting-migrations-from-codeAnonymous
May 22, 2012
Concur with Marcel Bradea: adding /Script to the migrate.exe program would be nice. Rolling your own console app is a pain for such a generic feature.Anonymous
May 27, 2012
Does EF 4.3 Migrations also needs Full trust as it was in CTP? blogs.msdn.com/.../code-first-migrations-august-2011-ctp-released.aspxAnonymous
May 29, 2012
@Scott Stafford - Thanks for the feedback also. We're pretty much locked down on EF5 so it's not going to be in this release but we'll try and get it into the next release. @IsmailS - Migrations can now be run in partial trust.Anonymous
June 07, 2012
Do not improve the performance of no useAnonymous
July 08, 2012
Should the code first approach not be completely avoided as the only part of an application which survives for more than 10 years is the database. The resulting database from a technology, version specific software is not maintainable or reusable. (We won't mention the performance aspect.) Why is so much time being invested in code first, is everyone writing school or hobby applications now?Anonymous
July 09, 2012
@Dan - Code First is really just another alternative to modeling in the designer and can be used to generate a database or map to an existing database, in the same way the designer can generate a database (Model First) or map to an existing database (Database First). Whether you want the 'primary source of the model' to be your application or your database is a decision that is completely in your hands and EF supports both approaches. Code First is perhaps one of the newest and shiniest features but at the same time we implemented Code First we also worked on the DbContext API, which benefits both Code First developers and those using the designer. EF5 also includes improvements to the designer (in VS 2012).Anonymous
July 12, 2012
Dear EF team, I wanted to ask whether you could reply to my question on stackoverflow regarding the current status of and your future plans for Round-Trip Modelling with Model First? stackoverflow.com/.../entity-framework-net-round-trip-modelling-with-model-first Thank you very much and keep up the great work!Anonymous
July 16, 2012
@aronia – I just posted a reply to your Stack Overflow question.