Partager via

Code First Migrations: Alpha 2 Released

  • Article

 

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

 

Six weeks back we released the first preview of Code First Migrations. This preview was called ‘Code First Migrations August 2011 CTP’. However, after some changes to how we name our releases it is best to think of that release as ‘Code First Migrations Alpha 1’. Today we are happy to announce that ‘Code First Migrations Alpha 2’ is available.

Alpha 2 is still is primarily focused on the developer experience inside of Visual Studio. We realize this isn’t the only area in which migrations is important and our team is also working on scenarios including team build, deployment and invoking migrations from outside of Visual Studio as well as from custom code.

Note: If you have received the following error when trying to use Code First Migrations Alpha 2 it is most likely due to bugs that were causing a dependency on SQL Compact and a dependency on a local SQL Express instance. We have released an updated package that resolves both these issues, please ensure you have updated the EntityFramework.Migrations package to version 0.6.2. You will need to close and re-open Visual Studio after updating the package, failure to do so will result in an error stating that “The project 'Demo' does not contain any migration contexts”. If you continue to get errors after updating to the latest package and re-starting Visual Studio then please start a thread in our Pre-Release Forum.

Add-Migration : Exception has been thrown by the target of an invocation.
At line:1 char:14
+ Add-Migration <<<< Init2
+ CategoryInfo : NotSpecified: (:) [Add-Migration], TargetInvocationException
+ FullyQualifiedErrorId : System.Reflection.TargetInvocationException,System.Data.Entity.Migrations.AddMigrationCommand

 

What Changed

The short answer… a lot! You gave us a lot of feedback on our first alpha and we summarized it in the 'Code First Migrations: Your Feedback' blog post. The changes are pretty widespread so we would recommend reading the Code First Migrations Alpha 2 Walkthrough to get an overview of the new functionality. Here are some of the more notable changes:

  • We did a lot of work to improve the ‘no-magic’ workflow, including a code based format for expressing migrations. Our walkthrough also starts with the no-magic approach and then shows how to transition to a more-magic approach for folks who want to use it.
  • A provider model is now available. Providers need to inherit from the System.Data.Entity.Migrations.Providers.DbMigrationSqlGenerator base class and are registered in a new Settings class that is added when you install the NuGet package. Alpha 2 includes a provider for SQL Server (including SQL Azure) and SQL Compact.
  • We’ve taken a NuGet package name change. Alpha 1 was released as EntityFramework.SqlMigrations, but given the design changes that name makes less sense. We have now dropped the ‘Sql’ and are now just EntityFramework.Migrations.
  • We’ve improved how we do type resolution to find your context etc. In the first preview there were a number of issues around how we discovered your context, especially in solutions with multiple projects. This would result in various errors when trying to run either of the migration commands. We’ve done some work to make this more robust in Alpha 2.

 

Feedback

We really want your feedback on this work so please download it, use it and let us know what you like and what you would like to see change. You can provide feedback by commenting on this blog post.

The key areas we really want your feedback on are:

  • Shape of the API for expressing migrations. The API for migrations isn’t complete yet but Alpha 2 contains a large part of what we expect the final API to look like. We’d love your feedback on whether we are heading down the right path.
  • Will you use the automatic migrations functionality? We support a purely imperative workflow where all changes are explicitly expressed in code. A lot of folks have told us that is how they want to work. We want to know if we should continue to invest in the option of having sections of the migrations process handled automatically.

 

Getting Started

The Code First Migrations Alpha 2 Walkthrough gives an overview of migrations and how to it for development.

Code First Migrations Alpha 2 is available via NuGet as the EntityFramework.Migrations package.

 

Known Issues & Limitations

We really wanted to get your feedback on these design changes so Alpha 2 hasn’t been polished and isn’t a complete set of the features we intend to ship.

Some known issues, limitations and ‘yet to be implemented’ features include:

  • You must start using migrations targeting an empty database that contains no tables or targeting a database that does not yet exist. Code First Migrations assumes that it is starting against an empty database. If you target a database that already contains some/all of the tables for your model then you will get an error when migrations tries to recreate the same tables. We are currently working on a boot strapping feature that will allow you to start using migrations against an existing schema.
  • VB.Net is not yet supported. Migrations can currently only be scaffolded in C#, we are adding VB.Net code generation at the moment and will release another Alpha shortly that includes VB.Net support. You can, however, use a C# project to work with migrations that reference a domain model and context that are defined in a separate VB.Net project(s).
  • There is an issue with using Code First Migrations in a team environment that we are currently working through. Code First Migrations generates some additional metadata alongside each migration that captures the source and target model for the migration. The metadata is used to replicate any automatic migrations between each code-based migration. If the source model of a migration matches the target model of the previous migration then the automatic pipeline is skipped. The issue arises when two developers add migrations locally and then check-in. Because the metadata of their migrations are captured during scaffolding they don’t reflect the model changes made by the other developer, even if the second developer to check-in sync’s before committing their changes. This can cause the automatic pipeline to kick in when the migrations are run. We realize this is the key team development scenario and are working to resolve it at the moment.
  • No outside-of-Visual-Studio experience. Alpha 2 only includes the Visual Studio integrated experience. We also plan to deliver a command line tool and an MSDeploy provider for Code First Migrations.
  • Downgrade is currently not supported. When generating migrations you will notice that the Down method is empty, we will support down migration soon.
  • Migrate to a specific version is not supported. You can currently only migrate to the latest version, we will support migrations up/down to any version soon.

 

Prerequisites & Incompatibilities

Migrations is dependent on EF 4.1 Update 1, this updated release of EF 4.1 will be automatically installed when you install the EntityFramework.Migrations package.

Important: If you have previously run the EF 4.1 stand alone installer you will need to upgrade or remove the installation before using migrations. This is required because the installer adds the EF 4.1 assembly to the Global Assembly Cache (GAC) causing the original RTM version to be used at runtime rather than Update 1.

This release is incompatible with “Microsoft Data Services, Entity Framework, and SQL Server Tools for Data Framework June 2011 CTP”.

 

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
    September 07, 2011
    I'd like to see a feature in it which would allow creating skip/differences rules. For example having an extra column in the database and not having the same property in the Model, or having it with a different name, same for other DB types - keys, indexes etc. Without this feature migration will be a pain if model's generated db schema differs from the actual one by design.

  • Anonymous
    September 07, 2011
    @EF Team Excellent work! We will absolutely use the "Automatic Migration" functionality.  We feel a lot of light-weight development teams will--especially for small to medium sized projects. It was nice to see the walkthrough include examples of indexing fields.  With that said, we have some questions:

  1. Will DataAnnotation or the ModelBuilder Fluent API provide the ability to specify indexes? Example:     [Display(Name="My Property")]     [Index(Direction="Ascending")]     string MyProptery{ Get; Set; }     data.uservoice.com/.../2231176-indexattribute
  2. If many records have been created, how do we reindex?     a) By re-issuing the "CreateIndex("Blogs", new[] { "Name" });" command?     b) Could we run something like "Update-Database -reindex" just to reindex indexed fields?          i) Or better yet, specify which fields we would like to reindex.

  • Anonymous
    September 07, 2011
    The comment has been removed

  • Anonymous
    September 07, 2011
    I have to agree with Sean that it is very important that indexing can be expressed by data annotations attributes

  • Anonymous
    September 07, 2011
    this work with a non SQL express instance ? antoine magette

  • Anonymous
    September 07, 2011
    Do we have control over indexes, foreign key names ? Won't this migration tool overwrite my custom keys and indexes? (I don't want CodeFirst to generate those guys for me with ugly names not following naming convensions)

  • Anonymous
    September 07, 2011
    Consider the following scenario. Let's say I have db schema and entity framework model, but my db schema contains more stuff then entity framework model describes (more columns in tables, than in entity framework entities, extra indexes, keys etc.) At some point in feature I am making an update in the EF model and running Migration tool which in a more complex scenario may require drop-and-recreate some tables in my db. After those tables are dropped and recreated won't my custom extra columns, indexes, keys etc. be lost?

  • Anonymous
    September 08, 2011
    The comment has been removed

  • Anonymous
    September 08, 2011
    @Stefan Olson – Good feedback to hear, thank you! @Antoine – Yes, this will work with non-express instances (incl SQL Azure). @Konstantin Tarkus – You actually can’t specify names yet, but we could easily expose that. EF doesn’t care what the names are in the database, just that the constrains are there, so we could easily enable this at the migrations level. Regarding your second point, yes, if you do things to the schema outside of migrations then you need to make sure you take care of them by modifying the generated migrations. @Devi – I know I answered this on another post, but just replying for the benefit of other folks reading this. We’ve posted an updated package that resolves this issue. See the note we’ve added at the top of this post.

  • Anonymous
    September 08, 2011
    "if you do things to the schema outside of migrations then you need to make sure you take care of them by modifying the generated migrations" Modifing the generated migrations each time I use this tool? That's not an option, too much work to do if I gonna use migration tool often and also with big databases there will be too much things to modify in the generated migrations file. That's why I was talking about "skip rules" in the previous comment.

  • Anonymous
    September 09, 2011
    To my mind fully automatic migrations are redundant. These migrations concern data in most of cases. It's not a good idea to make those migrations blindly. Please provide good examples of data migrations in your next preview articles.

  • Anonymous
    September 12, 2011
    @Konstantin Tarkus - You wouldn't need to modify the migration every time. We scaffold changes by comparing the current model to the model last time you created a migration. So if you add an index, view, column, etc. in the database then we aren't going to try and remove it every time you generate. Say you add a view though and then change the table name that the view relies on, you would need to add logic to the generated migration to take care of fixing up the view. I'd recommend using the Alpha and letting us know if there are particular scenarios that are not working for you. @Alexey Bogdanov - Are there particular data migration scenarios that you are interested in?

  • Anonymous
    September 12, 2011
    I am trying to get this to work and keeping getting the following error: The type initializer for 'System.Data.Entity.Migrations.DbMigrator' threw an exception. Any ideas?

  • Anonymous
    September 12, 2011
    @Sam Striano - For anyone else hitting this issue, the related forum thread is: social.msdn.microsoft.com/.../7fab9bf4-c453-4ee5-a132-7c2c408f7166

  • Anonymous
    September 13, 2011
    @Sam Striano - We have released an updated package with a bug fix for this issue (see the note at the top of this post).

  • Anonymous
    September 13, 2011
    Hi Rowan,

  • Please do keep automatic migrations (if it can be generated automagically, no reason it shouldn't be possible to update it automagically).  I like having the control when I need it and the automatic pilot button when I don't (like during development).
  • Data migration would be gravy but I consider that to be a pretty orthogonal concern to schema sync.
  • I'll throw in a +1 for the indexing options being consistently available on both sides of the convention/configuration boundary.
  • I realize this isn't a migration-specific bit of feedback, but in the spirit of the earlier poster's comment about default naming conventions...I'd love it if there were a way to remove the underscores it puts in auto-generated foreign key names without having to resort to the Fluent API (like an analog to Conventions.Remove<PluralizingTableNameConvention> that eliminates the underscore naming delimiter).  Sorry for the non-sequitur, but hey, I'm on a roll... Thanks for the great work you and your team are doing!
  • Anonymous
    September 14, 2011
    Great work..!! Is there any way that we could seed the database with data on the first migration, as we are to start with a non-existing database?