All posts by Julie

Troubleshooting the dotnet ef command for EF Core Migrations

Updated March 7, 2017 after Visual Studio 2017 was released.
Also, keep in mind that I have been updating this post (and will continue to do so) as I discover new ways people are hitting problems with dotnet ef.

When using EF Core in a .NET Core app (ASP.NET Core or other app sitting on .NET core), it’s easy to run into a problem when attempting to use EF Core migrations at the command line. The most common one is

No executable found matching command "dotnet-ef"

A Note If Your Coming from My Pluralsight EF Core Course

Microsoft supports developing .NET Core apps in VS2017. The tooling for VS2015 is outdated and there are no plans to bring them up-to-date for the new csproj support. I recorded my Entity Framework Core: Getting Started  course on Pluralsight while VS2017 was still in beta. While I did recreate the VS2017 demos in RC3 right before we published the course, we chose to leave the  rest of  the .NET Core demos that are in VS2015 alone.  VS2015 only supports project.json and the project templates set you up for .NET Core 1.0, not .NET Core 1.1. So in the course means that we’re stuck with project.json support and tooling that’s not quite aligned. But Pluralsight and I both agreed that it made sense not to ALSO force users to the bleeding edge, not even released VS2017 for the demos. The course’s focus is on EF Core, so as long as I could hand-hold users through the project.json setup stuff without the need to make them expert at that, it was the right way to go.

Of the nearly 2000 who have already watched the course since it’s release less than 2 weeks ago,  a few people ran into some confusion with the versioning and getting the “no executable found” message. I worked through these with them but wanted to write down the suggestions I’d made and have a single blog post I could point to.

Problems You May Encounter with ‘dotnet ef’

While some of these notes are specific to the project.json use in the course, I’ve also added tips for using dotnet ef with the newer csproj/msbuild support.

There are a few key things to watch out for.

  1. The current stable tooling for EF Core migrations is split into two packages.
         Microsoft.EntityFrameworkCore.Tools is for PowerShell
        Microsoft.EntityFrameworkCore.Tools.DotNet is for the CLI (dotnet commands)
    Be sure you’ve referenced the Tools.DotNet version of the package so that you have access to the CLI commands. If you’re following my course, that’s explained.
  2. dotnet ef only works in .NET Core projects. If your project targets the full .NET framework, then you’ll need to use the PowerShell commands e.g. add-migration, update-database.
  3. Make sure that you are running the command from the folder that contains the project where the Tools package is referenced. This is explained in the course demos, but still a step you may overlook in your excitement!
  4. If you are using project.json*, make sure that you have the Tools.DotNet package in the Tools section, not the dependencies section. After March 7 release, this will just be “1.0.0”.
    *Going forward, you should only be using project.json with .NET Core 1.0 projects. If you are using the current .NET Core (1.1+) you should be using csproj/msbuild.

    "tools": {
       "Microsoft.EntityFrameworkCore.Tools.DotNet": "1.0.0"
     }
    
  5. If you’re using csproj/msbuild, make sure the tools package is listed in the DotNetCliToolsReference tag.  After March 7 release, this will just be version “1.0.0”.

    <DotNetCliToolReference   
        Include="Microsoft.EntityFrameworkCore.Tools.DotNet"
        Version=”1.0.0” />
  6. If you’re using csproj/msbuild, make sure the casing is correct if you’re manually adding that package in csproj! I’ve seen people get tripped up by typing Dotnet rather than DotNet.
  7. It’s possible that you have to Tools correctly placed but your IDE did not trigger a dotnet restore. So you may need to do that manually. Here’s an example where that bit someone. https://github.com/aspnet/EntityFramework/issues/7801
  8. You shouldn’t be using an RC of VS2017 at this point but I’m leaving this one here.
    If you are using an older Release Candidate of Visual Studio 2017 (before RC3) , the CLI tooling was not yet aligned with the msbuild support so with that version, you have to use the PowerShell commands to do migrations. Therefore you have to use the Tools package and work in the package manager console, not the command line.

    <DotNetCliToolReference   
        Include="Microsoft.EntityFrameworkCore.Tools"
        Version="1.1.0-preview4" />

    As of  VS2017 RC3 (which is what I show in the last module of the course) it was possible to use msbuild3 as shown in point #4 above and the CLI commands. After March 7 release, this will just be “1.0.0”.

  9. Be sure you’re targeting a relational database. Migrations only work with those and not, for example, InMemory. A twitter friend accidentally ran into this problem and was getting the “no executable found” error message.
  10. Make sure that the version of the EF Core tools you are using aligns with the version of .NET Core on your machine.

In my EF Core course, I’m using EF Core 1.1 and for EF tools and in all but the last module, I’m using Microsoft.EntityFrameworkCore.Tools.DotNet 1.0.0-preview4. (I’m in the process of  updating the course to use the new 1.0.0 package)

You’ll need .NET Core 1.1 installed and the related dotnet SDK – which is not numbered as simply. Today the  .NET Core SDK tools are still in preview so the version number of the current “stable” build that goes with .NET Core 1.1 is 1.0.0-preview2-1-001377.  

Note that on March 7  when VS2017 has its official release, the .NET Core SDK tools will also be released so the versions will just be normal numbers like 1.0.0.

Here’s an example of what the dotnet ef command will tell you if you don’t have .NET Core 1.1 installed:

The specified framework 'Microsoft.NETCore.App', version '1.1.0' was not found.
 - Check application dependencies and target a framework version installed at:
 C:\Program Files\dotnet\shared\Microsoft.NETCore.App
 - The following versions are installed:
 1.0.1
 - Alternatively, install the framework version '1.1.0'.

You can get the correct version via the download grid at microsoft.com/net/download/core. The grid only exposes stable releases. If you’re looking for nightly builds (which at this time you need for using the csproj support), there’s a link to those just below the grid.

The set of downloads you get via the LTS button is for .NET Core 1.0.3. The Current button gives you the latest stable versions. The SDK button gets you the Runtime + SDK, whereas the Runtime button gives you ONLY the runtime.

The SDK installs will give you the SDK and the runtime. When you’ve selected the SDK set of installs, it says that it’s .NET Core 1.0. That’s referring to the version of the SDK. It will also install both the .NET Core 1.0 and .NET Core 1.1 runtimes. That single SDK is able to work with both of the runtimes. I’m on Windows x64 so my download is the first one on the list…the Windows x64 installer.netcoresdk10

Just as an FYI, if you select the Runtime set of downloads, then you will only be getting a specific version of a runtime and not the SDK.

netcore11runtime

After it’s installed, typing dotnet will show you that you the runtime version that your machine is running by default. That’s the later one. After installing the 1.0 SDK with both runtimes, dotnet tells me I’m running Version 1.1.0 of the runtime. 

 dotnet –version gives you the version of the SDK. That’s already showing me that there was a patch because the result says “1.0.1”.

If you installed this new SDK but are still seeing the old SDK version (1.0.0-preview2-001313), that is likely because that version is specified in the global.json file of your solution. That shouldn’t create a problem for using the migration commands, but it’s a good idea to have the correct version listed in global.json.

Some additional tips for you!

Commands can only run from an executable/test project

In my Pluralsight EFCore course, I have the DbContext in its own class library project. So when running dotnet ef, after solving all of the above problems, you’ll get a new message which is just pointing out that the commands depend on an executable to run. That message looks like this:

Could not invoke this command on the startup project 'TestEFCore.Data'. This version of the Entity Framework Core .NET Command Line Tools does not support commands on class library projects in ASP.NET Core and .NET Core applications.

In my case, I wasn’t ready to add a UI or test to the solution,  so I added a minimal console app just to cover this need. And it needs to reference the project with the DbContext. Once that’s sorted, you can use the —startup-project parameter of the dotnet ef command to point to that project. While I show all of this in my course, you can also see that in my MSDN Magazine article here: msdn.microsoft.com/magazine/mt742867

This will get a touch easier with the msbuild version of the EF Core tools. With the newer tooling, you’ll at least be able to run dotnet ef to get the command’s help without pointing to a startup-project, although to run sub commands, you’ll still need to specify the startup project.

Installing the EF Core Tools via NuGet in Visual Studio 2015

One of the viewers of the course reported a strange problem. He was able to add the EF Core Tools package in project.json and use the migrations from the CLI as expected. But if he attempted to add the package from the NuGet Package Manager or the Package Manager Console instead, he was back to the old ‘No executable found matching command “dotnet-ef”‘ error.

He finally noticed that there were errors when NuGet attempted to download the package. But in his IDE the errors were subtle, so he was unaware that the tools package was not installed. Here’s a screenshot he shared:

frsBKTFTRSjBGOFFZDJ6_nugetmanager

I figured out how to get myself into a similar bind and got a much more helpful error message:

2017-02-27_17-08-52

Package 'Microsoft.EntityFrameworkCore.Tools.DotNet 1.1.0-preview4-final' uses features that are not supported by the current version of NuGet. To upgrade NuGet, see http://docs.nuget.org/consume/installing-nuget.

Even though Visual Studio extension manager did not indicate an available update AND it listed my NuGet Package Manager version as 3.5 (the latest), I learned that the team responsible for this extension had temporarily stopped pushing notifications for updates! That change is noted in the “No Auto Updates” section of this blog post: http://blog.nuget.org/20161027/Announcing-NuGet-3.5-RTM.html

So I had to explicitly download the latest VSIX (ignoring the fact that it seemed to have the same version # as the one I had installed!) from the NuGet  distributions page. After installing that, it resolved the problem of installing the EF Core tools package from the Package Manager and Package Manager Console.

2017-02-27_17-14-46

There’s a sneak peek at EF Core with msbuild in VS2017

A few people mentioned to me that they decided to go straight to VS2017 when working through the demos in the course. And they also said they were confused by some differences and had to do some research. I know for sure that one of these devs was kicking himself when I asked if he had watched the VS2017 demo I did at the end of the course before trying to VS2017 along with the early demos. (His answer was “umm, now you tell me!”)  It’s listed in the table of contents for the course. So if you take a peek at that first, I think doing all the demos in VS2017 will be a lot easier! I am currently in the process of updating the VS2017 demos to use the RTM and latest tools.

Hope this helps!

Updated My EFCore / WebAPI / PostreSQL / XUnit Repo to 1.1

Today was dedicated to updating my long running repository sample that I started when EF Core was EF 7  to the newest version of EF Core: 1.1. Here is the updated repo: https://github.com/julielerman/EFCore-ASPNetCore-WebAPI-RTM.

Phase one of this update continues to use project.json.

In addition to updating the version #s of  the Nuget package references, I also made some changes to the code to reflect a few new features.

Pay attention to the tooling packages. In the tools section, the package name has changed – note DotNet at the end –  and the version is currently 1.0.0-preview3 even though IIS version is preview2.

 "tools": {
   "Microsoft.AspNetCore.Server.IISIntegration.Tools": 
       "1.0.0-preview2-final",
   "Microsoft.EntityFrameworkCore.Tools.DotNet":
       "1.0.0-preview3-final"
 },

Also in the dependencies, the EFCore Design package is 1.1.0 like the rest of EFCore. That’s part of the EF APIs, not tooling.

Code changes ….

You’ll discover the DbSet.Find method and change tracker Load method in use in the repository class. These were both added in to EF Core 1.1.

I modified the WeatherEvent class to fully encapsulate its Reactions collection using the support for mapping to IEnumerable. That resulted in some changes to constructors and the addition of an AddReaction method and a local variable.

Unrelated to EF Core, I also modified the SeedData.cs class. It reads a hard coded seeddata.json file to read in seed data. That data used old dates. I wanted the data to show current dates to help me tell that I really and truly pushed new data into the database. Since the Date property of WeatherEvent is private, they way I went about this was to read the raw JSON and update the date value that way then save the raw JSON back to the original file. Then I deserialize the JSON with a current range of dates into a set of WeatherEvents. This also means that I added Delete/Create database back in so the database gets thrown away and recreated/reseeded every time you start up the application.

The tests are also update to use the latest packages. In addition to changing the versions, I had to add a reference to an older package (InternalServices) as its dependency has not yet been updated in xunit.

Here’s the full project.json for the test project since I had to do a bunch of googling to figure it out.

{
 "version": "3.0.0-*",
 "description": "Tests for simple app using aspnetcore, efcore and   
                  postgresql. developed and run on OSX.",
 "authors": [ "Julie Lerman" ],
 "testRunner": "xunit",
 "dependencies": {
   "Microsoft.EntityFrameworkCore.InMemory": "1.1.0",
   "src": "3.0.0",
   "xunit": "2.2.0-beta4-build3444",
   "dotnet-test-xunit": "2.2.0-preview2-build1029",
   "Microsoft.DotNet.InternalAbstractions":"1.0.0"},
 "frameworks": {
 "netcoreapp1.0": {
   "dependencies": {
     "Microsoft.NETCore.App": {
     "type": "platform",
     "version": "1.1.0"
     }
   },
   "imports": [
     "dnxcore50",
     "portable-net45+win8"
     ]
   }
  }
}

I hope you find this repository useful to see EF Core 1.1 in action.

Oh and as per a tweet by Brad Wilson, I added SDK to my global.json file!

Now I have to go learn about why this is important. Clearly it is!

 

EF6 or EF Core? How Do I Choose?

In late October, I spoke at DevIntersection. One of my sessions was called EF6 or EF Core? How Do I Choose? As I’ve been an authority on EF since it’s earliest days, people have been asking me this question frequently, which inspired the talk.

The session was not recorded but I’m sharing my slides on SlideShare. I go into detail on the topic in my upcoming Pluralsight course, “EF Core: Getting Started” which I am currently building. Watch my Pluralsight author page (as well as twitter.com/julielerman and this blog!) for its release.

In the meantime, here is a link to the slides from the DevIntersection talk.ef6-or-ef-core

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.

Getting Started with EF6 Course on Pluralsight

image

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.

Installing EF Power Tools into VS2015 (with an update for VS2019)

March 2020: In comments below, someone asked about VS2019.

The EF Power Tools Community Edition (see July 2017 note below) still works for VS2019.

Erik EJ also created EF Core Power Tools.

While I’m at it, I thought I would also point out the plain old EF Tools for VS2019. For VS2019 (& IIRC for VS2017), these tools are installed via the Visual Studio Installer.
Entity Framework tools are installed as part of the Data storage and processing workload in the Visual Studio Installer.

You can also install them as an individual component under the SDKs, libraries, and frameworks category.

July 2017: something amazing happened! Erik Ejlskov Jensen, the creator of the SQLCe provider Entity Frameworkas well as the creator of the very popular SQL Server Compact Toolbox extension for Visual Studio, has given us a community version of EF Power Tools for VS2015 and VS2017. Thanks to the tools already being on GitHub, he forked the tools and now we have

EF6 Power Tools Community Edition that you can get via Visual Studio Extensions

Oct 2016 note: There have been over 60,000 hits to this blog post so far. My host is reaping the benefits ($$$). In July, I submitted a pull request to update the VSIX. The PR was finally merged. Now just waiting for the change to show up in the VS Gallery.

TLDR: If you don’t want to do the tasks (even though they are so easy) you can download the updated VSIX I created from here.

The Entity Framework Power Tools extension for Visual Studio has been around for quite some time and is still called a Beta. I cannot live without it’s “View Entity Data Model (Read-Only)” feature which I used to validate my code first models.

But if you try to install the extension into Visual Studio 2015, you won’t find it.

7-25-2015 9-47-12 AM

Checking the extension in Visual Studio Gallery, you’ll see that it hasn’t been updated to install into VS2015.7-25-2015 9-47-49 AM

The fix is nothing more than making it know about VS2015. There are no other compatibility problems that I have experienced. Modifying an extensions installation package (which is just a zip file!) to be aware of another version of Visual Studio is pretty easy. Here are the steps to get the EF Power Tools into VS2015.

Download the extension from the Visual Studio Gallery page.

Find the file

7-25-2015 9-50-13 AM

and change it’s extension to zip.

7-25-2015 9-50-33 AM

Extract the files from the zip file.

7-25-2015 9-53-01 AM

Open the extension.vsixmanifest file in a text editor and find the Supported Products section.

7-25-2015 9-53-25 AM

And copy paste one of the Visual studio elements, changing the version to 14.0. I have the Enterprise version but didn’t bother changing it from Pro here and it didn’t seem to be a problem.

7-25-2015 9-53-47 AM

Now you have to reverse your steps in order to recreate the VSIX file.

Select the files in the extracted folder and zip them. Don’t zip the folder. The files have to be at the root. (Guess how I learned that! Smile ) I named my zip file VSPowerTools15.zip

7-25-2015-9-55-47-AM.png

Rename the file to have the vsix extension.

7-25-2015 9-56-01 AM

Run the file right from here.

7-25-2015 9-56-16 AM

Voila!

7-25-2015 9-56-22 AM

If Visual Studio was open, you’ll have to restart to get this to kick in.

Also you’ll see Entity Framework Power Tools listed in the installed extensions when you look at the About section of Visual Studio 2015.

I accidentally mistook this for something it was NOT and (embarrassingly) tweeted it. I had forgotten that I had done this for the VS2015 preview. Then I installed VS2015 RTM on top of the preview and that picked up all of the installed extensions. When I saw the power tools listed in About, I thought they had a) finally gotten rid of the “Beta” tag and b) installed automatically with VS2015. When I realized the extension was installed, I uninstalled that and indeed the tool went away. So for anyone who saw that tweet…. sorry! Guilty as charged …

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

TLDR:
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

AttachGraph

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.

context.ChangeTracker.TrackGraph(newSamurai,

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

DbContextOptions

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

DbContext.Entry.SetState(EntityState)

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

DbContext.Entry.State=EntityState

 

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:

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.