I just found a bug in the new version of SchemaExplorer (3.2.4.797) at MemberColumnSchemaCollection.Contains(CoolumnSchema value) method.

How to reproduce:

DB:

Code:

SqlSchemaProvider p = new SqlSchemaProvider();
DatabaseSchema db = new DatabaseSchema(p, “your-connection-string”);
TableSchema table = db.Tables[“E_AWBs”];

// Returns true
bool isFound = Test(table.Columns[“FlightNO”]);

// Returns false – in the previous version it worked just fine
bool isFoundTPK = Test(table.PrimaryKey.MemberColumns[“FlightNO”]);

public static bool Test(ColumnSchema column)
{
   TableSchema tbl = column.Table;
   foreach (TableKeySchema key in tbl.ForeignKeys)
   {
      if (key.ForeignKeyMemberColumns.Contains(column))
         return true;
   }

   return false;
}

My opinion:

I’m not sure how the code is written (the reflector shows me the message “This item appears to be obfuscated and can not be translated“) but my guess is that table.PrimaryKey.Columns return a shallow copy of table.Columns and therefore the Contains method don’t work properly.

Workaround:

1. The quick solution is quite dirty but is simple and match the same solution I did before: 
   
   

   column = column.Table.Columns[column.Name]; // Change the pointer to address the real column

   
   
2.  The other solution is to foreach the key.ForeignKeyMemberColumns and match column name and table name as needed.

I’ve just upgraded my CodeSmith version to 3.2; It went pretty well just until I’ve opened the CodeSmith Studio and tried to compile my template. I got a strange NullReferenceException in the CodeSmith.Engine.CodeTemplate constructor.
I thought about 2 reasons which can cause this behavior:

1. Maybe the CodeSmith Studio works with an old version of one of the dlls, for some unknown reason (unlikely).
   
2. I’m using a compiled dll as my CodeTemplate base class, maybe I need to recompile it again and then try to compile the template (more likely).

So I compiled my DLL (and did a quick restart to my computer, just to be safe) – now it works…

This post is mostly a self reminder but it may come useful if you’re using CodeSmith as well.
It is possible to check if a (schema)column is an identity field via ExtendedProperties property of the SchemaObjectBase class:

// Only for Sql Server
private bool IsIdentityColumn(ColumnSchema column)
{
   return (bool)column.ExtendedProperties[“CS_IsIdentity”].Value;
}

There is one exception though and that’s if you’re sending the column object through the TableSchema.ForeignKey[index].ForeignKeyMemberColumns or TableSchema.ForeignKeys[index].PrimaryKeyMemberColumns, meaning:

for(int i=0; i<MySourceTable.ForeignKeys.Count; i++)
{
   // Same thing about MySourceTable.ForeignKeys[i].PrimaryKeyMemberColumns…
   for (int j=0; j<MySourceTable.ForeignKeys[i].ForeignKeyMemberColumns.Count; j++)
   {
      if (IsIdentityColumn(MySourceTable.ForeignKeys[i].ForeignKeyMemberColumns[j])) // <– Exception Here.
      {
         //do some code         
      }
   }   
}

The extended properties will NOT hold the key “CS_IsIdentity” and IsIdentityColumn will throw an exception (null reference). I’m still not sure if this is by design or not, so I’ll try to fish it out on from the net and update the post later on. 

The solution is simply working a little harder via TableSchema.Keys and than verify the type of the key (by PrimaryKeyTable and ForeignKeyTable properties).

update:
This is quite a dirty hack, but it works and I’m loving it (I don’t have to change a lot of code in a lot of different places) !  
I refactor the mehotd IsIdentityColumn so it will do the trick: