Version 3.x should support .NET Core LTS version(s)

We should support .netcoreapp3.1 and .netcoreapp2.1 The reason is that .netcoreapp3.0 and .netcoreapp2.2 is EOL (End Of Life), whereas .netcoreapp3.1 and .netcoreapp2.1 are LTS (Long Term Servicing).

This is supported in Version 4.x (develop branch), but we will likely be servicing Version 3.x for awhile, so it makes sense to add support for .NET Core 3.0

Process

1. Gather all FluentMigrator netstandard2.0 PackageReference dependencies
2. Gather all /lib/ folder dependencies and see if they now exist as Nuget Packages.
   • If they do, move to the Nuget Package for netstandard2.1
   • Delay moving for net461 and netstandard2.0
     • Reason: We don’t have integration tests that perform end-to-end verification yet - we don’t want a bad release, so let’s be conservative here
3. For Microsoft.Extensions.* packages, in order to allow end users to load FluentMigrator from ASP.NET Core 2.x:
   • netstandard2.0 should use 2.2.0 dependencies (latest .NET Core 2.x dependencies)
   • netstandard2.1 should use 3.1.3 dependencies (latest .NET Core 3.y dependencies)

Out of scope: In the future, we should consider targeting netstandard TFM family that is parallel support to the underlying target frameworks. In practice, this means adding “netstandard2.1” to the list of TargetFrameworks

Lessons Learned

1. Next time, upgrade dependencies first so that the latest versions of each dependency work against currently supported TargetFrameworks.

2. Be careful of TargetFramework vs. TargetFrameworks.

3. .NET Core 3.0 introduced [NotNull] attribute. If you reference JetBrains.Annotations and System.Diagnostics.CodeAnalysis in the same file, you’ll get a compiler error. The fix is to use the NETSTANDARD2_1 pre-defined symbol (see also Target Frameworks in SDK-style projects).

4. FluentMigrator.DotNet.Cli depended on an Obsolete extension method ILoggerFactory.AddDebug, which is now removed in .NET Core 3.x. There is a guide on Microsoft Docs for Migrate from Microsoft.Extensions.Logging 2.1 to 2.2 or 3.0:

       private static void Configure(ILoggerFactory loggerFactory)
       {
   #if NETSTANDARD2_0
           loggerFactory
               .AddDebug(LogLevel.Trace);
   #endif
   #if NETSTANDARD2_1
           LoggerFactory.Create(builder => builder.AddDebug(LogLevel.Trace));
   #endif
       }
   

5. Autofac-specific issues

   1. These are limited to the FluentMigrator.Tests project
   2. Autofac 4.9.4 is the last release that supports legacy .NET Framework. net45 TFM was dropped in 5.0.0.
   3. Autofac.Extensions.DependencyInjection 4.4.0 is the last release that supports netstandard1.0 TFM, and therefore is the last release that supports net461 TFM.

6. McMaster.Extensions.CommandLineUtils now 2.6.0

   1. Package has breaking changes from 2.6.0 to 3.0.0. As a result, we’re using 2.6.0 as part of this issue. Upgrading to 3.0.0 is out-of-scope. Fortunately, 2.6.0 marks obsolete interfaces, so we can fix them soon after FluentMigrator 3.3.0 release.

7. FSharp.Core now 4.7.1

8. Microsoft.Build.Utilities.Core

   1. Stopped supporting net461 in major version 15. Last release to nuget 15.9.20.
   2. However, net461 targets major version 14. No idea why?

9. Sap.Data.SQLAnywhere doesn’t exist for .NET Core.

   1. As a result, FluentMigrator.Tests project tests for SqlAnywhere will only run on net461.
   2. I’ve never seen a support request for SqlAnywhere in the last 2+ years, so it’s FluentMigrator user base is likely small, but @eloekset might be one of them!

10. Microsoft Jet (via ADOX.dll) doesn’t exist for .NET Core.

    1. We already had a check in FluentMigrator.Tests.csproj if the build was being built using MSBuild Core, but never had a check to guard against running tests on .NET Core. https://github.com/fluentmigrator/fluentmigrator/blob/84274296032eb0da8ad4664ef2796e9ad480dbfc/test/FluentMigrator.Tests/FluentMigrator.Tests.csproj#L79
    2. ~As a result, JetTestTable.cs and other integration tests for Jet are disabled on .netstandard2.0 and .netstandard2.1 TFMs for xUnit test runner.~ I was wrong about this.
    3. Type.GetTypeFromProgID("ADOX.Catalog"); might be footgun code.

11. Wrapped ConnectionStringManagerTests.cs in a #if NET461 check

12. FluentMigratorConsoleTests.cs should be moved to its own Test project to avoid #if NET461

13. .NET Core 3.0 does not support AddJsonFile

    1. Add nuget package Microsoft.Extensions.Configuration.Json

14. Minor refactoring work

    1. Lifted out package tags from individual csproj files and into Global.props
    2. Lifted out assembly signing logic from individual csproj files and into new Package.AssemblySigning.props file. This will make it easier to remove assembly signing in the future (cf #1050 )
    3. Installed Paul Harrington’s EditorGuidelines Visual Studio Extension and formatted <Description> field so it doesn’t run on forever without a line break.
    4. Moved <Import ...> MSBuild directives to the top of each csproj file, so that it’s clear what global variables exist from contexts outside the file itself.
       1. This could in theory cause an issue, so I checked that there are no variable name collisions that could cause replacing values.

TODO Items

• Investigate why Microsoft.Build.Utilities.Core for net461 has Major Version 14.
• Investigate why project references like FluentMigrator.Runner.SqlAnywhere needed to add netstandard2.1 to the TFM list in order for FluentMigrator.Tests to be happy.
• In files where JetBrains.Annotation.NotNullAttribute is still used in .netstandard2.1 target, should we update to explicitly use System.Diagnostics.CodeAnalysis.NotNullAttribute?
• Finish cleaning up <Description> field in .csproj
• Revisit Microsoft Jet assumptions as OleDebConnection should work on .NET Core?
• ConnectionStringManager.cs and NetConfigManager.cs is using/was using #if NETFRAMEWORK - should it use #if NET461 instead?
• Ask @fubar-coder why some tests use the SqlAnywhere .Password("pass") extension
• Update all the PackageReference(s) to use Nuget version ranges so that dependabot correctly auto-bumps dependencies.

[jzabroski]

We will get there. I think once proper 3.1 support is implemented, adding features is gonna be a relative breeze. I have so many cool, innovative ideas in this space that nobody has even thought of yet. I haven’t even written design docs for the really cool ideas because I don’t want anyone stealing my original thoughts and then being like, “FluentMigrator doesn’t do this” (as is common in open source software). It’s going to really advance state of the art in “DbOps”.

[jzabroski]

I want to finish it by the end of the summer. I maintain two projects, this and RazorLight. This PR is rather enormous. To complicate things, I was falling behind accepting PRs to FluentMigrator, so I chose to accept those PRs and do small releases. So now I have to merge those PRs to my jzabroski/FluentMigrator branch, which is extra work. It’s a fine balance between moving features forward and keeping project interest up and optimizing for what’s easiest / least amount of work for me to do. In this case, I chose to do more work and accept more PRs and have to do more merging.

I’ve also taken some time to write up some design docs on where I want the project to go long-term, as I didn’t write the current runner architecture. See https://github.com/fluentmigrator/fluentmigrator/discussions/1288

Note, this is not my full time job and I don’t get paid for it, so I do all this free work “on the side” as time permits with family and my other business objectives (I run my own software company).