Tag Archives: EF7

OSX, ASPNetCore, EFCore and CoreCLI, oh my!

After moving some RC1 test projects from windows over to my MacBook, it was time to start from scratch in OS X to see what that experience was like. Installing all the right pieces. I’d been using Visual Studio Code already on windows for nodes programming, but doing that for an ASP.NET 5 project is a little harder since the debugging for that isn’t implemented yet. At the same time I’m still getting used to navigating my way around a Mac … keystrokes, bash commands etc.

But I did get a small sample worked out and even used PostgreSQL to do the job.

That (remember, RC1) little test is on github here: github.com/julielerman/ef7osxtest.

But RC2 is a different beast!

Addendum because so many have asked: I am using the nightly builds of RC2. It is not out yet!

DNX is transitioning to CoreCLI with new underlying APIs. And there was that name change. ASPNET 5 became ASP.NET Core and EF7 became EF Core. The package and namespaces have changed.

And in the meantime, EF7/EFCore is still going through changes with RC2. To me the most significant is the work the team has been doing to help with disconnected graphs. You can read the latest (and I think final) state of how EF will handle disconnected graphs here on github.

I tried a few paths to starting a new project to try out RC2. Here’s some twitter evidence:

I had watched the video of David Fowler & Damien Edward’s talk about Core CLI from NDC London and David did the demos on a mac.

But it took a tweet from Tony Sneed to remind me that I could get David’s demos from github:

Indeed, that was the best starting point. I cloned that repository onto my MacBook and made sure I could run all three projects.

Now I’m working on building out the HelloMVC project by adding in the model, dbcontext, controllers and other relevant bits from my RC1.

At the moment (as of Feb 1 2016), the dotnet ef migrations commands aren’t working but Brice Lambson is working hard on it and says that should be pushed up this week. (Watch this github issue.)

And it might be a while before the Postgres provider gets updated to work with the new namespaces and package dependencies  but we do have the Microsoft.EntityFrameworkCore.Sqlite provider that will work on OS X although there seem to be a lot of problems at the moment with that on Linux. But I’ll be trying that out anyway.

EF7 is now EF Core 1.0, Package and namespaces change too

The big news last week was that the ASP.NET 5 & EF7 stacks were renamed in an attempt to alleviate the confusion around the naming of everything under the ASP.NET 5 umbrella.

ASP.NET 5 is now ASP.NET Core 1.0

EF7 is now EF Core 1.0

The naming has been a topic of debate since each of these were introduced by Microsoft and throughout their development. The teams finally accepted that the myriad questions and complicated answers about the naming in the ASP.NET 5 stack was enough of a red flag to change the names. While it is a huge relief to many, the timing is problem for people who have invested in asp.net 5 already because the name is not just a brand but it will affect packages as well. As per the announcement on github

  1. The Microsoft.AspNet.* packages and namespaces are changing to Microsoft.AspNetCore.*.
  2. The EntityFramework.* packages and namespaces are changing to Microsoft.EntityFrameworkCore.*.
  3. The version numbers of all of the above are being reset to 1.0.0-*.

Changing the namespaces this late in the game is going to be painful for devs/companies who have already been building apps and tooling on ASP.NET 5 &/or EF7. We are already on RC1 which was released in November with a go live license. Rick Strahl has a great [balanced] post talking about this.

Other than this, both ASP.NET Core & EF Core will move forward as planned. RC2 is supposed to be out sometime in February and they remain committed to the initial RTM at the end of March.

Here are the new namespace names for EF Core for RC2, as per https://github.com/aspnet/EntityFramework/tree/dev/src

In EF7 In EF Core
EntityFramework.Core Microsoft.EntityFrameworkCore
EntityFramework.Commands Microsoft.EntityFrameworkCore.Commands
EntityFramework.MicrosoftSqlServer Microsoft.EntityFrameworkCore.SqlServer
EntityFramework.MicrosoftSqlServer.Design Microsoft.EntityFrameworkCore.SqlServer.Design
EntityFramework.Relational Microsoft.EntityFrameworkCore.Relational
EntityFramework.Relational.Design Microsoft.EntityFrameworkCore.Relational.Design
EntityFramework.InMemory Microsoft.EntityFrameworkCore.InMemory
EntityFramework.Sqlite Microsoft.EntityFrameworkCore.Sqlite
EntityFramework.Sqlite.Design Microsoft.EntityFrameworkCore.Sqlite.Design

If you are curious about what’s in EF Core, check out my EF7 Course on Pluralsight which I created during the Beta 4 …then read my recent post, EF7 Updates and Changes on Pluralsight’s blog which takes you from there to the current RC1.

EF7 RC1 Notes–An Update to my Pluralsight “Planning Ahead for Entity Framework 7” course

In early 2015, I published a course titled “Looking Ahead to Entity Framework 7”. This was created using an early version of the work that the EF team was doing on the total refresh of Entity Framework.

That version was referred to as Beta 4 although was still so malleable that the EF team even referred to it as an alpha. In fact, the only reason it had the tag “beta 4” was to align with the set of Nuget packages that were being released for ASP.NET 5 as it was developing. An important goal with EF7 was that it needs to work with ASP.NET 5, so the EF team needed to release their stable pre-releases on Nuget.org (e.g. http://www.nuget.org/packages/EntityFramework.Core/) in sync with ASP.NET 5. The nightly builds, which are available on https://www.myget.org/gallery/aspnetvnext are a different story and are pushed frequently by the EF team whenever they are ready to do so.

Since the course was released some technical things have changed and even the release plans have changed. Rather than updating the course each time, potentially introducing more things that will change by RTM, I will wait until EF7 is closer to RTM and use that to create a course about the release.

In the meantime, I think it is important to have some awareness of the current landscape so that combined with watching Looking Ahead to Entity Framework 7, you can plan ahead effectively. My recommendation is to at least peruse this blog post before watching the course and then come back and read it more carefully when it will make more sense.

In this post I will address each of the 6 modules of the beta 4 course and alert you to what has changed and what to expect.

Module 1: Achieving Microsoft’s Goals for EF with EF7

The overarching goals for EF7 have not changed. Microsoft is wholly committed to a completely new code base for EF7 using modern software practices. The New Devices New Data Stores goal is still correct and as you learned (or will learn when you watch the course), the proof of concept work around NoSQL and Redis is still set aside.

While discussing where you can use EF7, I showed a slide that talked about various frameworks.


This shifts a bit since the initial RTM of EF7 will now support UWP (Universal Windows Platform) which targets Windows 10 devices including phones and tablets. Along with this change, the SQLite provider that had been set aside, is now part of the initial RTM. In the course, I explained that the Windows Phone 8 & Windows Store support is also set aside for a later release after the initial RTM. That is still true.

Here is an updated version of that slide I created for a recent conference:


Another change to the first module is related to the timeline. I explained how EF7 was going to focus on being able to release alongside of ASP.NET5 which meant setting aside of of the goals that they wanted to achieve. I also explained that when ASP.NET 5 was released, we would get a release of EF7 that would be still called a pre-release, not an RTM. Here is the slide I used while discussing this timeline.


These plans have changed somewhat. While the initial ASP.NET focused release of EF7 is still going to be a subset of all that the team wants to implement in EF7, it is now going to be a full release, an RTM, not a pre-release. So at the same time ASP.NET 5 is released, EF 7.0.0 will be released.

Here is what has not changed however:

· EF 7.0.0 will still be an “abbreviated” version.

· The features that the team is focusing on are those which align well with web applications. A good example of this is that they are working on improving the experience with disconnected entities and have set aside some magical relationship features such as explicit and lazy loading.

· EF 7.0.0 will not become the “official” version of Entity Framework.

· EF6 will continue to be the official version.

· EF6 will continue to be what’s delivered when you install entityframework via Nuget.

· Your apps that use EF6 will not automatically update to EF7!

· When installing the packages via Nuget, you will not need to use “-pre” to distinguish between EF6 and EF7.
EF6 will continue to install using install-package entityframework. There is no plain old entityframework package for EF7. You would begin with your desired provider (e.g. entityframework.inmemory) and that will pull in all dependences e.g. entityframework.core and more. Since this is a full RTM for EF7, you will no longer need to use the –pre.

Also, we now have a pretty well-delineated roadmap from the EF team on their github wiki. Most importantly is that the RC1 (Release Candidate with Go-Live) version of EF7 (as well as ASP.NET5) was released in November 2015. According to the ASP.NET 5 roadmap, there will be an RC2 in February with the RTM targeted to the first quarter of 2016. There will be a big change Another notable point on the ASP.NET 5 website is the lack of Visual Basic support until possible Q3 of 2016.

According to the roadmap, EF7 will become the official version at some point in the future when the team feels that they have a critical mass of important ORM features implemented.

Here is an updated version of the above timeline slide which I used in my recent conference talk:


Module 2: Targeting EF7 Initial and Future Releases

The list of things collected in what will be in the initial release has not changed significantly except that now, as mentioned above, EF7 will also support the UWP apps.

Re VS *& .NET versions. While ASP.NET 5 can run on the DNX environment, it can also be run on a full .NET Framework environment. In the course, it says this will be possible with 4.5 and beyond. Now it will be for .NET 4.5.1 and beyond. I don’t believe that the future releases will revert back to supporting 4.5 at all.

Installing: As mentioned above, the latest stable release is available on Nuget.org. (Today that is RC1). The nightly builds are available via the myget package source (https://www.myget.org/gallery/aspnetvnext). The team is currently working on RC1 in the nightly builds. Sometime this month (November 2015) a stable version of RC1 will become available on Nuget.org and that will be what you get with the “-pre” tag.

In Beta4 there was still an EF7 package named EntityFramework. That no longer exists, enabling us to use that package name to specifically target EF6. For EF7, it’s easiest to begin with the provider that you want and then this will pull down all of the relevant dependencies. So for example
install-package entityframework.sqlite” will pull down that package, the relational package (which includes migration support), the core package and others.

Don’t forget that the migrations commands are in a separate package: EntityFramework.Commands, which you need to explicitly install if you want to perform migrations in nuget or the DNX environment.

This is important: the “K Runtime” is now the “DNX runtime”.

All of the commands that you run start with dnx now, not k.

For example:

dnx ef migrations add

Playing with the proof of concept features The support for the stripped down framework used for Windows Phone 8 and Window Store apps was set aside and is still in that state. Those DLLs are not handily available. The tricks I used in the course to access those assemblies may or may not work still. I haven’t tested. Remember though that the SQLite assembly is now part of EF7 so that’s easy to get! And if you can target Windows 10 phone & tablet apps with EF7.

Module 3: Querying and Updating with EF7 (Disconnected Graphs change!)

Most of the changes from that evolved since I created this course with beta4 are around syntax. Even in the course you could see that at first the team was renaming methods to better suit how they wish they had been named. For example, rather than have DbSet.Add and DbSet.AddRange, they modified add to just take an overload that accepted a range. But just before I pushed the course live, they changed the methods back to Add taking a single object and AddRange specifically for a range. The reason for this is to lessen the blow of changes to the API. This could be something that would be backwards compatible with EF6. There have been a number of changes like this as EF7 has evolved where some of the syntax was reverted to better align with EF6. Even behavior has shifted. Add is another example. EF6 and earlier had a pattern of [almost] always affecting full graphs when you pushed a root of a graph into the context with Add/attach/Delete or using the Entry().State property. And the effect were inconsistent. They experimented with completely separating behavior by making Add (etc) and Entry.State ONLY affect the root and then giving us a new method ChangeTracker.AddGraph soley for working with graphs. Since beta4, the team has narrowed in on a pattern that will be the final say on this matter. Here it is:

DbSet.Add, AddRange, Attach, AttachRange, Update, UpdateRange: These methods now take a new 2nd parameter which is an enum,GraphBehavior.

GraphBehavior values are IncludeDependents and SingleObject.

The default for the above methods is GraphBehavior.IncludeDependents which means that a just using it in a familiar way, e.g.:


will result in *almost* familiar behavior. THe catch (which is a good improvement, in my opinion)is that the default behavior, IncludeDependents, is literally for dependent objects. it is not going to include All Related Objects. The distinction is important. Objects in a relationship are either principal (aka “parent”, or dependent (aka “child”). In the database these are easily distinguishable because the dependent is the one that has the foreign key back to the principal.

Consider the following Principal to Dependent relationships:

Order –> Line Items



It makes sense to create a new order, add some new line items to it and then add that order graph by calling context.Orders.Add(order). In this case, all of the dependent line items will be included in the operation, i.e. marked as Added as well.

It makes sense to add an address record to a person and then add that person to the context. context.People.Add(person). Again, the dependent address  would be marked as added. The category with it’s dependent products also is logical.

If for some reason you created a new line Address instance then identified it’s Person by setting someAddress.Person=somePerson, and then added that address via context.Addresses.Add(someAddress), EF7 will not mark the parent/principal object (somePerson) as Added. Adding a new address does not necessarily mean you are adding the new person so EF won’t make that presumption. I also am a fan of building my model with aggregate roots that are in charge of the behavior of their related data. So I wouldn’t allow my tyeps to be used in such a way that the user of my API could create an address and randomly add it anyway. So this behavior aligns with coding patterns that I recommend.

It also solves another problem I see a lot where devs use object instances to specify reference properties. I always recommend using foreign key properties for this but I know that so many programmers have the following problem.

Imagine this scenario:

The form for building or editing the order has a place to enter the a new  shipping address for a customer. One of those fields is a dropdown for “region” (in my case, in the U.S. that would be a state like Vermont or Utah). I query for a list of region objects and populate a dropdown list.


I select Vermont and then my code does something like this: theOrder.theAddress.Region=(region)List.SelectedItem. I add the order with context.Orders.Add(theOrder) and call SaveChanges.

The next person who goes to add an address sees this:


Two Vermonts! That’s because in EF6 (and earlier) everything in the graph is marked added and the EF inserts the Vermont object into the database even though it was already there.

In this case, the model sees REGION as the principal and ADDRESS as the dependent because ADDRESS has a foreign key back to REGION. EF7 will not include the principal. Only the address will get inserted and the crops are saved!

Add, Attach & Update: Root Only

So, the default for Add, AddRange, Update, UpdateRange, Attach and AttachRange is to include dependents. Using the parameter, you can specify the SingleObject enum and then only the root entity of the graph will be affected by the method.


In RC1 this is the same as I explained in the course: if you specify an entity that is in a graph, only that entity will be affected by setting the state. Any other objects that are part of the graph will be untouched.

ChangeTracker.AddGraph has changed to ChangeTracker.TrackGraph

The signature is the same, you pass in the graph and a lambda function. The lambda can express the state that you want the graph to use.

context.ChangeTracker.TrackGraph(someEntityWithRelatedObjectsAttached,          e => e.Entry.State = EntityState.Added);

EF will walk the graph and apply that function to everything it discovers in the graph, skipping objects that are already being tracked (and their related objects).    A cool feature of this method (same as when it was called AddGraph) is that that function does not have to express state. It can be any function you want.

The DbSet.Find method
This was set aside for post-RTM, but the team is reconsidering and may get it in for RTM. More here: https://github.com/aspnet/EntityFramework/issues/797

Module 4: Using and Migrating Relational Databases

In this module I talked about some differences between how migrations worked relative to how we are used to them working in EF 4.3 to EF6. I also showed how migrations work in the k runtime commands if you are using ASP.NET 5 and not able to use the familiar PowerShell commands. I also explained that the magic behavior of the DbInitializers as well as automatic migrations will not be part of EF7.

Not a lot has changed since the beta4 release that the course is based on. The team has streamlined the commands a bit more. They had introduced a new “apply-migration” command to replace update-database, but apply-migration is gone and you will just use the familiar update-database command.

On the ASP.NET side, the commands are now dnx commands, not k commands. So the current way to express adding a migration, therefore is:

dnx ef migrations add myAwesomeMigration

Not much else has changed from what is explained in Module 4.

There’s a nice chart in the July 23rd EF design meeting notes that shows the changes.

Not really migrating, but the commands now support reverse engineering with a scaffold command that has a bunch of helpful parameters to customize how the code is generated.

Module 5: EF7 Futures

This module covers things that the team was exploring but set aside to focus on the ASP.NET 5 aligned release. Those were non-relational stores (with Redis and Azure Table Storage as their proof of concept) and allowing EF to run on the trimmed down version of .NET that is used for Windows 8 phone and tablet (aka “windows store”) apps which also relied on the new SQLite provider. Since the assemblies were still accessible, I showed a demo of a Windows Phone and Windows Store app that used SQLite as well as one that used Azure Table Storage.

The Azure Table Storage and Redis providers are still set aside, as I explained in this module.

And while it is still true that EF7 will not initially support this Windows 8 Phone and Store apps when it is released, the team did bring SQLite back into the fold for EF 7.0.0. The reason that SQLite was re-ignited is because, as I mentioned above, EF7 is now able to run on UWP (Universal Windows Platform) the Windows 10 platform that lets us create cross-device apps that will also run on phones and tablets. Those will benefit from using SQLite. In fact, I was able to rebuild the Cookie App from this module in UWP with EF7 and SQLite and watch it run on emulators for phones and tablets.

Module 6: Interacting with the Team

This module is about how EF7 is being developed openly on GitHub at github.com/aspnet/entityframework and the story has not changed. The team continues to be eager to have developers try out EF7 and provide feedback in the form of issues or even Pull Requests. They continue to publish their team meeting notes on the wiki where we can converse with them further about their ideas.

The EF7 RoadMap

The roadmap did not exist when I created the course. It is a great resource and I encourage you to check it out at https://github.com/aspnet/EntityFramework/wiki/Roadmap.

I continue to bang on EF7 and pester the team when I’m confused. When EF 7.0.0 releases, I will create a Getting Started course that will dig further into EF7 as a full released framework.

A Few Notes About Mappings

Since the course there were a few things I learned that either didn’t exist at the time or I just didn’t know about that I think are worth mentioning.

The pluralization support we’ve been used to in the past does not exist in EF7. If you have a model with an entity named Person and another name Order, EF (& migrations) will presume that the relevant tables are also named Person and Order.

The next point will help you address the pluralization.

Custom Conventions that we got in EF6 are not in RC1 and won’t be in the first itereation of EF 7. They are targeted towards a future release — and should be in EF7 by the time it becomes the “official” version of EF.

So a custom convention such as this is not yet possible:

(EF6->) modelBuilder.Properties<String>().Configure(p => p.HasMaxLength(50))

However, Rowan Miller points out in his gist (https://gist.github.com/rowanmiller/88261afd0baae7fb9b04) that we can continue to use a hack that we had before custom conventions existed to help (but not magically solve) with table name pluralization. And thanks to the new Name property introduced in C#6 (& VB but remember, we don’t have VB support yet) you could iterate through the entities and apply someo rules. This gist of Rowan’s shows a simplistic “add s” rule:

foreach (var entity in modelBuilder.Model.GetEntityTypes())


modelBuilder.Entity(entity.Name).ToTable(entity.Name + “s”);


Support for Table per Hierarchy (TPH) mappings was added as of RC1.

EF7 can now infer 1:1 mappings without you having to specify the principal and dependent. If it doesn’t get it right then you can use updated HasMany/HasOne fluent mappings. (These have been simplified!)

Recent Data Points Columns: Aurelia, Azure DocumentDB, Scriptcs, EF6, EF7, ASP.NET 5

Data Points – Aurelia Meets DocumentDB:
A Matchmaker’s Journey
(Part 1)

*Part 2 will be in Dec 2015 issue

Nov 2015

After exploring both DocumentDB and the new Aurelia framework, Julie Lerman decided it was time to use them together, but that proved more difficult than expected. Learn how she finally found the path to the correct solution.

Read article

Data Points – Revisiting JavaScript Data Binding — Now with Aurelia

Sep 2015

Julie Lerman has long been a fan of the Knockout JavaScript framework and its data binding talents. Here she explores the new Aurelia framework, which is quickly gaining momentum with Web developers, and finds that it offers a lot to like for data-oriented programmers.

Read article

Explore Entity Framework Behavior at the Command Line with Scriptcs

Jul 2015

Julie Lerman learns how to explore Entity Framework behavior interactively using Scriptcs.

Read article

An Overview of Microsoft Azure DocumentDB

Jun 2015

Julie Lerman takes a first look at the Microsoft entry into the document database field—Azure DocumentDB.

Read article

The EF6, EF7 and
ASP.NET 5 Soup

May 2015

Julie Lerman discusses the difference between the next version of .NET and what ASP.NET 5 apps will run on, then explains how Entity Framework 6 and Entity Framework 7 fit into the mix.

Read article

EF6 Code First Migrations for Multiple Models

Apr 2015

The new support for Code First Migrations in Entity Framework 6 makes it easier to store data for multiple models in a single database. But that support may not be what you imagine. Julie Lerman explains what this feature does and doesn’t do, and how to use it.

Read article

Looking Ahead to
Entity Framework 7

Jan 2015

In this first look at EF7, Julie Lerman discusses what EF7 will bring to developers, the motivations behind decisions being made about the framework, and what this version means to existing apps that use EF6 or earlier.

Read article

EF7 EnsureCreated vs. Migrate Methods

I had a “demo gods” problem recently…of course I hit the jackpot combo during a conference presentation though never while practicing.

Remember that EF7 is not EF6 with new features. So behavior can change and I didn’t check this one.

In EF6 if you have migrations and either let DbInitialization create the database or use Database.Create(), the database will get created along with the migrations in the MigrationHistory table.

With EF7 if you use EnsureCreated to create the database at runtime, as I had in some of my tests where I literally wanted to check behavior in the database, the migration history table DOES NOT GET CREATED.

This messed me up because I was demoing a migrations feature after having run one of these tests. With the migration history table wiped out by my test, the update-database command attempted to start with the very first migration, not the one I had just added in my demo. This caused a conflict because that migration was attempting to create a table that already existed in the database.

I couldn’t figure out what the problem was on the fly, so I moved on, with assurances to the attendees that I’d done a lot of work with migrations and new they worked as expected. And that a) it was a beta b) I would run it by the team and c) “you can trust me”.

So, blaming it on “beta” was not fair and it was not right. The blame lay between the chair and the keyboard, as they say. I hadn’t even run that test in my conference session yet.  But I had re-run all fo the tests one last time right before I started the session, which put the database in this bad state.

Here, from one of EF7 issues raised on Github is Rowan Miller’s explanation:

EnsureCreated totally bypasses migrations and just creates the schema for you, you can’t mix this with migrations. EnsureCreated is designed for testing or rapid prototyping where you are ok with dropping and re-creating the database each time. If you are using migrations and want to have them automatically applied on app start, then you can use context.Database.Migrate() instead.

So I’ve gone back to my tests and made sure the ones that use the database make use of the Migrate command.

My anticipated uses:

  • EnsureCreated for on the fly DB creation on devices (e.g. phones)
  • EnsureCreated for integration testing when I’m pointing to a unique testing-only database.
  • Migrate for integration testing when my tests involve a test database that uses migrations. I think this will be rare and this is what I wanted for my conference demo.
  • Migrate for, as Rowan suggests, Migrating a db on app startup. This could be for example, client apps (ala WPF) or web sites you’ve deployed to Azure.

Keep in mind that these demos where Migrate made more sense, are demos I am using to help people understand how EF7 works, not to demonstrate how to build tests when employing Entity Framework in your application. So some of the things I am doing are not necessarily how I would use tests when building software.

Getting Started with EF6 Course on Pluralsight


You may think you read that title wrong. Does she mean EF7? No, I actually invested some time into creating a new Getting Started with EF6 course even though EF6 was released about 18 months ago. When EF6 was released, most of what changed since EF5 was the advanced features and usage. I did a course called “EF6 Ninja Edition: What’s New in Entity Framework 6” specifically to cover those additions/improvements. But for the “toes in the water” first look at EF, not much had changed between EF5 and EF6 so the Getting Started with EF5 course remained pretty relevant.

Watch Getting Started with Entity Framework 6

So why Getting Started with EF6 now, when EF7 seems to be around the corner? Well, EF7 is still going to be a while. Even though a “Beta 6” was announced recently, the team has said in a significant way that EF7 Beta 6 is still “very much a preview” of EF7. A pre-release of EF7 is expected in early 2016 along with the release of ASPNET5. But the RTM of EF7 is still further off than that date. And even then, not everyone will be using EF7 right away.

So EF6 will be around for a long time and I decided that it was useful to have a course that addressed Getting Started with EF6 directly including using the latest version of Visual Studio – VS2015.

The first module is an overview which is designed for not just developers but even your managers who may want to have a better understanding of what EF is and how it fits into your overall plans.

I am also committed to creating two more EF6 courses for Pluralsight — also for the sake of being long-term resources. These will consolidate information in the various courses I’ve created about EF3.5 – 6 over the years. One will be an EF6 Fundamentals and the other will be Advanced EF6.

In the meantime, I’ll be updating the “Looking Ahead to EF7” course to reflect the Beta 6 since things have evolved since Beta 3 when I did that course.

EF7 Beta 4 & LINQ Queries: Be sure you have the right LINQ package

For EF7 Beta 4 (via nuget) the package you want is Remotion.Linq 2.0.0-alpha-002.

I recently updated some demos from using the EF7 stable (stable comes from Nuget.org, not the nightly build package source) version beta3 to beta4. It involved updating a lot of other packages and I know enough to be dangerous so this took me a while.

But I got it worked out and everything compiled and everything ran correctly …or so I thought.

There was a test I missed running which performed some LINQ queries.

I tried to demo that at in a conference session earlier this week at Techorama and it threw an exception. Rather than struggling with it, I assured the attendees that I knew this worked and was probably a versioning issue. I finally got a chance to dig into that today and have solved the problem.

It was indeed a version issue. I found a GitHub issue that indicated this problem was caused by having the wrong version of Remotion.Linq installed. But the conversation was based on an earlier build of EF7 and wasn’t sure which version of Remotion.Linq.

But in fixing the problem, I targeted the wrong version for an update, thinking the “stable” build might be what I wanted since the EF7 betas in nuget are considered “stable” betas. Unfortunately trying to install that stable version (1.15.15) caused nuget to hang for so long I had to just crash visual studio. I tried this repeatedly from different angles so I wasted over an hour being a dummy.

When I finally decided to try the 2.0.0-alpha-002 installed, it updated quickly and easily and my LINQ queries executed successfully.

Some EF7 Beta3 to Beta4 API Syntax Changes

I am updating some demos I created earlier in the year and using the Beta4 version of EF7 that is the latest stable beta and available on Nuget as opposed to the super-bleeding edge APIs you can get via the nightly builds source.

There were some API changes to features I was using and I had to do a bit of exploring to sort them out so wanted to share in case you are doing the same.

Keep in mind that there are a LOT of things that have evolved between these two versions. I’m just focusing on the things I had to change so that my little demos continued to work properly. Smile


DbContext.ChangeTracker.AttachGraph is now DbContext.ChangeTracker.TrackGraph.

Here’s an example of it in use with a graph of all new objects and the root of the graph is newSamurai.


e => e.State=EntityState.Added);


DbContextOptions is now DbContextOptionsBuilder.

You’ve most likely seen this used as a parameter in the OnConfiguring override for DbContext.

Here is the original signature:

protected override void OnConfiguring(DbContextOptions options) {}

Here is the new signature:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { }

DbContext/DbSet.Add Overload for Ranges

EF6 has DbSet.AddRange. Originally EF7 switched the functionality to be an overload of Add which was cool but not backwards compatible so we’re back to DbContext.AddRange and DbSet.AddRange.

DbContext.Entry.SetState( )

The DbContext ChangeTracker API since EF4.1 let us set state with

DbContext.Entry.State= EntityState (where EntityState is an enum)

EF7 started out with a nicer API for this which was


But for the sake of backwards compatibility, it’s now back to



That’s what I’ve encountered so far. Hope it helps

Looking Ahead to Entity Framework 7 on Pluralsight

Pluralsight has published my latest course, a 2.5 hour course about Entity Framework 7 (EF7).

“Looking Ahead to Entity Framework 7”

EF7 is not released yet. It will get released as a “pre-release” along with ASP.NET 5 so that there is a data stack available for projects that target the CoreCLR. Then the team will do a lot more work on EF7 for a full release possibly (wild guess) at the end of 2015. There are a lot of changes since EF7 is begin rewritten from the ground up. Many new features – from things like Batch Updates that we’ve been asking for since v1 to totally new concepts like being able to query and update against non-relational data stores. But there will also be things that do not get carried forward – most notably for some is the EDMX, the designer based entity model.

This course will show you what’s coming, what’s going, demonstrate a lot of the new features (as they are currently …aka the Alpha or earlier versions) and provide guidance about deciding if and when to move to EF7.

Here is an list of the modules:

You can see the more detailed Table of Contents here.

I’ve already gotten some great feedback on the course. My favorite tweet so far was:

“Great info and insight. I don’t know if I’m happier with what’s being added or being removed.”

Check it out and let me know what you think of EF7!

Some Observations While Playing With EF7 Alpha Bits: Current vs On-Hold APIs

You may or may not have caught this important blog post from the EF team about plans for the first RTM of EF7:  EF7 – Priorities, Focus, and Initial Release. In it, EF Program Manager, Rowan Miller explains that for its initial release, EF7 will target ASP.NET 5, ensuring that ASP.NET 5 has a solid data platform to release with. It also means setting aside some of the proof of concept work that the team has been working on for it’s “new platforms, new data stores” initiative. Namely, Windows Store &  Windows Phone and the non-relational providers that the team has been experimenting with are on hold until after the initial RTM of EF7. This does *not* mean that they are being dropped, just delayed so that the team can focus on shipping something usable sooner. Rowan is also clear about the fact that EF7 will not be considered the “go-to” EF version until much later when they’ve brought these other features in as well as forged ahead with more parity with EF6. I recommend that you read that post.

So what does that mean with respect to the source code for EF7 on Github and the current preview Nuget packages of EF?

Note that I have a package source that is pointed to the ASPNET vNext packages which is also where EF7 lives on myget: https://www.myget.org/F/aspnetvnext/api/v2

Also that I have selected PRERELEASE packages:


And using the console, that means always adding the “-pre” parameter after the install-package command (e.g. install-package entityframework –pre).

First, here’s a look at what DLLs were on Nuget prior to the shift


The shift occurred when the nuget packages went from being tagged as alpha to being tagged as RC. Note that these nuget tags do not reflect the state of EF7, but a package naming decision.


Notice that the AzureTableStorage, Redis and SQLite packages are still there but they are from Dec 1, 2014.

Notice the addition of EntityFramework.Core. That’s where all of the core bits are now.  But the entityframework package is still there. You still start by installing entityframework.

The entityframework package has a dependency on entityframework commands and will pull that in and then that forces nuget to also pull in entityframework.core, relational and migrations. You’ll need to explicitly install entityframework.SqlServer or InMemory if you want them. You’ll need at least one of those.

When you install EF7 from the ASPNetVNext package source, when the installation is finished the following HTML page will pop up in Visual Studio:


I have not tried to use the older providers. They are not going to be kept in sync with the moving forward packages. They will get caught up after EF7 has its initial release.

Also, you do have the ability to get at the source code as it was prior to this big shift. Check the “futures” branch on github:


I believe this is a snapshot that was taken prior to the shift.

Unfortunately, it’s not possible to keep all previous versions of packages on MyGet the way it is on Nuget.  You can get a snapshot of the beta2.11514 packages that Rowan Miller set aside for his Connect demos. https://github.com/rowanmiller/Demo-EF7/  That’s not the latest version of EF7 prior to the shift but close.

Just remember, it is all still early early, evolving and changing rapidly.