@jzabroski
I added the TryAdd registrations as discussed.

A few things about the changed registrations

• I turned all library service registrations in AddFluentMigratorCore into TryAdd variants
  • Even TryAddSingleton
  • All except those which are resolved as IEnumerable<T> as this implys that having a list of services is supported by FluentMigrator (eg. IAssemblySource)
  • Not only interface types but also concrete types (eg. AssemblyLoaderFactory)
• CreateServices is internal, obsolete and as far as I see only used in test code paths, so I left it as-is
• ConfigureRunner was untouched as it intentionally registers the service
• I don't think other registrations need the TryAdd change, as they are "on-purpose" registrations and not "general" registrations as in AddFluentMigratorCore.

Some questions:

• Should non-interface types be registered with TryAdd (as I already did)?
• I kept the new-line formatting but on some lines it's kinda weird to have services. on a separate line (and sometimes a comment in-between) - should the services. be placed on the same line as the next TryAdd?

5 tests are failing, but these are already failing before my changes so this should be fine.

which 5 tests are failing? none failing locally for me or azure dev ops pipeline? can you open an issue with the failing stack trace/nunit error

Just a quick update
Those are culture dependent errors. "," instead of "." for numbers, error messages in my locale (de) instead of the english ones.

I think the FluentMigrator tests should set the culture to en-US before executing any tests to be stable for all contributors.
The 2(?) error message tests should be tested with a known culture (en), but the other tests are in the generated SQL which seems to be problematic after thinking about that more.

I create a new issue after work.

Thanks. I am about to head on paternity leave so I have been heads down writing documentation on various responsibilities I have at work. I imagine I will merge this after looking through it more carefully.

I've finally fixed our ci/cd failing. (turns out, I had to add new pipelines and delete the old ones after renaming the master branch to main). This was slowing me down with evaluating PRs as i couldn't even immediately see build pass/fail.

No stress. This is an important code path, so take your time.

On another note:
I believe build pipelines were designed to frustrate developers 😩

@warappa Sorry, I completely lost track of this PR and my eyes got top-heavy reading only the more recent PRs.

No problem :) Just ping me if I can help.

It's been merged. I think you mentioned wanting to do a PR for ValidateOnBuild?

@jzabroski Yes, I started with it but it's not straight forward. But I will try to make it into a PR.

@warappa It looks like the PR has two failing tests. There is also a typo "No migration generator registerd." but that may not be coming from your code. Is it possible I messed up the merge? https://github.com/fluentmigrator/fluentmigrator/pull/1842/checks?check_run_id=31363477043

FluentMigrator.Tests.IssueTests.GH1836.Fixture.VersionLoaderShouldUseCustomVersionTableMetaDataImplementationRegisteredAfterFluentMigrator

System.InvalidOperationException : No migration generator registerd.

FluentMigrator.Tests.IssueTests.GH1836.Fixture.VersionLoaderShouldUseCustomVersionTableMetaDataImplementationRegisteredBeforeFluentMigrator

System.InvalidOperationException : No migration generator registerd.

I'll take a look.

The typo is here:

I will fix it

I fixed the tests by configuring a runner. I took SQLite, but that's just a random choice, because it's only for registering any migration generator.

I realized that I just test it with 1 service (IVersionTableMetaData) - I hope this is enough for you.

yes, progress is incemental.