title: LINQ to SQL entity column name attribute ignored with guid primary key
body: <p>I was working with a simple entity class with LINQ to SQL (SQL Server 2005 SP3 x64). </p>
  
  <pre><code>[Table( Name="TBL_REGISTRATION" )]
  public sealed class Registration : IDataErrorInfo
  {
      [Column( Name = "TBL_REGISTRATION_PK", IsPrimaryKey = true, IsDbGenerated = true, AutoSync = AutoSync.OnInsert )]
      public Guid RegistrationID { get; private set; }
      /* other properties ommited for brevity */
  }
  </code></pre>
  
  <p>There are only two somewhat interesting things here:</p>
  
  <ol>
  <li>The class and property names aren't the same as the table and column names</li>
  <li>The primary key is a Guid (uniqueidentifier)</li>
  </ol>
  
  <p>Here's what the table looks like:</p>
  
  <pre><code> create table dbo.TBL_REGISTRATION
      (
      TBL_REGISTRATION_PK uniqueidentifier primary key clustered
          rowguidcol
          default newid(),
      /* other columns ommited for brevity */ 
      )
  </code></pre>
  
  <p>When I attach this entity to my table and submit changes on my DataContext, the LINQ stack throws back a SqlException:</p>
  
  <p>SqlException (0x80131904): Invalid column name 'RegistrationID'</p>
  
  <p>LINQ seems to be ignoring the Column( Name = "TBL_REGISTRATION_PK" ) attribute on my RegistrationID property. I spent a while futzing with different attribute decorations trying to get it to work. In the end I settled on a private TBL_REGISTRATION_PK property to wrap my RegistrationID property to make LINQ happy.</p>
  
  <pre><code>[Table( Name="TBL_REGISTRATION" )]
  public sealed class Registration : IDataErrorInfo
  {
          public Guid RegistrationID { get; private set; }
          [Column( IsPrimaryKey = true, IsDbGenerated = true, AutoSync = AutoSync.OnInsert )]
          private Guid TBL_REGISTRATION_PK { get { return RegistrationID; } set { RegistrationID = value; } }
      /* other properties ommited for brevity */
  }
  </code></pre>
  
  <p>This works.</p>
  
  <p>Why didn't it work the first way? Am I doing something wrong here or is this a LINQ defect?</p>