Fluentmigrator: !!! Could not load file or assembly Error

[biju-ps]

I am trying use FM in my Dotnet core 2 project . I just created a test migration and used the following command.

C:\Users\xxxx.nuget\packages\fluentmigrator.console\2.0.5\tools\net40\x86\Migrate.exe -a {pathToMyDLL}\MyDll.dll -db Mysql5 -conn "Data Source={ip};Database={dbName};User Id={user};Password={pwd}" -profile "Debug"

and it showing the following error.. I missed something ?? .. Please help ..

!!! Could not load file or assembly 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

[fubar-coder]

I guess that you're using it on a .NET Standard library? This is a problem I have to evaluate myself.

In the meantime, you can try the following:

1. dotnet publish your project
2. Use the net452 version of the Migrate.exe tool
3. Run the Migrate.exe tool on the DLL in the published directory

If this doesn't work, you may try to use the .NET CLI tool:

1. dotnet publish your project
2. Add the FluentMigrator.DotNet.Cli package as tool to your project (<DotNetCliToolReference Include="FluentMigrator.DotNet.Cli" Version="2.0.5" />
3. dotnet restore
4. From your project directory (i.e. where your csproj is), Execute dotnet fm migrate with the appropriate options. You can use dotnet fm --help and dotnet fm migrate --help to see all options.

The solution will be better when the .NET Core 2.1 tooling with the global tools support is released and supported by us (see issue #857).

[biju-ps]

Hi fubar-coder,

Thanks for you support.
Tried with net452version and getting the same error.

Tried to add FluentMigrator.DotNet.Cli and the following error throw in package manager console

Package 'FluentMigrator.DotNet.Cli 2.0.6' has a package type 'DotnetCliTool' that is not supported by project

My project is a ClassLib project targeting Donet Core 2

[biju-ps]

I created a runner class as follows and call it from startup and its working fine
```
public static class MigratorRunner
{
public class MigrationOptions : IMigrationProcessorOptions
{
public bool PreviewOnly { get; set; }
public string ProviderSwitches { get; set; }
public int? Timeout { get; set; }
}

    public static void MigrateToLatest(string connectionString)
    {
        // var announcer = new NullAnnouncer();
        var announcer = new TextWriterAnnouncer(s => {
            System.Diagnostics.Debug.WriteLine(s);
        });

        var assembly =  typeof(DAL.SomeMethod).Assembly ;

        RunnerContext migrationContext = new RunnerContext(announcer);
        migrationContext.NestedNamespaces = true;
        migrationContext.Connection = connectionString;


        var options = new MigrationOptions { PreviewOnly = false, Timeout = 60 };
        var factory =
            new FluentMigrator.Runner.Processors.MySql.MySql5ProcessorFactory();

        using (var processor = factory.Create(connectionString, announcer,  options))
        {
            var runner = new MigrationRunner(assembly, migrationContext, processor);
            runner.MigrateUp(true);
        }
    }
}

```

[fubar-coder]

The .NET Core tooling will work better as soon as the global tools support is published. I'll leave this issue until the the global tools support landed in .NET Core.

Partially fixed after #857 is done.

[fubar-coder]

dotnet-fm tool is now part of the 3.0.0 release, which will be released as soon as .NET Core 2.1 is released.

[justinboyd]

Since dotnet core 3.1 was released this issue was reintroduced.

[jzabroski]

@justinboyd Unlikely. More likely the problem is you are trying to run dotnet-fm (a .NET Core 3.0 global tool) using .NET Core 3.1. In general, I don't think that's a supported scenario by Microsoft. Global Tools are a form of DLL Hell, really. That's why we created #1016 to explain some of the issues.

It's especially annoying because if you go to nuget.org for the package, it says "No dependencies", which is total crap. https://www.nuget.org/packages/FluentMigrator.DotNet.Cli/

To understand this problem, you have to understand that Microsoft effectively wrote a _very complicated Linker_ for .NET Core to replace bindingRedirects. It tries to do many clever things vs. the dead simple bindingRedirect.

[justinboyd]

@jzabroski You are 100% right in the way I'm attempting to execute the runner.

I understand, kind of a bummer, not on your part though. Thank you for the quick reply!

[jzabroski]

No worries. I'm not blaming Microsoft, btw. When I first heard of Global Tools, it didn't dawn on me that this would be a problem, even though the word Global should've told me "Spooky action at a distance" issues would exist. I don't know why as engineers we miss these obvious things. What I do know is that writing a Linker is in general incredibly complicated, understanding what the Linker does is even more complicated, and only about 5 people in the whole world probably understand how the .NET Core Linker works.
That's not a bad thing: if you rely on the MSBuild/Dotnet toolchain to resolve things for you, it generally just works. It's magic, but it works. And it saves you a ton of time vs. bindingRedirect. And if you run things in a Docker container, the chances your Linker get upgraded is actually sort of small, because you are statically linking to the runtime targeting pack you want to run against. In this sense, Microsoft/.NET Core is engineering towards a future where containers are prevalent and having tiny footprints is desirable.