Describe the bug
I had to use a custom version info table, so I registered it like this:

services.AddScoped<IVersionTableMetaData, CustomVersionTableMetaData>();

Previously it worked, but after I refactored my code (just moving registrations around) it broke.

The reason:
Previously, I first called AddFluentMigratorCore(...) and after that services.AddScoped<IVersionTableMetaData, CustomVersionTableMetaData>(). While refactoring the order changed.

To Reproduce
This version works (pseudo code):

services.AddScoped<IVersionTableMetaData, CustomVersionTableMetaData>();
services.AddFluentMigratorCore(..);

this doesn't:

services.AddFluentMigratorCore(..);
services.AddScoped<IVersionTableMetaData, CustomVersionTableMetaData>();

Expected behavior
The order of the registration should not cause the custom migration to be ignored/missed.
I consider this a very suptle but hard to spot and therefore serious bug, despite the workarounds being pretty straight forward.

Investigation
Usually, in a library this is caused by using services.AddScoped<...>() instead of services.TryAddScoped<...>() which overrides user registrations, but I couldn't find something like that.
As I did not register a AssemblyVersionTableMetaDataSourceItem with ScanIn(...).For.VersionTableMetaData(), this returns null for VersionTableMetaData property (debugged this).

Workarounds

• Call AddScoped<IVersionTableMetaData, CustomVersionTableMetaData>(); after AddFluentMigratorCore(...)
• Use ScanIn(...).For.VersionTableMetaData()
• Use WithVersionTable(new CustomVersionTableMetaData())

Information (please complete the following information):

• OS: Windows 10
• Platform .NET 8
• FluentMigrator version 5.2.0
• FluentMigrator runner "in-process runner"
• Database Management System Oracle
• Database Management System Version "Oracle 19c