12 replies »

  1. Hi Arthur,

    I am using EF 4.1, and I exclusively use the “model designer” to make changes to my database and entities. For example, if my Users table needs a new column “OwnsAFerrari” of type boolean, I will simply open up the model designer, and add that column, and right-click the designer and select “Generate database from model”. To upgrade my existing live database, I run the create scripts from version 1.0 on a local SQL server, run the create scripts for 2.0 (featuring the new Users column), run a schema compare from VS between the two, and export the output to a SQL editor. I then run this script against my live database. This is my entire database development process. Will I be affected by the EdmMetadata not being supported anymore?

    Thank you very much.
    Matt McLoughlin

    • Matt: It should not affect you. EdmMetadata is only used for Code First flows. Any flow that uses an EDMX, including the Model First flow that you desribe, should not be affected.


      • Hi Arthur,
        And in the Code First flow (which is my case) how do I migrate an EF4.1” EdmMetadata” based Production DB to a “_MigrationHistory” based one? I couldn’t find any clue about that.
        Can I:
        1. Create a new DB using EF5 Code first on my original data classes.
        2. Make _MigrationHistory table non system
        3. Generate creation scripts (structure & data)
        4. Play the scripts against my production BDs
        5. drop EdmMetadata table
        This implies that EF5 will create the same DB structure as EF4.1 (except Edm and history stuff) and also that _MigrationHistory doesn’t contain some “context” dependent information.
        Or is there a trivial answer.
        I would like to migrate to EF5 but don’t dare to.
        Thanks in advance.

  2. Hi Arthur,
    I found that because new “__MigrationHistory” table is System now, script for it is not included into Web Deployment package, which is generated by Publish VS feature
    Because of that there is exception after publishing my web application, which states that database was not properly created.

    Are you or Web Deployment team going to fix it in some way and allow “__MigrationHistory” to be picked up by Web Deploy?


    • @Andrey I’ve been following up with various people on this issue. The Web Deploy team are currently working on adding support for Migrations so that this will just work. For now you will need to either do something to make the table not a system table. (Migrations doesn’t care whether the table is marked as a system table or not.)

      One way to make sure that __MigrationHistory is not a system table is to wrap the SQL generator. This only works if you do it before the database is created and then use Migrations to explicitly create the database with a call to update-database. Create a class that derives from SqlServerMigrationSqlGenerator and override GenerateMakeSystemTable so that it does nothing:

      public class NonSystemTableSqlServerMigrationSqlGenerator : SqlServerMigrationSqlGenerator
      protected override void GenerateMakeSystemTable(System.Data.Entity.Migrations.Model.CreateTableOperation createTableOperation)

      Now set an instance of this new class in your Migrations Configuration:

      public Configuration()
      AutomaticMigrationsEnabled = false;
      SetSqlGenerator("System.Data.SqlClient", new NonSystemTableSqlServerMigrationSqlGenerator());

      If you have an existing __MigrationHistory table and want to make it non-system then you’ll have to do some work in SQL. This worked for me, but my SQL isn’t great so it may not be the best it can be:

      SELECT *
      INTO [TempMigrationHistory]
      FROM [__MigrationHistory]

      DROP TABLE [__MigrationHistory]

      EXEC sp_rename 'TempMigrationHistory', '__MigrationHistory'

      Hope this helps.


      • @Arthur, thanks for your reply. If Web Deploy team is going to take care about Migrations, its fine for me. If I can use these workarounds, it’s also fine for me :)

  3. Is there a way to disable this functionality? Im using plain CLR objects and EF5-beta1 and .NET 4. Every time the app starts up these queries are executed. The solution for EF4x does not work; which was to remove the IncludeMetadataConvention convention.

    [GroupBy1].[A1] AS [C1]
    COUNT(1) AS [A1]
    FROM [dbo].[__MigrationHistory] AS [Extent1]
    ) AS [GroupBy1]

    SELECT TOP (1)
    [Extent1].[Id] AS [Id],
    [Extent1].[ModelHash] AS [ModelHash]
    FROM [dbo].[EdmMetadata] AS [Extent1]
    ORDER BY [Extent1].[Id] DESC

    • @Craig If you don’t want any database initialization to happen, then disable the database initialer for your context with Database.SetInitializer(null) or with an appropriate entry in the config file.

      • Thanks! It took one more little tweak. It’s a generic for the DbContext class which I put in the static constructor of my extended DbContext class.

        public class TagsDataContext : DbContext {

        static TagsDataContext()

  4. The company I am working for updaded to entity framework 4.3.
    Now a warnning is being produced stating:
    ‘System.Data.Entity.Infrastructure.IncludeMetadataConvention’ is obsolete when

    This occurs in the overriding of the OnModelCreating method when the following line is called:

    I beleive the Remove()removes the EdmMetadata table.

    My question is can I just remove the line of code modelBuilder.Conventions.Remove
    and will the code work identically the same before the upgrade to entity framework 4.3 was perfromed????????????

    The EdmModelDiffer class is an internal class and I can get a reference to it so I can not replace IncludeMetadatConvention with EdmModelDiffer in the code.

    I just was handed this project and my knowledge of the inner working of Entity Framework is nill.
    It appears that EdmMetadata has been replaced with an internal: called

    I have searched alot of website on this issue and most of the websites go off on theory and tangents and ef framework this and that, when I need to know is how to replace the line of code:
    so the code still works the same as before..

    • @steve fred IncludeMetadataConvention is no longer used. In other words removing it is now a no-op because it was never added in the first place. So, yes, you should just delete that line of code. However, I’m curious as to why you are updating to 4.3 when EF5 has been out for quite some time. Why not update to EF5?