Partilhar via


Code First Migrations: 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 September we released Alpha 3 of Code First Migrations. Based on Alpha 2 and Alpha 3 feedback your telling us that we are building the right thing… so it’s time to start improving quality and working towards our first go-live release. Today we are making Beta 1 available which is our first step in that direction.

 

What Changed

This release has been primarily about improving quality and cleaning up the API surface ready to RTM. There aren’t any significant changes to the user experience.

Some more notable changes include:

  • Class and method renames. We’ve done a lot of renaming and refactoring since Alpha 3. There are some important notes in the next section about how these changes affect migrations that were generated with Alpha 3.
  • Migrations will now create indexes on foreign key columns.
  • Improved model change detection. We fixed a number of bugs in the way we look for changes in your model and scaffold migrations. This includes things such as detecting CascadeDelete changes on relationships.

 

Upgrading From Alpha 3

If you have Alpha 3 installed you can use the ‘Update-Package EntityFramework.Migrations’ command in Package Manager Console to upgrade to Beta 1. You will need to close and re-open Visual Studio after updating, this is required to reload the updated command assemblies.

You will also need to update any existing code to reflect a series of class and method renames:

  • The Settings class has been renamed to Configuration. When you update the NuGet package you will get a new Configuration.cs (or Configuration.vb) file added to your project. You will need to remove the old Settings file. If you added any logic for seed data etc. you will need to copy this over to the new Configuration class before removing Settings.
    (This file rename is a result of us changing the base class for this class from DbMigrationContext to DbMigrationsConfiguration)
  • If you have existing migrations that call ChangeColumn you will need to update them to call AlterColumn instead.
  • There is a designer code file associated with each migration in your project, for migrations generated with Alpha 3 you will need to edit this file. You will need to add a using statement for System.Data.Entity.Migrations.Infrastructure and change the references to IDbMigrationMetadata to IMigrationMetadata.

 

RTM as EF4.3

So far we have been shipping Migrations as a separate EntityFramework.Migrations NuGet package that adds on to the EntityFramework package. As our team has been looking at the grow-up story to Migrations from a Code First database that was created by just running a Code First application it’s becoming clear that Migrations is a very integral part of Code First. We’ve also heard feedback that we need to reduce the number of separate components that make up EF. Because of this we are planning to roll the migrations work into the EntityFramework NuGet package so that you get everything you need for Code First applications in a single package. This will be the EF4.3 release.

The timeline to our first RTM of Code First Migrations depends on the feedback we get on this release but we are currently aiming to have a go-live release available in early 2012. We’re planning to make a Release Candidate available before we publish the final RTM.

 

What’s Still Coming

Beta 1 only includes the Visual Studio integrated experience for Code First Migrations. We also plan to deliver a command line tool and an MSDeploy provider for running Code First Migrations.

We are planning to include the command line tool as part of the upcoming RTM.

We’re working with the MSDeploy team to get some changes into the next release of MSDeploy to support our new provider. Our MSDeploy provider will be available when the next version of MSDeploy is published. This will be after our initial RTM of Code First Migrations.

 

Getting Started

There are two walkthroughs for 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.

Code First Migrations Beta 1 is available via NuGet as the EntityFramework.Migrations package.

 

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

License.rtf

Comments

  • Anonymous
    November 29, 2011
    I just came here to say, apart from the usefulness of Code First Migrations I have to congratulate you on the good job you guys are doing at everything else, i.e., managing this blog with incredibly detailed info, possible release dates, answering comments, walkthroughs side-by-side new releases, taking in feedback and acting on it, etc. It makes us feel almost like part of the team. Thank you very much.

  • Anonymous
    November 29, 2011
    I will try this new version. I can´t use Alpha 3: social.msdn.microsoft.com/.../b89279bd-666b-4489-97f6-684b7667f3ab

  • Anonymous
    November 29, 2011
    Congratulations team! EF Code First is perfect and Code First Migrations will improve this perfection! Congratulations! Your work is perfect! I am very proud of work with this feature! Thank you for your job and dedication!

  • Anonymous
    November 29, 2011
    I am struggling to do a Zero to one Relationship to a child object.  I have tried TPH, TPT and even EDMX. Please take a look at below two sites where I have posted request for help, I am sure this is possible but maybe EF is not a very popular ORM hence I am not getting much response. stackoverflow.com/.../entity-framework-inheritance-zero-to-one-relationship-to-child-object-how-t social.msdn.microsoft.com/.../69d9145a-f7ec-4845-b01a-26e57e9ba16e

  • Anonymous
    November 30, 2011
    How do we configure for SqlCE support?

  • Anonymous
    November 30, 2011
    How do you handle scenarios where you need to update existing data in the database with code rather than SQL?  I posted this before, but say you want to use a C# function to populate the Blog.Abstract property in a way that can't easily be done with a SQL update statement (for example parse the blog contents and truncate at the end of a sentence).  We need a way to select data from the database in the migration, do some operations on it in code, and then put that modified data back in to the database.  We've been using migrations for years and that's one of our most common scenarios (we've had to build custom code to work around it when using FluentMigrator). All the communication, voting, and early access versions are a breath of fresh air.  Keep it up!

  • Anonymous
    November 30, 2011
    I have the EF nuget package installed at my class library and at asp.net MVC project If you put migration together EF, I will end with migration references and config files in both projects

  • Anonymous
    November 30, 2011
    @Andrew Peters - So is cascadeDelete : true by default now? I am a little confused on how the scaffolding handles this with regards to the fluent api of EF configurations. Could you please elaborate? Regards, Sam Striano

  • Anonymous
    November 30, 2011
    The comment has been removed

  • Anonymous
    November 30, 2011
    "Migrations will now create indexes on foreign key columns." I generated the script using Update-Database, and I did not see any CREATE INDEX statements for foreign keys. Is there some kind of property setting for this?

  • Anonymous
    November 30, 2011
    I am getting an error when using SqlCE. Using the '- verbose' flag I can see that all of the table and index relaerd scripts run, but then the methods under the section [Inserting migration history record] I get the error. The full details are located in the pre-release forum under the titled post "Migrations Beta1 - Error when calling 'update-database' when using SqlCe" created on Thursday, 12/1/2011.

  • Anonymous
    November 30, 2011
    I'm in CST, so the date for my post in PST is Wednesday, 11/30/2011.

  • Anonymous
    December 01, 2011
    Got things work using Sql Express and a .mdf file. This is -really- nice! :)

  • Anonymous
    December 01, 2011
    @Sam Striano, By convention, Code First will enable cascade delete for 1..* associations. Perhaps this is what you are seeing? Cheers, Andrew.

  • Anonymous
    December 01, 2011
    The comment has been removed

  • Anonymous
    December 07, 2011
    The comment has been removed

  • Anonymous
    December 09, 2011
    What if I want complete control over DB schema, willing to create it manually. But from time to time I need to check if database model is in sync with EF models. I would appreciate having a tool allowing me to run that type of comparison. I would use it instead of current version of "EntityFramework.Migrations".

  • Anonymous
    December 09, 2011
    Can you please describe a workflow for working with EntityFramework.Migrations in a team and its project hosted under source control system?

  • Anonymous
    December 09, 2011
    ..for example one developer updated the model, created new migration file and checked in all changes including migration file under source control system. Then another developer pulled recent version into his branch, but he needs to merge it before continuing working on his own branch of the project.. won't there be problems during such merge operations?

  • Anonymous
    December 12, 2011
    Is the fluent API still supported with Code First Migrations?  I don't see my mapping classes being called when Update-Database is called.  Also, do you have to shut down visual studio and reload in order for Update-Database to pick up any changes to your class model after having called it previously?  That seems to be the behaviour.

  • Anonymous
    December 12, 2011
    @zl1 Actually, I see a benefit to having the column name included in the name of the foreign key. For example, I have some tables where there are multiple foreign keys linking to the same table. SQL Management Studio just appends a digit to the end of the foreign keys. This makes it difficult to tell which foreign key corresponds to which navigation property if you do something like database first (using non-code first). So, it's useful to include the column name in an example like the following. A grant has a local investigator and a principal investigator. Both of these foreign keys map to the Person table. So, if it does include the column name like you say, I see that as a good thing and better than what SSMS does by default. Grant LocalInvestigatorId PrincipalInvestigatorId Person Id I.e. I would rather have FK_Grant_Person_LocalInvestigatorId FK_Grant_Person_PrincipalInvestigatorId FK_Grant_Person FK_Grant_Person1

  • Anonymous
    December 14, 2011
    Here is my alternative to EntityFramework.Migrations package; instead of maintaining model change history it physically compares database schema with EF Code-First model during database initialization or/and manually by request. If you develop both model and db schema by hand, it allows to find quickly all the differences / incompatibilities between the db schema and the model. github.com/.../data - It's an alpha version. Feedback is always welcome!

  • Anonymous
    December 14, 2011
    Is it possible to trigger a database update programmatically from within the application at runtime? Otherwise I'm not sure how to use this while automatically deploying/updating my application on hundreds of customers' servers?

  • Anonymous
    December 15, 2011
    @Kristoffer, Yes, check out the DbMigrator class.

  • Anonymous
    December 16, 2011
    I am having a problem with Model-first programing with many-to-many relations. Entity framework keeps changing the names of the join fields back to RelationName_FieldName, even after I try to set the field name to just FieldName. Bug report is here: connect.microsoft.com/.../entity-framework-chaning-the-column-names-of-an-association-table This is a real headache, because we want to do model-first programming, so that we can add custom attributes to our entities.

  • pmcilroy@ms
  • Anonymous
    December 19, 2011
    First of all I think Migrations is one of the last functionalities I missed in the CTP, so great job done. However I have one tiny problem. I switched over to Migrations and therefore had to include a reference to EntityFramework instead of the System.Data.Entity. Now I'm having problems with changing the state of a entity with the enumertor EntityState. It appears not to be included in EntityFramework and using Migrations I can not use the System.Data.EntityState anymore. What is the replacement or workaround for this?

  • Anonymous
    December 19, 2011
    @Capellio: you will need references to both EntityFramework.dll and System.Data.Entity.dll as some parts of the API, like the EntityState enum, are defined in the later.  Hope this helps.

  • Anonymous
    December 26, 2011
    Would it be possible to have CF Migrations read annotations in order to determine the [DiscriminatorColumn] in SINGLE_TABLE / Table per Hierarchy Inheritance?  Then the public classes that extend the abstract super class could use a [DiscriminatorValue].  This is how a lot of legacy sql tables work in the real world

  • Anonymous
    December 27, 2011
    Hi, I'm having problems with migrations since the Model value for the _MigrationHistory table is about 8800 chars. Should I manually change the dimension of this field?

  • Anonymous
    December 29, 2011
    Just wondering when or if a second level cache will be added to the Framework. It would be nice if his was shipped with EF

  • Anonymous
    December 30, 2011
    The comment has been removed

  • Anonymous
    January 08, 2012
    Any chance you could share what you are doing to get the MSDeploy provider to work?  I hit an issue working on a provider that required to be able to access CLR 4 assemblies.

  • Anonymous
    January 09, 2012
    @Colin Bowern: We've hit a few limitations while implementing our Web Deploy provider. We've raised these to the Web Deploy team. Having said that, a couple of ways to get .NET 4 code running from a provider are:

  1. Configure Web Deploy to run as a .NET 4 process. This may not, however, be possible for all scenarios.
  2. Launch a separate .NET 4 process from your provider. For additional Web Deploy support, I'd try <a href="forums.iis.net/1144.aspx">their forums</a>.