EF CodeFirst THT - Column 'Id' specified as part of this MSL does not exist in MetaDataWorkspace

Question

I'm using a 'table-per-type' hierarchy in my code-first project (EF5). My derived classes override the default primary-key name to clearly identify this relationship from a database point of view, like so:

/* change primary keys to Chair.ProductId and Table.ProductId */
modelBuilder.Entity<Chair>()
    .Property(x => x.Id)
    .HasColumnName("ProductId");

modelBuilder.Entity<Table>()
    .Property(x => x.Id)
    .HasColumnName("ProductId");

Using the following classes as example:

[Table("Product")]
public class Product
{
   public int Id {get; set;}

   /* generic product properties */
}

[Table("Chair")]
public class Chair : Product
{
     /* specific chair properties */
}

[Table("Table")]
public class Table : Product
{
     public virtual ICollection<Chair> Chairs {get; set;}

     /* specific table properties */
}

Which causes the following error on property Table.Chairs: Column 'Id' specified as part of this MSL does not exist in MetaDataWorkspace.

Which I kinda understand as EF probably didn't see that the PK of Chair Product was changed.. (and still assumes it's called 'Id') But I can't figure out how I instruct EF to use the alternate key.

Thx,

PS. Yes I know, if I don't change the names of the PK's it works... but can it be done using the EF Fluent API?

Answer 1

This is some bug of EDMX model generator in Visual Studio.

To solve this do:

• remove particular table from EF.
• save EF and restart Visual Studio
• add particular table to the model again
• save and compile

I have Visual Studio 2015 udpate 3

Answer 2

I recently was searching for a fix to a similar error, but designing things Database first. I post my finding here because this is where my search kept landing me.

I had multiple similar errors, on build. What they really meant is that my Model never built successfully.

I was able to fix the issue by removing and re-adding some table valued functions that had been modified in the database recently.

Most of the errors and details I could find where actually just red-herrings; other than the concept that the model didn't build successfully; and having knowledge of things someone else was changing in the database helped.