You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Using FAKE with recent frameworks (8.0 and 9.0) #2862
Hi All, I am wondering if this project is still actual and maintained. I am having lots of issues in running FAKE 6 on a recent Mac (with .Net Core 8.0 and 9.0 installed).
Even using undocumented features like FAKE_SDK_RESOLVER_CUSTOM_DOTNET_VERSION and trying everything, it looks like I am always missing somethng.
I guess the reason is that it is still targeting .Net 6.0 - which is unsupported since Nov 2024.
Will FAKE be updated fot recent frameworks or should I better look elsewhere?
Are you just using fake-cli, or have you tried using FSI or compiling the build script into a regular cli application? (I think the latest fake-cli still has issues with .NET 8+ that the other approaches don't)
Will FAKE be updated fot recent frameworks
There is a pull request open to update everything to .NET 8, but it seems to have stalled at the moment
@Numpsy thank you for your answer. I have tried everything but the only way to make it work was to install .Net 6
My question was aimed at understanding the actual health of F# toolset, fake, packet, and so on because a language is only as good as its toolset.
It appears as if monkeys have started roosting in the repository and even in the "issues". .net 6 is well past the EOL (Nov. of 2024). I think this project either needs some TLC or perhaps a service to mark it's passing.
Ever since the dotnet 7.0 release, I've been using the workaround of writing my own driver programs linking against the Fake assemblies - turning the script files into program source files.
Ever since the dotnet 7.0 release, I've been using the workaround of writing my own driver programs linking against the Fake assemblies - turning the script files into program source files.
@arialdomartini
Following the response to #2871, I started a port, branch develop/net8.0 where I've got the main solution building under net8.0 (and in another branch net10.0rc2 - net9.0 would be trivial search and replace), with some much needed all-round updating there; currently working through the build.fsx file as the last obvious source file needing updates.
I think #2852 was all working except for some template tests that were trying to use the published (net 6) version of fake-cli together with the .NET 8 versions of everything else, but that last bit never manages to make it over the line
@Numpsy Of course it wouldn't - the published net6.0 fake-cli cannot ever work in the net8.0 environment - inability to work in later dotnet versions has been a known problem ever since net7.0. Without removing that block, the project is dead, dead, dead.
The only pragmatic approach is to cut losses. self-test at that point, and then ensure that the net8.0 version will run under net10.0 and so forth, resuming the published version back-testing only after the first net8.0 supporting build has released.
There was a previous suggestion at #2818 (comment) to just push out a prerelease .net 8 version of fake-cli, then update the templates and everything else after that to start from the prerelease
Doing a bit of archaeology to see what went on in the transition to net6.0, I noticed an interesting aspiration in the relevant pull request -
The benefits of this solution is the switch between runtime assemblies will now be much easier. For example, when .NET6 is officially released and adopted more. We can drop .Netstandard2.0 and use by default .NET6 - for that Fake runner will require .NET6 as a requirement - and provide a switch for next release of .NET. For example when .NET7 is released, runtime assemblies for it can be activated with a global.json file.
Perhaps a build of Fake >= 6.1.5 with such a global.json reading version of the assembly resolver could be the way of performing the transition to net8.0 (and later); the integration test failure indicates a resolution request for the global.json defined 8.0.401 SDK -
No exact match of product releases 8.0.401 found.
No product release found for 8.0.401. Maybe a pre-release? Returning all the versions.
No exact match of product releases 9.0.306 found.
No product release found for 9.0.306. Maybe a pre-release? Returning all the versions.
There was a problem while setting up the environment:
Activity
github-actions commentedon Mar 9, 2025
Welcome to the FAKE community! Thank you so much for creating your first issue and therefore improving the project!
Numpsy commentedon Mar 10, 2025
Are you just using fake-cli, or have you tried using FSI or compiling the build script into a regular cli application? (I think the latest fake-cli still has issues with .NET 8+ that the other approaches don't)
There is a pull request open to update everything to .NET 8, but it seems to have stalled at the moment
Canna71 commentedon Mar 10, 2025
@Numpsy thank you for your answer. I have tried everything but the only way to make it work was to install .Net 6
My question was aimed at understanding the actual health of F# toolset, fake, packet, and so on because a language is only as good as its toolset.
xperiandri commentedon Mar 12, 2025
Using
global.jsonhelpswaltiam commentedon Jun 6, 2025
It appears as if monkeys have started roosting in the repository and even in the "issues". .net 6 is well past the EOL (Nov. of 2024). I think this project either needs some TLC or perhaps a service to mark it's passing.
SteveGilham commentedon Oct 19, 2025
Ever since the dotnet 7.0 release, I've been using the workaround of writing my own driver programs linking against the Fake assemblies - turning the script files into program source files.
For a working example, see the projects in the AltCover build folder.
arialdomartini commentedon Oct 21, 2025
@xperiandri would you mind elaborating on this?
arialdomartini commentedon Oct 21, 2025
Is anyone already working to port FAKE to a more updated SDK? I would love to contribute.
xperiandri commentedon Oct 21, 2025
I do the same
arialdomartini commentedon Oct 21, 2025
@xperiandri
How does this work, in a nutshell? Any chance to have a sample short snippet?
I assume that this will allow you to work with .NET 8/9 but without
fakeCLI tool, right?Numpsy commentedon Oct 21, 2025
There's some documentation about different ways to run it at https://fake.build/guide/getting-started.html#Different-ways-to-run-FAKE
SteveGilham commentedon Oct 21, 2025
@arialdomartini
Following the response to #2871, I started a port, branch develop/net8.0 where I've got the main solution building under net8.0 (and in another branch net10.0rc2 - net9.0 would be trivial search and replace), with some much needed all-round updating there; currently working through the
build.fsxfile as the last obvious source file needing updates.Numpsy commentedon Oct 21, 2025
I think #2852 was all working except for some template tests that were trying to use the published (net 6) version of fake-cli together with the .NET 8 versions of everything else, but that last bit never manages to make it over the line
SteveGilham commentedon Oct 21, 2025
@Numpsy Of course it wouldn't - the published net6.0 fake-cli cannot ever work in the net8.0 environment - inability to work in later dotnet versions has been a known problem ever since net7.0. Without removing that block, the project is dead, dead, dead.
The only pragmatic approach is to cut losses. self-test at that point, and then ensure that the net8.0 version will run under net10.0 and so forth, resuming the published version back-testing only after the first net8.0 supporting build has released.
Numpsy commentedon Oct 21, 2025
There was a previous suggestion at #2818 (comment) to just push out a prerelease .net 8 version of fake-cli, then update the templates and everything else after that to start from the prerelease
SteveGilham commentedon Oct 26, 2025
Doing a bit of archaeology to see what went on in the transition to net6.0, I noticed an interesting aspiration in the relevant pull request -
Perhaps a build of Fake >= 6.1.5 with such a
global.jsonreading version of the assembly resolver could be the way of performing the transition to net8.0 (and later); the integration test failure indicates a resolution request for theglobal.jsondefined 8.0.401 SDK -