Prehistory

AnFake project inspired by FAKE (F# Make) and aimed to solve some conceptual problems which I faced when tried to use FAKE.

FAKE didn’t provide Team Foundation Server integration out of box. The story started when we (me and my colleagues) decided to use FAKE for customizing builds instead of awful Microsoft’s monster called ‘Build Process Template’. Unfortunately, FAKE knows nothing about TFS. Of course, we could invoke FAKE as external process but this approach didn’t give us desired results. We would like to see nice build summaries as TFS itself does. And also it was necessary to set some build properties from within build script – such as ‘Build Quality’ and ‘Build Status’ (we were interesting in ‘partially succeeded’ status). FAKE didn’t give us these features so I tried to extend it and found…
FAKE wasn’t designed to be extensible. The first task I tried to solve was to pass build warning/errors to TFS build tracking subsystem. I expected that FAKE aggregates all messages (from MSBuild, MSTest and so on) in own xml log and all that I need is to parse such log. But just a few moments later I realized – FAKE log contains only messages of FAKE itself, I couldn’t reach MsBuild warning/errors in this way! Ok, I wrote my own logger for MSBuild and got what I wanted. Then I turned to MSTest. MSTest writes test trace to xml file specified from command line. Good. But… FAKE doesn’t expose results file name to caller. It internally generates this name on the basis of current timestamp, so I couldn’t definitely predict this name from outer scope. Hmm… I was forced to write my own alternative of MSTest helper which is exactly copy-paste of original method but with MSTest results parsing. And this is generic problem - each new tool to be integrated with TFS needs its own “shamanic dance”.
FAKE provides inconvenient error reporting. FAKE renders exceptions with full stack trace but in most cases this is trace of FAKE lib and it isn’t interesting for build engineer or developer. It just clog an output. On the other hand, there is no build summary at the end. If some warning/error occurred near start point and after was a lot of other output then you might never find such message at all.
FAKE is badly structured. Some FAKE tools have inconsistent set of methods. E.g. MSBuildHelper.build has setParams function as argument which allows full control over MSBuild command line but the second argument represents just a single project/solution. On the other hand, MSBuildHelper.MSBuildDebug (and similar) accepts multiple projects but doesn’t provide setParams. So if you need to build multiple projects (w/o solution) and need full control over MSBuild command line then you will be in confusion - there is no suitable method… Some other tools lacking useful methods. E.g. there is no ‘append to zip’ operation. Another example FileHelper.CopyWithSubfoldersTo - it was contributed by my colleague during this story. FAKE API has annoying inconsistent naming – some methods are in camelCase but other in PascalCase, some tools look like a standalone function but other as static class members and so on. This greatly confuses beginners.