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:

image

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

image

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.

image

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:

image

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:

https://github.com/aspnet/EntityFramework/tree/futures

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.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!  

2 thoughts on “Some Observations While Playing With EF7 Alpha Bits: Current vs On-Hold APIs

  1. Microsoft really angered me by calling this EF7. It is not EF7 it is something else. I fully support all the design choices they’re making but they can’t call this project EF7 =/

Leave a Reply to Julie Lerman Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.