When using a custom IVersionTableMetaData implementation with both CreateWithPrimaryKey = true and UniqueIndexName specified, FluentMigrator would attempt to create two clustered indexes on the same table, causing SQL Server to fail with:

Cannot create more than one clustered index on table 'dbo.IdentityVersionInfo'. 
Drop the existing clustered index 'PK_IdentityVersionInfo' before creating another.

This occurred because:

1. VersionMigration.Up() creates a clustered primary key when CreateWithPrimaryKey = true
2. VersionUniqueMigration.Up() unconditionally creates a unique clustered index using UniqueIndexName

The fix modifies VersionUniqueMigration.Up() to create different index types based on the CreateWithPrimaryKey setting:

• When CreateWithPrimaryKey = false: Creates a clustered unique index
• When CreateWithPrimaryKey = true: Creates a non-clustered unique index

This approach avoids the clustered index conflict while still maintaining the UniqueIndexName functionality in both scenarios.

Example scenario that now works:

[VersionTableMetaData]
public class IdentityVersionTableMetaData : IVersionTableMetaData
{
    public string TableName => "IdentityVersionInfo";
    public string ColumnName => "Version";
    public string UniqueIndexName => "UC_Version";
    public bool CreateWithPrimaryKey => true; // Creates non-clustered unique index
    // ... other properties
}

The change maintains backward compatibility:

• When CreateWithPrimaryKey = false and UniqueIndexName is set → creates unique clustered index (existing behavior)
• When CreateWithPrimaryKey = true and UniqueIndexName is set → creates non-clustered unique index (new behavior)
• When only one option is used → works as before

Fixes #2051.

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.