Home

FAQ

What is this?

A convention driven set of build scripts for .net projects. It was created after we gave up on trying to tame MSBuild. We use NUnit for unit tests, SpecFlow for BDD and publish our artifacts via NuGet.

So by default, that's what Build.Tools does too.

Check out the overview at http://15below.github.io/Build.Tools

How do I use it?

Create a submodule of Build.Tools at the root of your source repository called tools.

Then create a batch file build.bat with:

tools\Fake\FAKE.exe tools\Core.fsx "tools=tools" "solution=src\MySolution.sln"

Running the batch file will carry out all of the operations above, except publishing NuGet packages; you'll need to give it a bit more information for that.

Can I change the default build process?

Of course, see Changing the default build process for more information.

How do I get Build.Tools to publish NuGet packages?

By default, it will only publish at all if it is running on a build server (tested on TeamCity, others should be detected in most circumstances).

As well as running on the build server, you will also need to supply the following configuration values either on the command line or as environment variables. We would recommend the later in most cases.

• pushurl
• apikey

Finally, Build.Tools will only attempt to create packages from projects that have a matching .nuspec file in the same directory as the proj file.

For example, if you want to package My.SuperLib.fsproj you'll need to put My.SuperLib.nuspec in the same directory. NuGet.exe can help you generate the nuspec from the project file using the spec command.

My NuGet package has been versioned with a weird deformed version number!?

We use feature branches heavily, and don't want to get them confused with release branches. We assume a release build is a build built on the build server, on the master branch of a git repository.

As such, if your project's assemblyinfo file contains an AssemblyInformationalVersion and any of the above are not true, Build.Tools will create a pre-release NuGet version with a name based on the branch name.

How do I get my unit tests to run?

Write them in NUnit and call the dll [something].Tests.dll. Patches and conventions for other test libraries accepted.

How do I get my SpecFlow features to run?

Put them in a dll called [something].Features.dll.

How do I get more than one set of SpecFlow features to run?

Sorry, we don't support that yet. Why not send a patch?

Can I create deployment packages?

There is opinionated support included for generating Octopus deployment packages, see Deployment.

What's an fsx file?

They're F# script files. F# was added to the official .net family of languages in Visual Studio 2010, and part of the language is a specification for script files. The ones in Build.Tools are designed to be run via the FAKE (F# make) executable, but Visual Studio will recognise them as valid F# and you can edit them with full intellisense support and type checking.

What's this FAKE thing?

FAKE (F# make) is both an executable wrapper around F# interactive, and a set of helper libraries that can be referenced from fsx scripts (or any .net code, for that matter). The scripts in the Build.Tools project are designed to be run by FAKE which provides things like timing metrics and target dependency resolution. A specific version of FAKE is included within the repository so that you can just sub-module it and go without having to worry about dependencies. You can check out the FAKE project pages if you want to know more.

You keep on saying .net. Will this work on Mono?

Probably not. The NUnit and SpecFlow runners assume they are running on Windows at the moment. Patches to make the scripts Mono compatible would be gratefully accepted.