MMS • RSS
Fake 5 was recently recently released after several several months of previews. This new version of the build tool for .NET applications brings a rewrite of the core, as well as many internal improvements and features. InfoQ reached out to Matthias Dittrich, maintainer of Fake, to learn more about all the changes and features.
InfoQ: What were the goals driving the Fake 5 release?
Matthias Dittrich: Historically, I felt like introducing FAKE was a huge burden – especially the recommended approach. This is because you had to learn Paket, FAKE and introduce several global files like
paket.lockand then Paket would create several other folders like
.paketand FAKE was creating a
While all of this infrastructure is completely fine and there was perfectly valid reasons behind all of that. It was a huge deal for small projects, for simple scripts and, in my opinion, a major blocker to adoption.
Then .NET Core was introduced and basically threw everything away we knew about .NET. You could publish standalone applications without dependency on any installed .NET framework. I felt like it was the perfect time to re-think the current approach to bootstrapping and use the .NET Core port (which we eventually had to do anyway) to implement it.
So basically the goal was to fix the burden from above, allowing to opt-out into a simpler workflow. Some other long outstanding wishes were to cleanup and uniform the API as well as split it into smaller modules.
Historically, people just contributed new functionality into a single project called
FakeLib. This library basically has grown over 5-10 years! We have everything in there you probably don’t even know exists.
On the other hand this means everybody is downloading everything every time. Something we never knew how to fix without breaking the ecosystem. Guess what – we found a way now.
InfoQ: Users can now create custom modules to extend Fake. Can you give more details about how it works?
Dittrich: Sure. Actually it is surprisingly easy (from a users standpoint). All you need to do is publish a .NET (C#/F#/…) library on any NuGet-Feed and reference it in your build script via Paket-Syntax on top of your file.
The only requirement is the library needs to be compatible to netstandard 2.0.
For example if I have the .NET SDK installed, create a new folder
dotnet new classlib && dotnet packand upload the
bin/Debug/testfakelib.nupkgfile to NuGet, I’m already ready to go.
Technically, we use Paket behind the scenes to do the heavy lifting of resolving transitive dependencies and finding the correct dll’s we need to compile and run the fake/f# script. It is a bit of an over-simplification but hey no need to bore anyone to death.
InfoQ: What are the notable features or improvements of this release?
Dittrich: The most notable features are, in my opinion:
It is much easier to get started no matter which environment you are currently in and no matter which way of bootstrapping/installing FAKE you prefer.
FAKE is now a lot more viable for scripting and small automation purposes (we now go further than “only” building).
You can now easily embrace the huge NuGet ecosystem to extend your builds and easily extend yourself.
But it really is hard to choose. For example a lot of help from the community went into the cleanup and modularization of the API. And I think we can be really proud of the results.
The point is: we might not have gotten everything perfect on the first shot.
But with the module system we have the option to create better an improved modules and obsolete old ones without breaking anyone.
InfoQ: What were the changes required in order to support .NET Core?
Dittrich: Actually, I don’t think we had to do most of the stuff we did just to support .NET Core. We just used the opportunity there. Technically, – especially since netstandard20 – we probably could have just recompiled most of the code. But where would have been the fun in that?