October 4, 2012

Unicorn Myths Debunked: Entity Framework 4.4

Caution, this post is a bit of a rant. I continue to see people in the community referring to something called Entity Framework 4.4, and I just want to set the record straight.

There is no such thing as Entity Framework 4.4!

The 4.4 comes from the assembly version of EntityFramework.dll when you install EntityFramework 5.0 into a project that targets .NET Framework 4.0. This is merely a side effect of how the runtime loads and binds to assemblies, and in no way reflects the version of the product.

An experiment

Here is some simple code that prints out version information about the Entity Framework assembly.
var assembly = typeof(DbContext).Assembly;
var name = assembly.GetName();
var info = FileVersionInfo.GetVersionInfo(assembly.Location);

Console.WriteLine("Assembly Version: {0}", name.Version);
Console.WriteLine("Product Version: {0}", info.ProductVersion);
When we run the code on an application targeting .NET Framework 4.5, we get the following output.
Assembly Version: 5.0.0.0
Product Version: 5.0.0.net45
On .NET Framework 4.0, we get:
Assembly Version: 4.4.0.0
Product Version: 5.0.0.net40
As you can see, the product version in both cases is 5.0.

In conclusion

Please always refer to the product as Entity Framework 5.0 and, if you think the information is relevant, also let people know what version of the .NET Framework you are targeting.

6 comments :

Randy said...

Brice -

I get what you're saying: "As the developer of a product, I have the choice to make Product Version != Assembly Version != File Version. Product Version trumps all.".

http://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin

Here's the kicker; all the posts on EF4.4 are saying "we don't like what you've done and it's confusing to us. When the community talks to each other we use a term 'Version' to talk amongst ourselves that usually refers to the Assembly Version and in this case it's EF4.4".

You have the right to rant as a developer and state "there's no such thing as EF4.4" but the community sees it differently. As a product manager, I think this is great feedback. Great because it recognizes an opportunity to grow and be better at communicating and clarifying what all of this means to your end users. Perhaps it's just a learning opportunity to say "our end users found this confusing even though it's 'technically' correct, what could we have done differently?". To rant at the community just makes things worse and creates an "I'm better than you and know what's right" attitude.

I recently upgraded from EF4.1 to EF5.0. I was totally confused. Primarily because VS2010 says that the "Version" I'm using is EF4.4. VS2010 doesn't distinguish and while that is the Visual Studio team's issue to resolve, it's not surprising that the community references EF5.0 as EF4.4 because of that. Perhaps your rant should be directed at them.

Lastly, and this is a personal preference, I don't like writing EF5.0.net40 every time I want to inquire on a question. I simply want to say EF4.4 as we all know what it means: EF5.0.net40.

Hopefully, this will provide some food for thought when it comes to version. People just expect Product Version = Assembly Version = File Version. Yes, it doesn't have to be that way, it's just easier for all of us.

Kind Regards,

Randy

Brice Lambson said...

Thanks Randy,

My motivation for writing this post becomes clearer in the context of EF6. In EF6, the differences between running on .NET 4.0 and .NET 4.5 are greatly reduced. All of the features that previously only worked on 4.5 (Enums, Spatial, etc.) will also work on 4.0 in EF6. Since the API surface and behavior will be the same, we can go back to having everything just be 6.0.0.

I agree that it has been confusing. We've tried very hard as a product team to reduce this confusion. It's unfortunate that we had to go through this pain in order to get out of the Framework.

I am very much looking forward to being past this transition. Hopefully, at that point, a lot of the confusion will go away.

One alternative that we considered was to release a 4.3.2 that included all of the EF5 bug fixes and just make EF5 work on .NET 4.5. We thought, however, that this would send the wrong message to .NET 4.0 developers since we had every intention of making future versions of EF work on both .NET 4 and 4.5.

P.S. I re-read this post again the other day and had the exact same reaction that you did: It is in poor taste. It should have been a post explaining why we decided to do it the way we did, thanking the users for their patience, and reassuring them that things would be better in the next release. When I get a chance, I will write that post and update this one accordingly.

Daniel said...

Hi Brice, what would you say is the anticipated release date for EF 6.0 ?

Thanks,

Daniel (Sr. Solution Architect)

danielstlouis said...

So am I correct to assume that EF 5.0 on .NET 4.0 is the same as EF 4.3.1 or is there additional fixes that are part of EF 5.0 (aka 4.4) that are not in 4.3.1 ?

Thanks,

Daniel

Brice Lambson said...

@Daniel,

We haven't set a date for the final release of EF6 yet. The Entity Framework CodePlex page is the best place for the latest information about the development status. (For example, here is the backlog of EF6 work items.)

EF 5 on .NET 4 includes all of the bug fixes that went into the .NET 4.5 version; just no enum support, table-valued functions, or spatial data types since these depend on components that ship as part of the .NET Framework.

Anonymous said...

program.cs

using System;
using System.Data.Entity;
using System.Data.Entity.ModelConfiguration.Conventions;
using System.Linq;
using System.Data.SQLite;
using System.Data.SqlClient;

namespace Humanresource
{
public class HumanResource
{
public Int64 ID { get; set; }
public String Name { get; set; }
public int Age { get; set; }
public int Salary { get; set; }
}
public class Humanresource: DbContext
{
public DbSet Humanresources { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove();
}
}
public class Program
{
public static void Main(string[] args)
{
int i = 0;
while (i == 0)
{
Console.WriteLine("Enter 1 for existing entry::::");
Console.WriteLine("Enter 2 for new entry::::");
Console.WriteLine("Enter 3 for tax calculation::::");
Console.WriteLine("Enter 9 to Exit.");
i = int.Parse(Console.ReadLine());
switch (i)
{
case 1:
{
using (var db = new Humanresource())
{
var query = from a in db.Humanresources
orderby a.ID
select a;
Console.WriteLine("\n\n");
foreach (var item in query)
{
Console.WriteLine("\nID:" + item.ID + " Name: " + item.Name + " Age:" + item.Age + " Salary: " + item.Salary);
}
Console.ReadLine();
}
break;
}
case 2:
{
using (var db = new Humanresource())
{
Console.WriteLine("Enter your name:");
var name = Console.ReadLine();
Console.WriteLine("Enter your age:");
var age = int.Parse(Console.ReadLine());
Console.WriteLine("Enter your Salary");
var salary = int.Parse(Console.ReadLine());
HumanResource employee = new HumanResource() { Name = name, Age = age, Salary = salary };
db.Humanresources.Add(employee);
db.SaveChanges();
}
Console.WriteLine("Your Entry has been saved successfully! \n\n Thanks for registering!");
Console.ReadLine();
break;
}
case 3:

case 9:
Console.WriteLine("Good Bye!!!");
break;
default:
Console.WriteLine("You have entered wrong entry!!!!!!!!\n thank you!!!");
break;
}
if(i!=9)
i = 0;
}
Console.WriteLine("\n\nThanks for using the service.....");
Console.ReadLine();
}
}
}
Install-Package System.Data.SQLite.Linq -Pre -Source https://www.myget.org/F/bricelam/




app.config


























i can create .sqlite file using this code so my database is ready but i didnt know how to create table using entity framework in SQlite...