search

dotnet / ef6

This is the codebase for Entity Framework 6 (previously maintained at https://entityframework.codeplex.com). Entity Framework Core is maintained at https://github.com/dotnet/efcore.
https://docs.microsoft.com/ef/ef6
MIT License
1.41k stars 538 forks source link

EF 6.5.0 RTM NuGet Package BROKEN #2262

Closed robertmclaws closed 3 weeks ago

robertmclaws commented 3 weeks ago

RTM PACKAGE FAILURE

There is an error in the package for 6.5.0 that has broken the EF build process in Visual Studio. The package is not being built properly, therefore EntityDeploy is no longer being called to compile EDMX files into the project.

👉🏻 For people experiencing this issue, there is a temporary workaround, see below. 👈🏻

SYMPTOMS:

You will suddenly get a "Metadata cannot be loaded" error in any project that leverages the DbContext, where the code previously functioned normally.

IMPACT

Automated builds that were previously working are now failing. I spent several hours tracking down why my services suddenly stopped working.

NEEDED RESOLUTION

EVIDENCE

New EntityFramework 6.5.0 RTM vs EntityFramework 6.4.4 RTM packages:

image image

WORKAROUND

In the project with your EDMX file, replace your <PackageReference Include="EntityFramework" ... /> line with the following entries:

        <PackageReference Include="Microsoft.EntityFramework.SqlServer" Version="6.*" />
        <PackageReference Include="EntityFramework" Version="6.4.*" ExcludeAssets="compile,runtime" NoWarn="NU1605" />

This will tell the build process to use the EntityCompile tasks from the EF 6.4.4 package, but NOT to reference anything in the lib folder for compilation. That means the downstream reference to EntityFramework 6.5 from the Microsoft.EntityFramework.SqlServer package will still get compiled into the build and your code will work correctly. The "NoWarn" attribute will tell the build process not to complain that you're referencing a version that the .SqlServer package doesn't like.

robertmclaws commented 3 weeks ago

@ajcvickers @ErikEJ tagging you both since this is a "broken in Production" situation.

robertmclaws commented 3 weeks ago

Updated with a verified workaround.

ErikEJ commented 3 weeks ago

@robertmclaws I created a PR with a fix...

AndriySvyryd commented 3 weeks ago

Fixed in ac4a11e

robertmclaws commented 3 weeks ago

Thanks everyone for getting this fixed so quickly!

birbilis commented 2 weeks ago

wonder if issues with the NuGet package (the unrecognized framework shown in 1st screenshot) could be caught automatically via some test case

robertmclaws commented 2 weeks ago

The NuGet package is just a zip file, so there absolutely could be a smoke test to enumerate through the file and make sure the structure is the way it is supposed to be.

Sounds like something I could add to Breakdance.

AndriySvyryd commented 2 weeks ago

Adding any sort of automated testing is out of scope for EF 6.x And we use a very different release process for EF Core

robertmclaws commented 2 weeks ago

Adding any sort of automated testing is out of scope for EF 6.x And we use a very different release process for EF Core

I mean, if someone contributes a fix to make sure people's builds don't randomly break again, are you going to reject it? This took significant time and expense out of my weekend to triage and fix... I would prefer to not have that happen again.

AndriySvyryd commented 2 weeks ago

Adding any sort of automated testing is out of scope for EF 6.x And we use a very different release process for EF Core

I mean, if someone contributes a fix to make sure people's builds don't randomly break again, are you going to reject it? This took significant time and expense out of my weekend to triage and fix... I would prefer to not have that happen again.

We might, since code reviews can take a non-trivial amount of time and the chance of hitting the same kind of packaging issue isn't high. Also, any new dependency would be unacceptable.