Migrations not found when defined in F#

Migrations defined in F# fail to be discovered by FluentMigrator when defined in F#.

I have tested this a plethora of ways from F#, each resulting in a different error.

1. Running using FAKE a) When running without explicitly loading FluentMigrator and FluentMigrator.Abstractions into the load context, these assemblies cannot be found.

   b) When running with these explicitly loaded, a MissingMigrationsException is thrown, even though, to the best of my knowledge, the appropriate class is discoverable.

2. Running out of process When running using the out of process tool, the tool fails to find FSharp.Core

3. Running as a separate console application (defined in F#) When running in the separate console application, a SIGSEV is thrown.

I don’t think this library explicitly supports F#, and I understand that, however while result 1a seems weird, 1b is really what I’m opening an issue about.

I can reflectively find my Migration’s type, and confirm it has the Migration attribute on it. Additionally it implements Migration, so it should be discoverable.

I’ve run this on the latest core SDK, as well as the latest preview SDK.

I have provided a minimal solution to display the issue.

to run from Fake, the command should be as follows:

1. .paket/paket.exe install (use mono if not on windows)
2. dotnet build build.proj

[EDIT]

Fixed problem 1, the migration assembly was being loaded into the wrong context, this is not a FluentMigrator issue.

I will leave this issue open in case 2 and 3 are of interest.

[jzabroski]

@cartermp No worries - and I hope my comments about disliking F# are not taken personally. I was a huge fan of F# in the early days but just gave up the evangelism battle, especially when I ran into stability issues. Still hope F# teaches the CLR team to think more robustly about the CLR type system.

[jzabroski]

GenericProcessorBase.cs should probably pass the connection string into a connection string builder to provide a better error message. However, this error indicates that the issue is simply that you didn’t tell it the connection string.

In this case, please:

1. open a bug for “dotnet-fm list migrations shouldn’t require connection string”. I think this is a separate issue. The workaround is to supply a connection string to a database.
2. (Possibly) Open a feature request for list migrations command with more options, such as listing migrations available vs. migrations not yet applied to a target database (which would require a connection string). Please provide feedback here on whether you think this is needed.