Improved Transaction Support provides support for a transaction external to the framework as well as improved ways of creating a transaction within the Framework.

Enums, Spatial and Better Performance on .NET 4.0 – By moving the core components that used to be in the .NET Framework into the EF NuGet package we are now able to offer enum support, spatial data types and the performance improvements from EF5 on .NET 4.0.

Improved performance of Enumerable.Contains in LINQ queries.

Improved warm up time (view generation), especially for large models.

Pluggable Pluralization & Singularization Service.

Custom implementations of Equals or GetHashCode on entity classes are now supported.

DbSet.AddRange/RemoveRange provides an optimized way to add or remove multiple entities from a set.

DbChangeTracker.HasChanges provides an easy and efficient way to see if there are any pending changes to be saved to the database.

Custom Code First Conventions allow write your own conventions to help avoid repetitive configuration. We provide a simple API for lightweight conventions as well as some more complex building blocks to allow you to author more complicated conventions.

Configurable Migrations History Table allows you to customize the definition of the migrations history table. This is particularly useful for database providers that require the appropriate data types etc. to be specified for the Migrations History table to work correctly.

Multiple Contexts per Database removes the previous limitation of one Code First model per database when using Migrations or when Code First automatically created the database for you.

DbModelBuilder.HasDefaultSchema is a new Code First API that allows the default database schema for a Code First model to be configured in one place. Previously the Code First default schema was hard-coded to “dbo” and the only way to configure the schema to which a table belonged was via the ToTable API.

DbModelBuilder.Configurations.AddFromAssembly method allows you to easily add all configuration classes defined in an assembly when you are using configuration classes with the Code First Fluent API.

Default transaction isolation level is changed to READ_COMMITTED_SNAPSHOT for databases created using Code First, allowing for more scalability and fewer deadlocks.

Entity and complex types can now be nested inside classes.

Improving Startup Performance

The 6.0.1 Patch Release

The 6.0.0 version of the EF package needed to be locked down early to be included in Visual Studio, ASP.NET, etc. After this lock down a number of important issues came to our attention that we felt were important to fix ASAP.

To deal with this, we are also publishing an EF 6.0.1 patch on NuGet today. If you install from NuGet you will automatically get the latest patch version. If you use a VS2013 project template that already has EF6 installed, or if the EF6 tooling installs the NuGet package for you, we would recommend updating to the latest patch version. You can do this by running Update-Package EntityFramework in Package Manager Console.

The 6.0.1 patch release is limited to fixing issues that were introduced in the EF6 release (regressions in performance/behavior since EF5). The most notable changes are to fix some performance issues during warm-up for EF models – this was important to us as we significantly improved model warm-up time in other areas in EF6 and have been listing it as a feature. You can see a complete list of the individual fixes on our CodePlex site.

Improving Performance with Ngen

Prior to EF6, a large portion of Entity Framework was included in the .NET Framework. This meant that most of Entity Framework automatically has native image generation run on it to reduce the just-in-time (JIT) compilation cost.

Because EF6 ships as a completely out-of-band release, native image generation is no longer performed automatically. This can result in an increased warm-up time for your application while JIT compilation occurs – we have seen results of around 1 second.

@Felipe Fujiy – I'm a little unclear on the scenario you have. If you are generating code from an EDMX then you should swap to the EF6.x templates (DbContext is included with the EF6 tooling and ObjectContext is available on VS Gallery). However, using ToTable is only when using Code First. Could you elaborate a little?

@Felipe Fujiy – We made that change to allow additional calls to be chained after ToTable. I assume you are using reflection to call the API? Any code that calls the Fluent API directly should compile just fine with the change.

@Missing – We haven't published one at this stage. We decided to hold off and see if there was much demand for it – counting that as one vote so far :). It's not ideal, but if you have a machine with VS2012 on it, you can install the VS2012 tooling and then grab out the tt files – they should work ok on VS2010 (though I haven't tried it).

Is this provider split the only solution to get the VS working with Provider and using EF6? Will this split be the same for EF7? Jiří Činčura only wants to split the provider if this doesn't change again for EF7.

@Felipe Fujiy: To add to Rowan's comment, a DLL already compiled against EF 4.3.1 is not guaranteed to work with EF6. There are intentional breaking changes in the API of EF6 and although most code that targets DbContext and Code First should work just fine after recompiling it you may need to modify your code in some cases. See the link to "Updating Applications to use EF6" in the blog post for more details.

Has the tooling for generating views made the cut for the RTM as promised? Could you possibly add a blurb in this post to clarify how that works? Does it come with Visual Studio 2013 or is there a separate download needed (ie: EF Power Tools Beta 4)?

@Robert – You can do it pretty easily already using the techniques shown here msdn.microsoft.com/…/jj592907. We do have an item on our backlog to add support for function imports in Code First. But using the current bits, if you wrap the raw sql call to a sproc in a method on your derived context then it will look basically the same to your application code.

@Ken Smith – We weren't able to fix that issue in the 6/6.0.1 releases. It's currently scheduled to be fixed in the next set of releases – though that's not a 100% definite commitment that it will be fixed. For the moment you could manually reference the assemblies.

@koichia: There will be an update for ASP.NET Universal Providers that will have support for EF6. The .NET Web Development and Tools Blog (blogs.msdn.com/…/webdev) is a good place to check for updates on Universal Providers.

@Rowan: what I mean with SELECT Stored Procedures was to select a SP and the Designer should build the Entity from the result of that SP – all of our Data access goes through Stored Procedures for Select/Insert/Update/Delete and the SELECT result doesn't often map to tables because we return special columns from multiple tables…

@Rowan Cool. Can you make it so that it looks for DbContext or ObjectContext? The way it works now, if you're using DbContext, you have to handle the ContextCreating event and specify the context programmatically.

It seems that EF6 wants to update the structure of any DateTimeOffset fields. Taking a simple test project created with EF5 including a DateTimeOffset field, enabling migrations (not-automatic), then upgrading to EF6, the project won't run without a migration being added. The migration seems to just specify the precision:

@Robert – That makes sense. We don't have that feature as yet and it's not on our backlog. Currently you would need to have the model generated from the table and then configure it to use SPs. Feel free to create a feature request here – entityframework.codeplex.com/…/Create.

@Dydek – There are a couple of performance issues that we are working on fixes for at the moment. The most notable one is an issue that is only present when you have the debugger attached – entityframework.codeplex.com/…/1778. We're working on a plan to get this fix out ASAP as we realize this is very painful for folks developing their apps with EF6.

While I applaud your hard work at getting this release out, I must say that I was entirely disappointed to discover that the Async named methods were only available for .Net 4.5.

Why can't the methods like SaveChangesAsync simply return Task<int> and not use the async keyword?

I realize the benefits of the async await pattern, but one can also make use of the TPL without out. It was even backported to .net 3.5.

Due to the lack of XP support in .net 4.5 (the overwhelming majority of our healthcare industry customers use XP and will not be changing) , it is not likely we will be able to use it for the foreseeable future. Even so, we have made heavy use of the TPL in our .net 4.0 products. I certainly hope this is only an oversight or something that will be upcoming, as we had been waiting for awhile for this update, only to realize this much awaited functionality is not usable to anyone stuck at .net 4.

@CJL: Thanks for your feedback. We evaluated supporting async on .NET 4.0 but we found several blocking issues. As you can guess although it is possible to target .NET 4.0 with the C# 5.0 compiler there are subtle differences in the runtime behavior and .NET 4.0 is lacking some of the changes that were made to better support async, e.g. on exception handling. Even more important, EF6 depends on the new Task-based async methods that were added to the ADO.NET provider model (i.e. in the classes under the System.Data.Common namespace) in .NET 4.5.

Before .NET 4.5 only a subset of the async functionality existed in different providers like SqlClient but it wasn't exposed in the common provider model in a way that EF could consume them.

In case it helps clarifying, our highest priority was to enable async for server-side and cloud scenarios as opposed to the UI responsiveness scenarios that are more common in client/server applications. E.g. our implementation is mainly focused on freeing up threads to the thread pool whenever a database call happens on a Web application, so that they can be as quickly as possible assigned to service additional requests, and we will never spin up a new thread to do additional work in parallel. We also don't support concurrent access from multiple threads to our context objects.

I'm wondering if anyone aside from me has thought that a Clear() method should be added to DbContext for clearing the object cache? This would be useful for batch processing. I see the lack of such a method as a real deficiency. I have heard that EF 6 was supposed to make allocating new DbContexts faster. So, you could simply allocate a new DbContext and dereference the previous one every n number of rows that are processed to free up memory. However, it sounds like EF 6 is actually slower now. I haven't been able to test yet as I'm using MySQL on a project and I'm waiting for an updated driver that supports EF 6. I would really like to see EF start using prepared statements for updates as well. I was surprised to find that it isn't doing that already. I think that would be easier to implement that batching of statements personally which is something else that someone was looking into.

@Jon: We considered in the past having such ability to reset the object tracking state of a DbContext but as you pointed out it you don't get much benefit since it is possible to create a new context instance every time you want to start anew. In fact in EF6 once the model is built (in the case of Code First) or loaded, we cache more information about how the EF model maps to your classes to make subsequent instances of the DbContext cheaper to create. Our internal performance testing show that this is indeed much faster in EF6 than it was in EF5. Thanks for your feedback about using prepared statements. We have the following work item in our backlog for it: entityframework.codeplex.com/…/912.

@Andre.Ziegler – We aren't planning to produce such a template. I'd be interested to know what you are using the template for. If I understand correctly you can hook it up to a model created in the EF Designer and have it generate a Code First model. If that is the case, I understand it could be useful for a one-time conversion from EF Designer -> Code First. But if you are actually using the designer to maintain the model then I don't see what advantage it provides, if you were to just let EF load the model from EDMX it would actually be a little bit faster.

I simply want to have classes without any references or attributes to/from EF. I replaced the EFFileTemplateManager with this http://www.nuget.org/…/T4.TemplateFileManager. I have a project with the EDMX and the T4 templates. Now I only generate the POCOs in the same project file and all EF related stuff (context, mapping) goes to a 2nd project. So I avoid that the GUI has a reference to the used ORM tool. With the buildin EF6 templates I loose this advantage because all files are generated in the same project and here I must reference EF.

@Andre.Ziegler – You can achieve that with the default code generation templates. There are separate templates that generate the entities (<model_name>.tt) and the context (<model_name>.Context.tt). The easiest way to do this is switch off code generation in the EF project (by clearing the CustomTool property of the file), then adding the tt file as a linked item in the second project. This way the file still exists in the same directory as the EDMX file and you don't need to update the path to the EDMX in the template.

ok, I've used the workaround. You should document this somewhere. I never thought of inserting the file as link.

But I still use the custom T4 TemplateFileManager to move the generated context class into the other project and move the entities into a subfolder. I don't like having too many files into the root of the project.

I noticed 1 issue with the VS tools. When adding the template, the already installed EF 6.0.1 references where replaced again with 6.0.0. I've updated EF again to 6.0.1 but now I now get a message the EF6.0.0 is missing during runtime of my program. I'll try to debug this tomorrow. Does VS have any tools to show miss matched references?

I know that I can define the namespace, but this doesn't move the files.

I also run into an issue, that I get an UnintentionalCodeFirstException. I've commented this call out from the tt so that is not generated in the context.cs.

Next, the old fluent Generator also created overloads of the context, where I can use different Connections strings. This should be also added to yours.

But I can't use the whole Generator at all. The db tables have a different Name compared to the model. I changed this in the EDMX after I imported the model from the DB when I used EF4.1. Now all queries want to get data from tables which I don't have because there is no mapping. With the old Generator everything worked fine.

@Andre.Ziegler – Commenting out the UnintentionalCodeFirst exception isn't a good idea. That means EF is going to ignore your EDMX file and use Code First to build up a default model based on it's conventions – unlikely to align with what is actually in your database. You should make sure your EF connection string (the one in App/Web.config that includes pointers to the CSDL/MSL/SSDL that are generated from your EDMX) is in the App/Web.config of the startup application.

I think the connectionstring is fine (works fine with EF4/5). It is this:

"add any additional configuration using attributes or the DbModelBuilder API and then remove the code that throws this exception"

The attributes are missing, but when I add attributes I must reference the EF Dll again which I don't want. The only way to solve this is to get a proper EF6 Fluent API generator. Because you don't want to create one, I can't use EF6. EF4/5 are slow so I think we'll stop our EF testing branch and never use EF again 🙁 🙁

@Andre.Ziegler – If you are getting the exception then EF isn't finding your connection string with the EDMX based content in it (which is why it's trying to run Code First). Here is a great post to help you understand what is going on blog.oneunicorn.com/…/dont-use-code-first-by-mistake.

@PJK – We've got something that works internally but there are some updates required to Dynamic Data before the new EDSC will work with Dynamic Data. Given that almost every request we've had for EDSC is to enable Dynamic Data we're going to hold off until the Dynamic Data team gets a change to make the updates and test out our new EDSC. I'm sorry that I don't have a definite timeline on that – but it is near the top of their backlog.

I read this link several times, but it still doesn't explain my issue. The connection works fine. I use the context.Database.Connection.Open(); to check if the database is online. If the connectionstring is wrong this would fail.

Now I also get VS crashes. After adding the EF6 T4 template I can't view the EDMX any longer and I see this error: "the file references an xml namespace that is inconsistent with the Entity Framework schema"

When I click on the "modify" link the VS crashes, here is the Windbg output:

> "I use the context.Database.Connection.Open(); to check if the database is online. If the connectionstring is wrong this would fail."

Even if it's not picking up your connection string with the EDMX info in it this would still work because it's falling back to Code First and will just pick a database via convention. That's why we put the UnintentionalCodeFirstException there – so you don't accidentally run in Code First mode.

There probably isn't much else we can do over blog comments. If you are able to provide a project that reproduces the issue then feel free to open a CodePlex issue (with the project attached) and I can help you there – entityframework.codeplex.com/…/Create.

I tried to create a new demo project, but I can't even reverse engineer the model from the DB.

I get a error that a provider is missing in the app.config and the link written in the error message points to an EF6 page: go.microsoft.com/fwlink. But this is an EF5 demo, the designer disables the EF6 radio button, so I guess he knowns it is EF5 🙁

And reverse engineer directly to EF6 also fails with a provider error.

Firebird + EF seams to be nearly impossible to be used together :'( :'( :'( :'( :'(

@Andre.Ziegler – Can you open a new issue on our CodePlex site and attach the project that is giving you issues – entityframework.codeplex.com/…/Create. Our team isn't planning to build a Fluent Generator because the correct (and best performing) solution is to correctly load the mappings from the EDMX file.

it works now after I started again from scratch with the update. It was indeed a connection string issue. When I use the Fluent Generator the EDMX is no longer used at all. I only use it to design the model and generate the fluent API CF code. But with your templates the other connectonString is still needed and uses the EDMX file. But I never used EF this way. I only used with the fluent generator from my first test application until now.

Btw, will we get the PDB and source files for 6.1 to debug EF calls in our projects?

The new BeginTransaction method which takes an IsolationLevel is ignoring whatever is passed in and always uses the default for the provider.

Haven't been able to find any way of making a SELECT followed by a conditional INSERT transactional when using EF. Even using TransactionScope doesn't help since EF only initiates the transaction when SaveChanges is called.

@Tony Whalen – If you have some example code where the IsolationLevel is being ignored, please open up a new issue on our CodePlex site so that we can dig into it – entityframework.codeplex.com/…/Create.

I’d like to retract my previous comment. The IsolationLevel is working correctly in EF so I was just wrong about that.

The issue remains however which is trying to perform a SELECT before an INSERT and have those statements work correctly in a concurrent environment. What I mean by ‘correctly’ is that one SELECT should block the other until the first commits the INSERT.

I now realise that you can’t even do that in SQL Server itself using just IsolationLevels. In fact, the only way I’ve been able to achieve this in SQL Server is by applying the UPDLOCK table hint on the SELECT. Note that using the SERIALIZABLE IsolationLevel does also work but produces frequent deadlocks which is unacceptable.

Since there is no way of applying locking hints in EF, there is no way to resolve this issue using DbContext. i.e. the following code will never prevent concurrent users from inserting the same row:

I really like EF and all the features it provides but this is a real show-stopper in a multi-user environment. The only current way I know to resolve this is to use a stored procedure which uses UPDLOCK and then use context.Database.ExecuteSqlCommand. Now that EF6 wraps ExecuteSqlCommand in a transaction, this produces the desired effect.

@Tony Whalen – It would be messy, but you could look at using command interception to tweak the SQL that is sent to the database to apply the locking hint – msdn.microsoft.com/…/dn469464.

BTW another approach to the design that would be more 'optimistic' would be to introduce a unique constraint on the Code column and deal with the exception when it occurs. This would avoid all the locking etc. which is probably going to significantly slow things down and optimizes your application for the (presumably infrequent) scenario where there is a conflict. You could still do the initial check ahead of time, so you would only get the exception if someone happens to insert between the query and save.

@Rowan Miller – Thanks for the advice Rowan. I agree that Interception would be a bit messy but it's a useful technique to know about. I like your suggested design using a unique constraint and exception handling. I think I'll go with that one!