Today I released FAKE 2.12 with a lot of small bug fixes and improvements. The biggest feature is that we now use NancyFx for FAKE.Deploy. A big thanks to all of the 60 contributors.
What’s new?
- Add getDependencies to NugetHelper #373
- Add more F# friendly functions for IO.Path #374
- SourceLink support #345
- NancyFx instead of ASP.NET MVC for FAKE.Deploy #376 – big thanks to @MorganPersson
- Allows to execute processes as unit tests #379
- Allow to run MsTest test in isolation #367
- Fixed Nuget.packSymbols #366
- Fixed bug in SemVer parser #364
- New title property in Nuspec parameters #359
- Added option to disabled FAKE’s automatic process killing #357
- Better AppyVeyor integration #353, #345
- Added ability to define custom MSBuild loggers #352
- Fix for getting the branch name with Git >= 1.9 #351
- Added functions to write and delete from registry #350
- NUnit NoThread, Domain and StopOnError parameters #349
- Add support for VS2013 MSTest #346
- Lots of small fixes
Getting started
If you new to FAKE you should read the getting started guide or clone the F# ProjectScaffold.
Go and grab the bits
Feel free to contact me if you need help for the upgrade.
Tags:
F#,
Fake
Today I released two new AssemblyInfo tasks for FAKE and marked the old one as obsolete. One advantage of the new tasks is that they only generate the specified attributes and no more. There are already a lot of predefined attributes but it’s also possible to specify new ones. Here is a small example:
Tags:
F#,
F-sharp Make,
Fake
My friend Björn Rochel (@BjoernRochel) built a really cool generic model for using fakes and automocking on top of Machine.Specifications (or MSpec) called Machine.Fakes (or mfakes).
Today he released version 0.1.0.0 (get it from nuget.org) and I want to talk a bit about the build process. Björn and myself thought a tool called “Machine.Fakes” should of course be built with a tool called “FAKE – F# Make”. In order to do so I had to fix some stuff in Fake which resulted in the new Fake version 1.50.1.0.
Here are some things I fixed:
- New task DeleteDirs allows to delete multiple directories.
- New parameter for NuGet task which allows to specify dependencies.
- Bundled with docu.exe compiled against .Net 4.0.
- Fixed docu calls to run with full filenames.
- Added targetplatform, target and log switches for ILMerge task.
- Added Git.Information.getLastTag() which gets the last git tag by calling git describe.
- Added Git.Information.getCurrentHash() which gets the last current sha1.
Machine.Fakes build setup
The build script for Machine.Fakes performs the following steps:
- It retrieves the version no. via GitHubs REST API
- It cleans all directories from old stuff
- It compiles the app and test projects
- It uses MSpec to test the application
- It merges StructureMap and StructureMap.AutoMocking into the app by using ILMerge
- It generates the XML documentation using the .NET 4.0 version of docu.exe
- It zips the app and the documentation files
- It builds and deploys a Nuget package with just Machine.Fakes
- It builds and deploys bundled Nuget packages in the following flavors:
- Machine.Fakes.FakeItEasy
- Machine.Fakes.RhinoMocks
- Machine.Fakes.Moq
Now you can start using this awesome project by calling:
install-package Machine.Fakes.{Flavor}
Tags:
F#,
Fake,
Machine.Fakes,
Machine.Specifications
Today I released “FAKE – F# Make” version 1.40.5.0. This release fixes some issues with CruiseControl.NET compatibility and improves the MSBuild task.
Important links:
Changes for CruiseControl.NET
Daniel Nauck created a FAKE task for CC.Net. This task allows a much easier configuration of FAKE. Please download the latest CC.NET build if you want to use it.
Daniel also created a FAKE build project on his server which showed us some compatibility issues:
- In FAKE:
- Race condition in FAKE’s trace functionality
- Better XML tracing if something fails
- The tracing buffer will be flushed after every build target
- Every task has a Timeout property (Default: 5 min.)
- Setting of environment variables fixed
- Showing labels in NUnit is now the default
- In Docu:
- In CC.NET:
@Daniel: Thank you very much for helping me on this CruiseControl.NET stuff. I really appreciate this.
MSBuild task changes
The MSBuild task in FAKE gets a sequence of project files and compiles them in the given order. This might be slow if you have lots of dependent projects. Then MSBuild might analyze the dependencies over and over again. To fix this issue I currently see two possible solutions:
- Generate a temporary solution file and use this for compilation.
- Analyze the given projects and remove all dependent projects from the list.
FAKE 1.40.5.0 implements the second idea. If you have a better idea please contact me.
Tags:
docu,
F#,
F-sharp Make,
Fake
Yesterday I released “FAKE – F# Make” version 1.33.0. This release has lots of small bug fixes and a couple of new features.
Important links:
Git helpers -Fake.Git.dll
Git is a distributed revision control system with an emphasis on speed. Git was initially designed and developed by Linus Torvalds for Linux kernel development. Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.
[Wikipedia]
In the last couple of months I worked on small helper library for controlling Git. This library is now released as part of “FAKE – F# Make”. You can find the source code at http://github.com/forki/FAKE/tree/master/src/app/Fake.Git/.
Features:
- Repository handling
- Submodules
- init, clone, information about submodules
- Branches
- checkout, create, delete, merge, rebase, tag, pull, push, reset, commit, …
- SHA1 calculation
Documentation generation with James Gregory’s docu tool
What’s a docu? A documentation generator for .Net that isn’t complicated, awkward, or difficult to use. Given an assembly and the XML that’s generated by Visual Studio, docu can produce an entire website of documentation with a single command.
[docu website]
Fake comes bundled with James Gregory’s documentations generator “docu”, which converts XML-Documentation comments into HTML files. All you need to do is downloading a template and calling the docu task inside your build script:
!+ (buildDir + "*.dll")
|> Scan
|> Docu (fun p ->
{p with
ToolPath = docuPath + "docu.exe"
TemplatesPath = templatesSrcDir
OutputPath = docsDir })
Since FAKE builds its own documentation with docu I started to add more (and hopefully better) XML doc comments. My plan is to describe more and more of the internal FAKE functions in the next releases. An updated HTML-document (generated via a docu task) can be found at http://www.navision-blog.de/fake/.
Side by side specification
For Test-driven development (TDD) it’s sometimes nice to have the specifications next to the implementation files since the specs are considered as documentation.
By using a tool like VSCommands it is possible to group the implementation with the specs (see also http://gist.github.com/457248).
This “side by side specification” makes TDD a lot easier but of course we don’t want to deploy the specification classes and the test data.
 |
==> |
 |
FAKE has a new feature which automatically removes all specification files and test framework references according to a given convention:
Target "BuildApp" (fun _ –>
!+ @"src\app\**\*.csproj"
|> Scan
|> Seq.map (
RemoveTestsFromProject
AllNUnitReferences // a default references convention
AllSpecAndTestDataFiles // a default file convention
)
|> MSBuildRelease buildDir "Build"
|> Log "AppBuild-Output: "
)
The conventions are simple functions and can be customized e.g.:
/// All Spec.cs or Spec.fs files and all files containing TestData
let AllSpecAndTestDataFiles elementName (s:string) =
s.EndsWith "Specs.cs" ||
s.EndsWith "Specs.fs" ||
(elementName = "Content" && s.Contains "TestData")
Miscellaneous
- SQL Server helpers are moved to Fake.SQL.dll
- Additional functions for attaching and detaching databases.
- FileHelper.CopyCached function was added
- Copies the files from a cache folder. If the files are not cached or the original files have a different write time the cache will be refreshed.
- EnvironmentHelper.environVarOrDefault added
- Retrieves the environment variable or a given default.
- Fixed Issue 3: toRelativePath calculates paths with ..\..\ if needed
- Added a build time report to the build output.
- XPathReplace and XMLPoke tasks added.
- Replaces text in an XML file at the location specified by an XPath expression.
- ILMerge task added
- Windows Installer XML (WiX) task added
Tags:
F#,
F-sharp Make,
Fake,
git,
SideBySideSpecification,
SQL Server,
TDD,
xml,
XPath
Earlier today I released “FAKE – F# Make” version 1.10.0. This new release contains a lot path issue fixes for Mono and a new architecture for logging and tracing.
A guy named Joel Mueller had an awesome idea and sent me some patches. He noticed that TraceHelper.fs writes all messages synchronously to the console and/or a XML output file, which means the actual build operations must wait on the writing of hundreds of trace messages, slowing down the actual build.
His idea was to use a MailboxProcessor to buffer up the trace messages and write them out asynchronously, so that the actual build can proceed at full speed.
type Message =
{ Text : string
Color : ConsoleColor
Newline : bool
Important : bool}
/// ….
let buffer = MailboxProcessor.Start (fun inbox ->
let rec loop () =
async {
let! (msg:Message) = inbox.Receive()
match traceMode with
| Console -> logMessageToConsole msg
| Xml -> appendXML msg.Text
return! loop ()}
loop ())
Now all internal logging and tracing functions can post their their messages to the inbox of the MailboxProcessor:
/// Logs the specified string (via message buffer)
let logMessage important newLine message =
match traceMode with
| Console ->
{ Text = message;
Important = important;
Newline = newLine;
Color = ConsoleColor.White }
|> buffer.Post
| Xml ->
{ defaultMessage with
Text = sprintf "<message><![CDATA[%s]]></message>"
message }
|> buffer.Post
This idea reduces the build time of FAKE’s self build from 3 min. to 2 min. Which is really amazing, since I didn’t have to change anything in the build script. This version is compatible to the last released version.
Please download “FAKE – F# Make” version 1.10.0 and tell me what you think.
Tags:
F#,
F-sharp Make,
Fake,
performance
The new version 0.27 of “FAKE – F# Make” comes with new syntactic sugar for build targets and build dependencies. Don’t be afraid the old version is still supported – all scripts should still work with the new version.
The problem
Consider the following target definition:
let buildDir = "./build/"
Target "Clean" (fun _ ->
CleanDir buildDir
)
Target "Default" (fun _ ->
trace "Hello World from FAKE"
)
"Default" <== ["Clean"]
run "Default"
As you can see we are having a lot of “magic strings” for the target names and the dependency definitions. This was always a small shortcoming in FAKE, since this doesn’t allow refactoring and may result in runtime errors.
One of my goals for “FAKE – F# Make” is to remove these strings in future versions. Unfortunately this is not that easy, because it causes a lot of internal issues. In particular logging to the build server is much harder if you don’t have a target name.
The first step
As posted in a bitbucket comment by cipher we could use the “dynamic lookup operator” to remove some of the magic strings without breaking any internal code.
As a result we can rewrite the above sample as:
let buildDir = "./build/"
Target? Clean <-
fun _ -> CleanDir buildDir
Target? Default <-
fun _ -> trace "Hello World from FAKE"
For? Default <- Dependency? Clean
Run? Default
All magic strings suddenly disappeared. I think this syntax looks really nice, but unfortunately the strings are not really gone, since the token Default is only checked at runtime.
The idea for future versions
Since the new syntax is really just syntactic sugar I’m always interested in a better solution. Currently I’m working on a syntax using monads. The result could look like this:
let buildDir = "./build/"
let Clean = target { CleanDir buildDir }
let Default =
target {
trace "Hello World from FAKE"
trace "Another line"
}
Default <== [Clean]
This way the magic string are really gone, but my current problem is retrieving the target name from the let-binding name. Please leave a comment if you have an idea to solve this issue.
Tags:
F#,
F-sharp Make,
Fake
Yesterday I released “FAKE – F# Make” version 0.14 with xUnit.net support. The usage is very easy and similar to the usage of NUnit:
Target "xUnitTest" (fun () ->
let testAssemblies =
!+ (testDir + @"\Test.*.dll")
|> Scan
xUnit
(fun p ->
{p with
ShadowCopy = false;
HtmlPrefix = testDir})
testAssemblies
)
This sample works perfectly with TeamCity and creates a html-page per test project in addition:
If you want to publish the xUnit.net test results in CruiseControl.NET just modify the build script a little:
Target "xUnitTest" (fun () ->
let testAssemblies =
!+ (testDir + @"\Test.*.dll")
|> Scan
xUnit
(fun p ->
{p with
ShadowCopy = false;
HtmlPrefix = testDir;
XmlPrefix = testDir })
testAssemblies
)
Now follow the steps in the CrusieControl.NET documentation. You will need to download the xUnitSummary.xsl file and save it to your webdashboard directory. If everything works correctly you should see something like this:
Tags:
CruiseControl.NET,
F#,
F-sharp Make,
Fake,
nunit,
xUnit.net. TeamCity
Since version 0.12 the FAKE build system provides an easy way to setup build configurations for CruiseControl.NET.
“CruiseControl.NET is an Automated Continuous Integration server, implemented using the Microsoft .NET Framework.”
[thoughtworks.org]
In this article I will show you how you can set up a FAKE build script in CruiseControl.NET. We will use the CalculatorSample which you can download from the FAKE Download page.
If you want to know how this build script works and how you could create one for your own projects please read the “Getting started with FAKE”-tutorial.
If you want to set up “FAKE – F# Make” build configurations in TeamCity please read “Integrating a "FAKE – F# Make" build script into TeamCity”.
Installing CruiseControl.NET
You can download CruiseControl.NET from thoughtworks.org. After the installation process (further instructions) you should see an empty dashboard:
Installing Subversion
The CalculatorSample is using Subversion (SVN) for SourceControl, so we need to download SVN from subversion.tigris.org. I’m using the “Windows MSI installer with the basic win32 binaries” and installed them under “c:\Program Files (x86)\Subversion\”.
Installing FxCop
The CalculatorSample is using FxCop, so we need to download and install it next.
“FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. Many of the issues concern violations of the programming and design rules set forth in the Design Guidelines for Class Library Developers, which are the Microsoft guidelines for writing robust and easily maintainable code by using the .NET Framework.”
[MSDN]
Creating a FAKE Project
Now create a new folder for the CalculatorSample sources. I’m using “d:\Calculator\” for the rest of the article.
The next step is to modify the CruiseControl.NET config file (“c:\Program Files (x86)\CruiseControl.NET\server\ccnet.config” on my machine):
<cruisecontrol>
<project>
<name>CalculatorExample</name>
<triggers>
<intervalTrigger name="continuous" seconds="30" initialSeconds="30"/>
</triggers>
<sourcecontrol type="svn">
<executable>c:\Program Files (x86)\Subversion\bin\svn.exe</executable>
<workingDirectory>d:\Calculator\</workingDirectory>
<trunkUrl>http://fake.googlecode.com/svn/trunk/Samples/Calculator/</trunkUrl>
</sourcecontrol>
<tasks>
<exec>
<executable>d:\Calculator\tools\Fake\Fake.exe</executable>
<baseDirectory>d:\Calculator\</baseDirectory>
<buildArgs>completeBuild.fsx</buildArgs>
</exec>
</tasks>
<publishers>
<merge>
<files>
<file>d:\Calculator\test\FXCopResults.xml</file>
<file>d:\Calculator\test\TestResults.xml</file>
<file>d:\Calculator\output\Results.xml</file>
</files>
</merge>
<xmllogger />
</publishers>
</project>
</cruisecontrol>
In this configuration I set up a trigger which checks every 30 sec. for changes in my CalculatorSample project.
If SVN finds changes FAKE.exe is called with my build script (completeBuild.fsx).
After the build I want to merge the FxCop and NUnit output files with my build results to create a build report.
Configuring the dashboard
In order to provide a nicer output on the dashboard we need to modify the BuildPlugins section in the dashboard.config file (“c:\Program Files (x86)\CruiseControl.NET\webdashboard\dashboard.config” on my machine):
<buildPlugins>
<buildReportBuildPlugin>
<xslFileNames>
<xslFile>xsl\header.xsl</xslFile>
<xslFile>xsl\modifications.xsl</xslFile>
<xslFile>xsl\NCoverSummary.xsl</xslFile>
<xslFile>xsl\fxcop-summary_1_36.xsl</xslFile>
<xslFile>xsl\unittests.xsl</xslFile>
<xslFile>xsl\nant.xsl</xslFile>
</xslFileNames>
</buildReportBuildPlugin>
<buildLogBuildPlugin />
<xslReportBuildPlugin
description="NCover Report"
actionName="NCoverBuildReport"
xslFileName="xsl\NCover.xsl"></xslReportBuildPlugin>
<xslReportBuildPlugin description="FxCop Report"
actionName="FxCopBuildReport"
xslFileName="xsl\fxcop-report_1_36.xsl" />
<xslReportBuildPlugin description="NUnit Report"
actionName="NUnitBuildReport"
xslFileName="xsl\tests.xsl" />
</buildPlugins>
As you can see we use the nant.xsl to transform the FAKE output to HTML.
Starting the build
Now if everything is configured correctly, you can tell CruiseControl.NET to run your build (press “Start” for your build project on the dashboard):
Now CruiseControl.NET should use SVN to checkout the CalculatorSample sources and run the build. The output on the project page for build 1 should look like this:
You can also inspect the NUnit and FxCop results:
Please feel free to give feedback if you have any problems with this article.
Tags:
CC.NET,
Continuous Integration,
CruiseControl,
CruiseControl.NET,
F#,
F-sharp Make,
Fake
