fluentmigrator: 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.
-
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
MissingMigrationsExceptionis thrown, even though, to the best of my knowledge, the appropriate class is discoverable. -
Running out of process When running using the out of process tool, the tool fails to find FSharp.Core
-
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:
.paket/paket.exe install(use mono if not on windows)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.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 50 (3 by maintainers)
Commits related to this issue
- Add FSharp.Core as reference This should enable F# usage in **at least some** scenarios (issue #883). — committed to fluentmigrator/fluentmigrator by fubar-coder 6 years ago
- Demo of https://github.com/fluentmigrator/fluentmigrator/issues/883 — committed to jzabroski/FSharpFluentMigratorCli by jzabroski 4 years ago
@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.
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:
list migrationscommand 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.Alright, I pushed the latest version and cleaned it up a bit based on your suggestions. Let me know if you think this is a publishable F#-style, or if any other improvements are needed.
@voroninp I spent my Saturday evening putting together a sample of an F# In-Process Runner using FluentMigrator. I am by no means an F# expert and last wrote F# code in January as part of a project to port F# logic to C#. In particular, I found some of the syntax F# seemed to require me to write to interface with C# logic:
WrappingAction<T>requires extra type parameter noise compared to C# (surprisingly)However, I can guarantee you I got this working. Please see: https://github.com/jzabroski/FSharpFluentMigratorCli/tree/master
Up next to is to debug the issues with running this from Fake, but for that I need more information from @tylerhartwig please.
BTW, @cartermp - if interested, feel free to code review and correct me if my above experience is based on amateurish insight 😃
Pushed it to repo as well
(found this from SO)
When using the .NET SDK (or any new “legacy” project as of VS 16.0) the FSharp.Core binary is a package. Things used to be absolutely nightmarish with FSharp.Core in the GAC, then not in the GAC, then at least three different ones depending on what you were doing (.NET Core 1.x was great). But now it’s just the package for anything build with VS 2019 or from .NET Core.
Since versioning could only ever be horribly complicated, here’s a full breakdown of the various versions and what they mean.
4in the front used to be the CLR version 4, since F# had to be compatible across incompatible CLRs. It’s now just the major language version number.betais needed because VS, to this day, won’t load it in process with a git hash. It’s a really weird restriction, but C# is equally affected and it hasn’t appeared to have been a problem.Currently the numbers should be:
So the versions @voroninp reports in the deps.json in the SO question appear to line up.
The FSharp.Core binary itself is laid out under
FSharp.Core.4.7.1/lib/tfm/FSharp.Core.dlland that’s been the format ever since it’s been distributed via NuGet. I doubt that will change, though we will be dropping thenet45binary in F# 5/.NET 5.I created the side C# project and was able to load the published assembly and scan all attributes. I’ll add in-proc runner, and let you know whether it works.
Okay, silly me. I’ve solved my own problem. Turns out my project is still targeting
netcoreapp2.0and all new global cli tools arenetcoreapp2.1by default. Which makes sense that it couldn’t find myFSharp.Core.dll.I’ve made a sample project using
netcoreapp2.1, did a publish, installeddotnet-fmas a local tool in my publish folder and was able to execute the migration.