This item was migrated from the DevDiv work item tracking system [ID=32229].
This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.
Comments: Fixed in f986cb32d0a3 StayInLinePlease (Make newsequentialid() default for store-generated GUID columns) This change makes newsequentialid() instead of newid() the default for SQL Server store-generated GUID columns created with Migrations except for SQL Azure where newsequentialid() is not supported. A new provider manifest token for Azure was required to allow Migrations to know when Azure is being targeted rather than on-premises SQL Server. Also included here is the fix for CodePlex 202 where SqlProviderServices was assuming that the StoreItemCollection contains a SqlProviderManifest. This is fixed by asking the database for the version during the create call rather than getting the version from the item collection. It is possible that this could result in different behavior if the item collection was ceated for a database version different than the one actually being used, but if this does happen the behavior is more likely to be correct (i.e. not throw/work well) now than it was before.
This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.
Comments: Fixed in f986cb32d0a3 StayInLinePlease (Make newsequentialid() default for store-generated GUID columns) This change makes newsequentialid() instead of newid() the default for SQL Server store-generated GUID columns created with Migrations except for SQL Azure where newsequentialid() is not supported. A new provider manifest token for Azure was required to allow Migrations to know when Azure is being targeted rather than on-premises SQL Server. Also included here is the fix for CodePlex 202 where SqlProviderServices was assuming that the StoreItemCollection contains a SqlProviderManifest. This is fixed by asking the database for the version during the create call rather than getting the version from the item collection. It is possible that this could result in different behavior if the item collection was ceated for a database version different than the one actually being used, but if this does happen the behavior is more likely to be correct (i.e. not throw/work well) now than it was before.