EF 4.3 Beta 1 Released
The information in this post is out of date.
Visit msdn.com/data/ef for the latest information on current and past releases of EF.
For Code First Migrations see https://msdn.com/data/jj591621
At the end of November we released Beta 1 of Code First Migrations. At the time we released Code First Migration Beta 1 we also announced that we would be rolling the migrations work into the main EntityFramework NuGet package and releasing it as EF 4.3.
Today we are making Beta 1 of EF 4.3 available. This release also includes a number of bug fixes for the DbContext API and Code First.
We are planning for this to be the last pre-release version of migrations and our next release will be the final RTM of EF 4.3.
What Changed
This release has been primarily about integrating migrations into the EntityFramework NuGet package, improving quality and cleaning up the API surface ready to RTM.
Notable changes to Code First Migrations include:
- New Enable-Migrations command. You now use the Enable-Migrations command to add the Migrations folder and Configuration class to your project. This command will also automatically fill in your context type in the Configuration class (provided you have a single context defined in your project).
- Update-Database.exe command line tool. In addition to the power shell commands this release also includes Update-Database.exe which can be used to run the migrations process from a command line. You can find this tool in the ‘packages\EntityFramework.4.3.0-beta1\tools\’ under your solutions directory. The syntax for this command line tool is very similar to the Update-Database power shell command. Run ‘Update-Database /?’ from a command prompt for more information on the syntax.
- Migrations database initializer. This release includes the System.Data.Entity.MigrateDatabaseToLatestVersion database initializer that can be used to automatically upgrade to the latest version when your application launches.
- Complete xml documentation. This release now includes xml documentation (IntelliSense) for the migrations API surface.
- Improved logging. If you specify the –Verbose flag when running commands in Package Manager Console we now provide more information to help with debugging.
Other notable changes in EF 4.3 include:
- Removal of EdmMetadata table. If you allow Code First to create a database by simply running your application (without using Migrations) the creation is now performed as an Automatic Migration. You can then enable migrations and continue evolving your database using migrations.
- Bug fix for GetDatabaseValues. In earlier releases this method would fail if your entity classes and context were in different namespaces. This issue is now fixed and the classes don’t need to be in the same namespace to use GetDatabaseValues.
- Bug fix to support Unicode DbSet names. In earlier releases you would get an exception when running a query against a DbSet that contained some Unicode characters. This issue is now fixed.
- Data Annotations on non-public properties. Code First will not include private, protected or internal properties by default. If you manually include them in your model Code First used to ignore any Data Annotations on those members. This is now fixed and Code First will process the Data Annotations.
- More configuration file settings. We’ve enabled more Code First related settings to be specified in the App/Web.config file. This gives you the ability to set the default connection factory and database initializers from the config file. You can also specify constructor arguments to be used when constructing these objects. More details are available in the EF 4.3 Configuration File Settings blog post.
Getting Started
You can get EF 4.3 Beta 1 by installing the latest pre-release version of the EntityFramework NuGet package.
You will need NuGet 1.6 installed and specify the –IncludePrerelease flag at the Package Manager Console to get this pre-release version. Pre-release packages can only be installed from the Package Manager Console.
There are two walkthroughs for EF 4.3 Beta 1. One focuses on the no-magic workflow that uses a code-based migration for every change. The other looks at using automatic migrations to avoid having lots of code in you project for simple changes.
Upgrading From ‘Code First Migrations Beta 1’
If you have Code First Migrations Beta 1 installed you will need to uninstall the EntityFramework.Migrations package by running ‘Uninstall-Package EntityFramework.Migrations’ in Package Manager Console.
You can then install EF 4.3 Beta 1 using the ‘Install-Package EntityFramework –IncludePrerelease’ command.
You will need to close and re-open Visual Studio after installing the new package, this is required to unload the old migrations commands.
RTM Timeline
We are planning for this to be the last pre-release version of migrations and are still on-track to get a full supported, go-live, release of EF 4.3 published this quarter (first quarter of 2012).
MSDeploy Provider Update
We originally blogged about our plans to deliver an MSDeploy provider that could be used to apply migrations to a remote server. After many long hours iterating on this and working with the MSDeploy team we’ve concluded that we can’t deliver a good MSDeploy story for Migrations at this stage.
The primary issues arise from us needing to execute code from your application assemblies on the remote server, in order to calculate the SQL to apply to the database. This is a requirement that other MSDeploy providers have not had in the past. We are going to continue working with the MSDeploy team to see if we can deliver something in the future, but unfortunately we won’t be shipping an MSDeploy provider in the immediate future.
If you are able to connect to the remote database from the machine you are deploying from, then you can use the Update-Database.exe command line tool to perform the upgrade process. You can also use the System.Data.Entity.Migrations.DbMigrator class to write your own code that performs the migration process.
EF 5.0 (Enum support is coming… finally!)
We’ve been working on a number of features that required updates to some assemblies that are still part of the .NET Framework. These features include enums, spatial data types and some serious performance improvements.
As soon as the next preview of the .NET Framework 4.5 is available we will be shipping EF 5.0 Beta 1, which will include all these new features.
Support
This is a preview of features that will be available in future releases and is designed to allow you to provide feedback on the design of these features. It is not intended or licensed for use in production. If you need assistance we have an Entity Framework Pre-Release Forum.
ADO.NET Entity Framework Team
Comments
Anonymous
January 12, 2012
Hi. I'm really excited about Code First Migrations. Could the DbMigration class pass in the name of the provider used (System.Data.SqlClient or Devart.Data.Oracle or other) to the Up and Down methods so that provider specific sql could be generated? See social.msdn.microsoft.com/.../c81dfd60-ede5-4873-9f4d-04e240c293c2. Also, should the DbSetExtensions not work with IDbSet instead of DbSet? kind regards RemcoAnonymous
January 12, 2012
Hi the Pluggable Conventions will be avaliable?Anonymous
January 12, 2012
Hi, also there some plans to add extension points at the Pluralization of the EntityFramework? My university has a awsome project for Portuguese Pluralization but there is no way to plug-in that into EntityFramework.Anonymous
January 12, 2012
Oh ? EF 5.0 in .NET 4.5 ?? you renamed EF 2.0 to 4.0 to match .NET version, now you are jumping ahead without reasons ? Why not keep EF and .NET versions synced ? so .NET 4.5 has C# 5.0 and EF 5.0, that's a messAnonymous
January 12, 2012
As Regis notes, it's unclear to me if conventions support is also being enabled. I wanted to add a TableNamePrefixConvention or similar.Anonymous
January 12, 2012
Guest, I think that now, EF Team wants to desynchronize from .NET and be a standalone project. Because EF needs much more frequent releases that .NET Framework. I hope we can use the EF 5.0 at .NET 4.0Anonymous
January 12, 2012
I agree EF should be a standalone project, but they should do it FROM THE BEGINNING. now EF is already trappen in .NET and this is it, so at least dont create more confusions. EF 5.0 for .NET 4.0 is not possible, see blogs.msdn.com/.../how-we-talk-about-ef-and-its-future-versions.aspx actually WCF WPF WF and many other things should be standalone product too, even ASP.NET. now we have .NET Core .NET Client .NET Extended and XNA, CoreCLR, Compact, Phone...., wow!Anonymous
January 13, 2012
@Guest(1): thanks for the feedback. We actually had a good reason to change how we do our versioning: that we plan to continue releasing at a higher pace than the .NET Framework. We looked at alternatives and we decided to commit to use Semantic Versioning, which provides a set of very straight forward rules for when you have to increment the different portions of your version. And yes, it is explained in more detail at: blogs.msdn.com/.../how-we-talk-about-ef-and-its-future-versions.aspx.Anonymous
January 13, 2012
@Regis and @Andy: Thanks for the feedback! No, we still don't allow plugging your own custom conventions. We agree it would be very a very powerful feature and we have it in our backlog. The main thing that we need get to first is a publically consumable object model for all our metadata and mapping, so that custom conventions will have the power to manipulate the whole model as opposed to just invoking the existing fluent API.Anonymous
January 13, 2012
@Regis, re pluralization extensibility: Agreed this would be great to add. Pluralization is currently implemented in our core libraries in .NET, which are subject to a longer process to be updated, but we may choose to get away from that. I encourage you to vote for this in http://ef.mswish.net.Anonymous
January 13, 2012
The comment has been removedAnonymous
January 13, 2012
一直关注啊..但是没有机会用啊.Anonymous
January 13, 2012
The comment has been removedAnonymous
January 14, 2012
I'm just finishing the first iteration of my first code first project and I just wanted to drop by to say thanks, what an amazing tool it is !!Anonymous
January 15, 2012
EF 5.0 is comming. What does it mean? In one of your previous articles you mentioned that EF in .NET 4.5 will be renamed to EF Core libraries and DbContext API will be renamed to EF. So what is EF 5.0? Is it DbContext API supporting new features from EF Core libraries included in .NET 4.5? Or is it EF Core libraries. In later case it is completely misleading step. EF Core libraries are still part of .NET framework and so they should use version of .NET framework as common in rest of the framework. If you want to move libraries from .NET just do it and after that play with versions as you want. Till that time any versioning changes in core libraries are unacceptable. Even versioning DbContext API to EF 5.0 is not good idea unless you are pretty sure that .NET 5.0 will not contain EF core libraries any more. If you want to differ from rest of APIs included in .NET framework do it in feature set, usability, performance and quality, not in curiosity. Btw. I just tried to use data annotations on private property with getter and setter and it didn't work. Do you plan to show some sample for this feature?Anonymous
January 15, 2012
The comment has been removedAnonymous
January 15, 2012
The comment has been removedAnonymous
January 15, 2012
Can we expect support for batch operations (Insert/Update/Delete) in EF 5.0? Thanks Ravi PathakAnonymous
January 16, 2012
Hi, I wanted to use it, but I get an exception when adding a new entity to its DbSet<TEntity>. (didn't even call ctx.SaveChanges()). The error I get is: The provider did not return a ProviderManifestToken string. {"A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)"}. I corrected the connectionString to point to the correct machineinstance, but the same error happens. I have Sql server R2 Express and my server instance name is [MACHINE]SQL (and not [MACHINE]Sqlexpress). I can access without problems my existing databases from management studio. SharedMemory/NamedPipes/TCP-IP protocols are also enabled. The DbContext inheriting class is very simple: public class CartContext : DbContext { public DbSet<Cart> Carts { get; set; } } Do you have some ideas on what could be going wrong?Anonymous
January 16, 2012
Hi team -- great job on code first. I'm looking forward to the EF 5.0 release in a big way. I did have a question...what is the best way to log bug report/feature requests? Connect or something else?Anonymous
January 16, 2012
The comment has been removedAnonymous
January 18, 2012
I love all this progress in CF and the open communication with the community. You guys are killing it, keep it up.Anonymous
January 18, 2012
I realy lke the new EF but i have bad bug.... Update-database is broken in one of my soltions.... System.Reflection.TargetInvocationException: Адресат вызова создал исключение. ---> System.ArgumentException: Параметр задан неверно. (Исключение из HRESULT: 0x80070057 (E_INVALIDARG)) --- Конец трассировки внутреннего стека исключений --- в System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters) в System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams) в System.Management.Automation.ComMethod.InvokeMethod(PSMethod method, Object[] arguments) I've copied EF classes to another soltion and it works... how do i repair my first soltion? moving ef classes to another project didn't help meAnonymous
January 18, 2012
Keep up the good work and thank you again!Anonymous
January 19, 2012
The comment has been removedAnonymous
January 23, 2012
@Bill, EF doesn't currently support nested types. Cheers, Andrew.Anonymous
January 23, 2012
Is it possible to script out to specified file location. Right now it looks like the -Script parameter always creates a new script so it isn't possible to incorporate scripting the database as part of the build process.Anonymous
January 24, 2012
Feature request for DbMigrations derived classes. I would like to type Add-Migration -Base MyApp.Data.MyCustomMigrationClass and have it generate a migration of that base type.Anonymous
January 24, 2012
Another question: Is it possible to get the identity of an inserted record mid transaction? It seems like Id always equals zero even after save changes (before transaction.complete). I need the id for sending a transactional MSMQ message.Anonymous
January 24, 2012
@Matt, You should be able to customize Migrations to do this now. You'll need to subclass CSharpMigrationCodeGenerator and override the WriteClassStart method. You can register your custom generator in your MigrationsConfiguration class by setting the CodeGenerator property. Cheers, Andrew.Anonymous
January 24, 2012
Very cool. Thanks!Anonymous
January 24, 2012
Andrew, Very cool! Thanks!Anonymous
January 25, 2012
I am really looking forward to Enum support. Any idea when we will have thisAnonymous
January 25, 2012
Sorry I did not read the full article. So I can now see that Enum support will be in EF 5Anonymous
January 25, 2012
Seeing support for Migration in EF5, can we also expect that we will be able to initialize the database via Code First in this version? I'm currently using NHibernate, where I can easily initialize a purely in-memory sqlite database (a feature sadly missing from SQL CE) from my mappings. So far, EF would force me to write database engine specific SQL to initialize the database by hand, for each database engine supported.Anonymous
January 25, 2012
@Cygon4: Migrations support is being added in EF 4.3, no need to wait for EF 5.0. I am not completely sure I understand what exactly you are refering to with the term "initialization". EF incorporated APIs to create, drop and verify the existence of a database in 4.0. With Migrations in EF 4.3 we are moving to a model that provides more granular control at the time individual objects are created in the database, providing the ability to specify indexes and default values for columns. In both models the writer of the ADO.NET provider has to implement specific methods in the provider classes to enable this functionality, but you shouldn't need to write database specific code. If by initialization you are refering to the ability to fill the database with seed data, both Migrations and Database Initializers (avialble since EF 4.1) offer this functionality in a database agnostic way.Anonymous
February 02, 2012
I'm very pleased to read about when the enum support will be on the shelf. However, not less important than that is have the RIA team develop a matching infrastructure so that those entities are generated in the client as well and act similarly. Currently, the supported version is EF ≥ 4.0 && < 4.2, which makes even 4.2 impossible in SL projects. ThanksAnonymous
February 02, 2012
I was looking to get the latest EF 4.2 or 4.3 beta but our development environment cannot reach out to the internet. It sits behind firewall which is locked down without our control. We use webdav to transfer files to and from the real world to our development lab and visa versa. How can we can the latest release or beta of EF?