Not able to generate SQL with dotnet-fm CLI

Describe the bug I’m trying to execute SQL that FM can then use to make a migration script. To do that I’ve included System.Data.SqlClient through nuget to grab data from the database. Upon running the CLI I’m receiving this error that says it can’t find the System.Data.SqlClient.

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Data.SqlClient, Version=4.6.1.2, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
   at FluentMigratorWithExternalDlls.TestMigration.Up()
   at FluentMigrator.MigrationBase.GetUpExpressions(IMigrationContext context) in D:\a\1\s\src\FluentMigrator\MigrationBase.cs:line 83
   at FluentMigrator.Runner.MigrationRunner.ExecuteMigration(IMigration migration, Action`2 getExpressions) in D:\a\1\s\src\FluentMigrator.Runner\MigrationRunner.cs:line 837
   at FluentMigrator.Runner.MigrationRunner.ApplyMigrationUp(IMigrationInfo migrationInfo, Boolean useTransaction) in D:\a\1\s\src\FluentMigrator.Runner\MigrationRunner.cs:line 607
   at FluentMigrator.Runner.MigrationRunner.MigrateUp(Int64 targetVersion, Boolean useAutomaticTransactionManagement) in D:\a\1\s\src\FluentMigrator.Runner\MigrationRunner.cs:line 427
   at FluentMigrator.Runner.Initialization.TaskExecutor.Execute() in D:\a\1\s\src\FluentMigrator.Runner\Initialization\TaskExecutor.cs:line 165
   at FluentMigrator.DotNet.Cli.Commands.BaseCommand.ExecuteMigrations(MigratorOptions options, IConsole console) in D:\a\1\s\src\FluentMigrator.DotNet.Cli\Commands\BaseCommand.cs:line 32
   at FluentMigrator.DotNet.Cli.Commands.Migrate.OnExecute(IConsole console) in D:\a\1\s\src\FluentMigrator.DotNet.Cli\Commands\Migrate.cs:line 31
--- End of stack trace from previous location where exception was thrown ---
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.Invoke(MethodInfo method, Object instance, Object[] arguments)
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.OnExecute(ConventionContext context)
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.<>c__DisplayClass0_0.<<Apply>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.<>c__DisplayClass142_0.<OnExecute>b__0()
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.Execute[TApp](CommandLineContext context)
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.Execute[TApp](IConsole console, String[] args)
   at FluentMigrator.DotNet.Cli.Program.Main(String[] args) in D:\a\1\s\src\FluentMigrator.DotNet.Cli\Program.cs:line 35

To Reproduce https://github.com/wtilton/FluentMigratorWithExternalDllsBug Run dotnet-fm migrate -p SqlServer2016 --no-connection --preview -o -a bin\Debug\netcoreapp3.1\FluentMigratorWithExternalDlls.dll --start-version 0

Expected behavior A SQL script to be produced

Information (please complete the following information):

• OS: Windows 10
• Platform .NET Core 3.1
• FluentMigrator version 3.2.9
• FluentMigrator runner FluentMigrator.DotNet.Cli
• Database Management System All I’d think but SqlServer2016 is what I’m using
• Database Management System Version SQL Server 2016 Developer Edition

Additional context I’ve also tried to execute the CLI command in the publish directory after running dotnet publish with the same result.

[rballonline]

dotnet tool list -g got it.

fluentmigrator.dotnet.cli 3.2.9 dotnet-fm

[rballonline]

I use FluentMigrator almost daily in my consulting, so I think I benefit a lot from any improvements I put into it. In terms of fixing this issue, I will try to get to it soon. I’ve been thinking of just pushing #1178 over the goal line and dropping SAP SQL Anywhere support, as that is the main thing slowing me down, because they do not seem to be maintaining the library and providing a .NET Core library for it.

Then that makes sense then. I use it maybe 2-3 times a month. This month we’re just transferring all data to our new shiny DB.

If it was me, I would drop anything that doesn’t have .NET Core support and move on. Devs using that can use older versions I’d think. The more I think about it though, some sort of plug-in system would make sense to me.