fluentmigrator.dotnet.cli requires dotnet 5.x even when newer versions are installed
See original GitHub issueDescribe the bug The fluentmigrator.dotnet.cli seems to require dotnet 5.x even when newer versions are installed. When attempting to run the cli in an environment without dotnet 5.x it will simply refuse to even start. This is the output from encountering this bug in Azure DevOps:
You can invoke the tool using the following command: dotnet-fm
Tool 'fluentmigrator.dotnet.cli' (version '3.3.2') was successfully installed.
You must install or update .NET to run this application.
App: C:\Users\VssAdministrator\.dotnet\tools\dotnet-fm.exe
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '5.0.0' (x64)
.NET location: C:\Program Files\dotnet\
The following frameworks were found:
3.1.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
3.1.6 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
3.1.20 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
3.1.32 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
6.0.5 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
6.0.14 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
7.0.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Learn about framework resolution:
https://aka.ms/dotnet/app-launch-failed
To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=5.0.0&arch=x64&rid=win10-x64
##[error]Cmd.exe exited with code '-2147450730'.
I was also able to replicate the behaviour locally after uninstalling dotnet 5.x
To Reproduce Simply run dotnet-fm in any environment without dotnet 5.x installed, such as an Azure DevOps hosted agent.
Expected behavior I expected fluentmigrator.dotnet.cli to only be dependent on having any version of dotnet installed.
Information (please complete the following information):
- OS: Windows 10/11
- Platform: dotnet 6.0/7.0
- FluentMigrator version: 3.2.2
- FluentMigrator runner: FluentMigrator.DotNet.Cli
- Database Management System: Any
- Database Management System Version: Any
Additional context This issue was encountered when attempting to run fluentmigrator migrations as part of a Azure DevOps pipeline on their hosted agents, as none of them have dotnet 5.x installed anymore, so even though fluentmigrator.dotnet.cli is successfully installed it just refuses to run any dotnet-fm commands due to the missing dotnet 5.x version.
Issue Analytics
- State:
- Created 6 months ago
- Reactions:1
- Comments:13 (2 by maintainers)
Top GitHub Comments
This PR should fix it, but it has been very little activity in this project lately. Previous release was october 2021, even if some PRs have been merged since then. I am considering other solutions for our migrations.
A workaround for me is to use unit tests or a custom console application for migrations as an alternative to the FluentMigrator.DotNet.Cli tool.
I am using Mac M1 where dotnet 5 is not supported.
https://github.com/fluentmigrator/fluentmigrator/pull/1650
The main thing I wanted to do was merge some of the old “4.0” (develop branch) contributions into main. In particular, the Snowflake one is a big one that I would love to have added.
In terms of this issue in particular, I do think the “right approach” for many is to not use FluentMigrator.DotNet.Cli directly but rather expose its entrypoint as a FluentMigratorApplicationBase base class, as that would completely solve issues with upgrading. The only downside would be that it would lock people into the Nate McMaster Command Line Utils and would not solve for people who run the migration framework directly on ASP.Net Core. But based on my experience answering issues and discussions here, the people who know how to and want to run this on ASP.Net Core would rather continue with their own approach and don’t care for an “on rails” approach. This Base class would also address the fact that Microsoft stance on CLI tools is dev only, and thus to run FluentMigrator.DotNet.Cli on a production box today effectively requires installing the SDK, which is rather nasty thing to ask System Administrators to do VS. deploy a regular .Net executable. EF Core team approach is to generate “bundles” but I think has a limited usefulness.
I’m open to not doing the Base class thing, but it’s my view that would solve half of all requests people have. In terms of why I have wanted it for 4.0, if I push it and other things, I need to reorganize a bunch of Github milestones.
I do want to note, even though we have not done a release in a while, I have spent time cleaning up the FluentMigrator/Documentation repo and there is really only one active issue there now.