.NET 5.0 - Custom Version Table Metadata not working

[jzabroski]

It seems the resources here are not 100% correct. at least with net5

here is my complete working example

internal class VersionTableAccessor : IVersionTableMetaDataAccessor
{
    public IVersionTableMetaData VersionTableMetaData { get; } = new VersionTable();
}

internal class VersionTable : IVersionTableMetaData
{
    public object ApplicationContext { get; set; }
    public string AppliedOnColumnName => "APPLIED_ON";
    public string ColumnName => "VERSION";
    public string DescriptionColumnName => "MIGRATION";
    public bool OwnsSchema => true;
    public string SchemaName => "MIG";
    public string TableName => "HISTORY";
    public string UniqueIndexName => "IX_HISTORY_VERSION";
}

internal static class MigrationExtensions
{
    public static IMigrationRunnerBuilder WithVersionTable<T>(
        this IMigrationRunnerBuilder builder) 
        where T: class, IVersionTableMetaDataAccessor
    {
        builder.Services.AddScoped<IVersionTableMetaDataAccessor, T>();
        return builder;
    }
}

and

services.AddFluentMigratorCore()
        .ConfigureRunner(o => o.AddSqlServer()
                               .WithGlobalConnectionString("...")
                               .WithVersionTable<VersionTableAccessor>()
                               .ScanIn(typeof(Startup).Assembly).For.Migrations());

Originally posted by @boop5 in #1429 (comment)

[jzabroski]

@boop5 I moved #1429 to a GitHub Discussion and moved your question into this new Issue. Can you please elaborate on what problem you are running into? Saying something is "not working" is not very descriptive.

[fubar-coder]

@jzabroski @boop5 I guess that the problem is, that registering an IVersionTableMetaDataAccessor is required, because a registration of a IVersionTableMetaData instance might not be sufficient? However, the registration of a PassThroughVersionTableMetaDataAccessor instance should work too.

[jzabroski]

I don't know. To me, the behavior @boop5 is describing can only happen if you're using attributes and the attributes are mismatched.

e.g.,

  // this attribute could (fail to) bind if your 
  // FluentMigrator.dll dependency in your migration assembly doesn't match FluentMigrator.DotNet.Cli.dll 's FluentMigrator.dll dependency
  [VersionTableMetaData] 
  public class VersionTable : IVersionTableMetaData {
    public object ApplicationContext { get; set; }
    public string AppliedOnColumnName => "APPLIED_ON";
    public string ColumnName => "VERSION";
    public string DescriptionColumnName => "MIGRATION";
    public bool OwnsSchema => true;
    public string SchemaName => "MIG";
    public string TableName => "HISTORY";
    public string UniqueIndexName => "IX_HISTORY_VERSION";
  }

For this reason, I wanted to use MetadataLoadContext to validate the above dependency match. I think --allowDirtyAssemblies would also resolve this issue, but I think checking the version numbers on the two assemblies for this specific scenario is a lot cleaner.

I'll try to run the sample in a net50 project and see what happens.