Consider a project with side-by-side specification:

Name: MyProject.csproj
Dependency on NUnit.Framework.dll
Class1.cs
Test.Class1.Something.cs
Test.Class1.Whatever.cs
Class2.cs
Test.Class2.Something.cs

This side-by-side specification is good for development, but for a release build we want to split this into two separate projects like this:

Name: MyProject.csproj
Class1.cs
Class2.cs

Name: Test.MyProject.csproj
Dependency on NUnit.Framework.dll
Dependency on MyProject.csproj
Test.Class1.Something.cs
Test.Class1.Whatever.cs
Test.Class2.Something.cs

The splitting should work for all testprojects and based on file name conventions.

Because if I will use FAKE version X it will be hard to find exact Tag for this version.

Building complete sln-files is much faster than building a sequence of csproj-files with MSBuild. We should support this.

See http://stackoverflow.com/questions/2812084/overload-operator-in-f

Samples/RunSpecificTarget/JustClean.bat

does not work due to wrong path of fake.exe

I added tasks to allow additional parameters for msbuild in MSBuildHelper.fs:

let MSBuildDebugExt outputPath properties targets =
let properties = ("Configuration", "Debug") :: properties;
MSBuild outputPath targets properties

let MSBuildReleaseExt outputPath properties targets =
let properties = ("Configuration", "Release") :: properties;
MSBuild outputPath targets properties

but of course it violates DRY. Any better solutions?

I use it to call WiX-Projects with version numbers:

Target "Deploy" (fun _ ->
let deployReferences = !! @"Setup*__.wixproj"
MSBuildReleaseExt deployDir ["Version", buildVersion] "Build" deployReferences
|> Log "DeployBuildOutput: "
)

Rename xmloutput command line param in logfile

The code in the xUnit.net section of the FAKE readme references "HtmlPrefix". This does not appear to be correct as the XUnitParams type does not contain this property.

Visual studio doesn't show the param names for curried parameters at the moment. Therefore we need a better xml-documentation in order to use the params in the right order.

It would be nice to have something like this for every FAKE function:

/// Produces relative path when possible to go from baseLocation to targetLocation
/// <param name="baseLocation">The root folder</param>
/// <param name="targetLocation">The target folder</param>
/// <returns>The relative path relative to baseLocation</returns>
/// <exception cref="ArgumentNullException">base or target locations are null or empty</exception>
let ProduceRelativePath baseLocation targetLocation =
    ....

When I build FAKE using

.\build.cmd

everything except for the documentation builds.

.\tools\docu\docu.exe .\build\Fake.SQL.dll

in the build script causes an exception. Maybe it's because I only have VS Shell + F# installed as opposed to the full VS. Or maybe the missing DLL should also be in FAKE\lib\SQLServer.

Ikke-afviklet undtagelse: System.IO.FileNotFoundException: Filen eller assemblyen 'Microsoft.SqlServer.SqlEnum, Version=
10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' eller en af dens afhængigheder kunne ikke indlæses. Den angi
vne fil blev ikke fundet.
ved System.Signature.GetSignature(SignatureStruct& signature, Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInterna
l fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType)
ved System.Reflection.RuntimeMethodInfo.get_Signature()
ved System.Reflection.RuntimeMethodInfo.GetParameters()
ved Docu.Parsing.Model.Identifier.FromMethod(MethodInfo method, Type type)
ved Docu.Parsing.DocumentableMemberFinder.d__0.MoveNext()
ved System.Collections.Generic.List1..ctor(IEnumerable1 collection)
ved Docu.Parsing.DocumentationXmlMatcher.DocumentMembers(IEnumerable1 undocumentedMembers, IEnumerable1 snippets)
ved Docu.Parsing.AssemblyXmlParser.GetAssociations(IEnumerable1 assemblies, IEnumerable1 xmlDocumentContents)
ved Docu.Parsing.AssemblyXmlParser.CreateDocumentModel(IEnumerable1 assemblies, IEnumerable1 xmlDocumentContents)
ved Docu.DocumentationGenerator.Generate()
ved Docu.Console.ConsoleApplication.Run()
ved Docu.Console.ConsoleApplication.Run(IEnumerable`1 args)
ved Docu.Program.Main(String[] args)
Running build failed.
Error:
Documentation generation failed.

As announced in the mailing list I want to build a F# 3.0 version of FAKE.
Unfortunately there is no .NET 2.0 fsi.exe at the moment so I might remove .NET 2.0 support for FAKE 2.0.

What do you think?

Hi,

I am working on a new way to manage target dependencies. I really like the tradition of declarative target management in build automation tools and FAKE offers with <== (read as: "depends on") such a declarative approach. On the other hand it seems to me that the current syntax in FAKE is designed to describe way to generic dependency graphs and therefore it is also way to verbose in practice.

In most of my builds scripts I find a linear "backbone" and only a small number of additional dependencies. So I came up with an additional syntax to describe this backbone.

Let's consider the dependency graph of https://github.com/forki/FAKE/blob/develop/build.fsx as a sample:

AllTargetsDependOn "Clean"
if not isLocalBuild then
    "BuildApp" <== ["SetAssemblyInfo"]

["BuildZip"; "Test"; "GenerateDocumentation"] |> TargetsDependOn "BuildApp"
"BuildZip" <== ["CopyLicense"; "CopyDocu"]
"Test" <== ["BuildTest"]
"GenerateDocumentation" <== ["CopyDocu"]
"ZipDocumentation" <== ["GenerateDocumentation"]
"CreateNuGet" <== ["Test"; "BuildZip"; "ZipCalculatorSample"; "ZipDocumentation"]
"Deploy" <== ["CreateNuGet"]

It looks quite complicated and uses AllTargetsDependOn and TargetsDependOn (which I don't like any more) to simplify things. Now the same code with the new "backbone"-operator (the arrow was flipped):

"Clean"
  ==> "BuildApp"
  ==> "BuildTest"
  ==> "Test"
  ==> "CopyLicense"
  ==> "CopyDocu"
  ==> "BuildZip"
  ==> "GenerateDocumentation"
  ==> "ZipDocumentation"
  ==> "ZipCalculatorSample"
  ==> "CreateNuGet"
  ==> "Deploy"

if not isLocalBuild then
    "Clean" ==> "SetAssemblyInfo" ==> "BuildApp"

I think this looks much nicer, but there is still one problem left. In the old way I didn't defined a particular order between BuildApp and BuildTest. This would allow (future versions of) Fake to run them in parallel. I came up with a second operator (<=>) which allows to specify targets on the same level:

"Clean"
  ==> "BuildApp" <=> "BuildTest"
  ==> "Test"
  ==> "CopyLicense"
  ==> "CopyDocu"
  ==> "BuildZip"
  ==> "GenerateDocumentation"
  ==> "ZipDocumentation"
  ==> "ZipCalculatorSample"
  ==> "CreateNuGet"
  ==> "Deploy"

if not isLocalBuild then
    "Clean" ==> "SetAssemblyInfo" ==> "BuildApp"

I already have a rough implementation for this but at the moment I am interested in feedback. Do you find this new syntax useful? Do you have ideas to improve it.

Best regards and thanks in advance,
Steffen

Running the latest version from github, I get lots of duplications of my project files in each subdir, each one adds an _spliced to the file name. Any hint?
(Took the SideBySide sample and used mspec runner for the tests)

See output at http://build.nauck-it.de/server/build.nauck-it.de/project/Fake/build/log20100713133151Lbuild.2010.07.13.002.xml/NAntOutputBuildReport.aspx

We are using unsanitized input here, and matching it against string that have rules in them (trailing slash here)

in the following code (scanDirectory)

• path comes from baseDir.FullName and ends with slash

• entry.BaseDirectory is manual input, and can ends with no slash

  let includedPatterns =
  includePatterns |> List.fold (fun acc entry ->
  // check if the directory being searched is equal to the
  // base directory of the RegexEntry
  if compare.Compare(path, entry.BaseDirectory, compareOptions) = 0 then entry::acc else

At the moment the MSBuild task gets a couple of proj-Files and compiles them in the given order.

This is very slow, because it compiles the dependencies over and over again.

Solution 1: FAKE should generate a temp. solution file and uses this for compilation.
Solution 2: Analyze the given projects and remove all dependent projects from the list.

When building NuGet package fails, the code that should throw an informative exception fails here. I suppose the replaceAccessKey function expects parameters in the reversed order?

Attempting to build package from 'FSharp.Data.nuspec'.
An error occurred while parsing EntityName. Line 14, position 88.
Running build failed.
Error:
    System.ArgumentException: String cannot be of zero length.
    Parameter name: oldValue
       at System.String.ReplaceInternal(String oldValue, String newValue)
       at System.String.Replace(String oldValue, String newValue)
       at Fake.NuGetHelper.NuGet(FSharpFunc`2 setParams, String nuSpec) in D:\BuildAgent-02\work\689cb4747b596ebb\src\app\FakeLib\NuGetHelper.fs:line 214
       at [email protected](Unit _arg6) in .\build.fsx:line 119
       at Fake.TargetHelper.runTarget@245(String targetName) in D:\BuildAgent-02\work\689cb474

7b596ebb\src\app\FakeLib\TargetHelper.fs:line 256

Aside, it would be really nice if the error handler could read the entire message printed by NuGet. I had to run nuget by hand to find out what was wrong when the build failed (it turned out my XML was invalid...)

Rake works this way, make works this way. I don't like to create separate shell and bat files for any possible situation!

Anyone can imagine the horror of shell files army in the root of repository.

DoubleClickMeIfYouWantToCleanOnWindows.bat
DoubleClickMeIfYouWantToCleanOnLinux.sh
DoubleClickMeIfYouWantToBuildOnWindows.bat
DoubleClickMeIfYouWantToBuildAndDeployWindows.bat
DoubleClickMeIfYouWantJustDeployWindows.bat
...

NOOO. I suggest two solutions:

• make fake to parse arguments as target actions
• additional tool or script (Fake client) which will implement this functional

first variant is right to do in my opinion, second variant is for lazy... but also will work and could be added to repository if first variant will be rejected...

Earlier version didn't allow to install packages into folders without version no. and it seems the proposed issue was closed as "Won't fix" (see http://nuget.codeplex.com/workitem/1522)

Maybe someone knows a way to do this.

Considering separation of AssemblyInfo and VersionInfo, initializing the project GUID with a new one results in compiler errors, as it would be defined twice.
In the example build.fsx it is entered anyway, so leaving it blank wouldn't matter.

What effect, if any, will the bundling of RavenDB in FAKE.Deploy have on commercial users of FAKE?

We need to move the helpers down to FakeLib

This is the scenario I want to show at the MVP summit:

• Create a small website project
  • Only a small small MVC site showing the version no.
  • One small MSpec test project
• Create build script
  • Clear folders
  • MSBuild for website and test project
  • Run MSpec
  • Create a nuget package
  • Save in deploy folder
• Configure FAKE.Deploy to listen (for demo probably on same machine)
• Configure Webserver on agent machine
• Push to agent
• Show website
• Make change to website code
• build & push again
• rollback

From the mailing group:

I'm trying to build a FAKE build for FParsec targeting both .NET 3.5 and .NET 4.0.
How do you set up a build for both target frameworks?

I didn’t do this before. I think we have to do something like XMLPoke in the project files.
Maybe we could create a task ChangeTargetFramework : (frameworkVersion:string) -> (projectFileNames: string seq) -> (newProjectFileNames: string seq).
This task would create copies of the original projects with the replaced target version (which could be ignored in .gitignore).

What do you think? Is this enough?

///

/// The source directory (fileName)
/// The target directory (fileName)
let SCP scpTool source destination =
tracefn "SCP %s %s" source destination

  let args = sprintf "-r \".\" %s" (destination |> toParam)

  tracefn "%s %s" scpTool args
  let result = ExecProcess (fun info ->
     info.FileName <- scpTool
     info.WorkingDirectory <- source |> FullName
     info.Arguments <- args) System.TimeSpan.MaxValue

  if result <> 0 then failwithf "Error during SCP From: %s To: %s" source destination

A FSI.dll is needed.
Good thing is: @fahadsuhaib built one.

Let's try this out.

In order to show the build process the xml logger should also print to the console.

Proposed folder structure on remote agents

• deployments
  • FAKE
    • active
      • FAKE-1-66.nupkg
      • extracted
        • tools
        • ....
        • install.fsx
    • backups
      • FAKE-1-64.nupkg
      • FAKE-1-65.nupkg
  • SignalR
    ....

Commands

Show all active releases:

FAKE.Deploy /activereleases [server]

Show active releases for FAKE:

FAKE.Deploy /activereleases [server] FAKE

Show all releases:

FAKE.Deploy /allreleases [server]

Show all releases for FAKE:

FAKE.Deploy /allreleases [server] FAKE

Rollback one release for FAKE:

FAKE.Deploy /rollback [server] FAKE

Rollback FAKE to 1.64:

FAKE.Deploy /rollback [server] FAKE 1.64

NUnit report watcher is looking in the root directory for the teamcity xml report.
but when working in a different workdirectory that is passed to nunit, it will store the xml report inside the workdirectory.

eg. teamcity build agent is working in this folder: "C:\BuildAgent\work\14f3cc67f56177d8"
it will launch nunit but where the workingdirectory is 'acceptancetests'.
so nunit will create the xml file here: C:\BuildAgent\work\14f3cc67f56177d8\acceptancetests\AcceptanceTestResults.xml
but unit report watcher is expecting the file here: C:\BuildAgent\work\14f3cc67f56177d8\AcceptanceTestResults.xml
so it is not finding the report.

I think the problem can be solved with a change in NUnitHelper.fs:
sendTeamCityNUnitImport parameters.OutputFile
-->
let tcNunitFile = Path.Combine(parameters.WorkingDir,parameters.OutputFile)
sendTeamCityNUnitImport tcNunitFile

it would be nice to have a zsh completion of the various tasks

one could 'setbasedir' if a pattern with a hardcoded path is detected. as of now, as the hardcoded path is not a child of the 'defaultbasedir' which happens to be whichever path the current binary runs from, enumeration fails.

I'm using white-background in terminal and I don't like default gray output.

Is it set somewhere?

toParam should add quotes if the given param contains \ or /

Fake is massively good and strong typing helps a lots for setting up stuff.
We'd need to allow easy extensibility to 3rd party component to spread that goodness around with a sound versioning system and an easy way for devs to push new helpers.

Could you have a look at this proposal please :
https://groups.google.com/forum/?fromgroups#!topic/fsharpmake/3XAQJib03RU

The idea is to :

• have each helper to become a fsx file
• each helperxxx.v1.fsx has a file helperfsxxv1.config which contains all the nugets that the file's code depends on
• the build.fsx file would then pick from the set of helperxxx.vn.fsx it needs
  #load "helperxxxvn.fsx"
  #load "helperyyyvm.fsx" etc

Then we would supply a 'faker' script (equivalent to : fake.exe fakesetup.fsx) which would enable to recursively install all nugets the build.fsx depends on upon call

This would remove the need of any specific directory like tools etc...
It would be easier to push new helper as they would not break the Fake project require recompilation / specific install etc..

For helper which depends on non nugget code, a pre-check function would be added I guess.

I get this with both Frack and Cashel:

FakePath: .\tools\FAKE\FakeLib.dll
FAKE - F# Make - Version 1.42.32.0
LocalBuild
FAKE Arguments:
("build.fsx", "1")

FSI-Path: .\lib\FSharp\fsi.exe
MSBuild-Path: c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Running Buildscript: build.fsx


error FS0193: internal error: Value cannot be null.
Parameter name: con
Press any key to continue . . .

At the moment FAKE is dependent of F# Oktober CTP.
We want to remove this and set everything up to work with the RC release.

Usually fake.exe is used as "\fake.exe" build.fsx, where build.fsx is present in the current directory. But if we navigate to fake.exe location and then provide the location for build.fsx it breaks, example entering the below in command prompt will result in an error,

c:\Fake> fake.exe "C:\work\build.fsx"

would be cool if this is fixed to accept the location based fsx files too!

Hello, I'm trying to use FAKE as continuous delivery system for the set of my apps (web sites, services, db scripts). When I integrate pushing of assembled nuget package to the server in CC.NET deployment process, and if deploy scripts for server side execution fails, is there any way to find out what went wrong? May be there's some kind of logging can be provided?

Thx in advance.

It's looking like tools\FSharp contains everything from lib\fsi.

Correct me if I don't understand the point of it.

When I type in browser's address string something like 'http://server:port/fake/deployments/', then FAKE.Deploy answers with

{
  "case": "QueryResult",
  "values": [
    []
  ]
}

But previously fake.deploy has installed my package and it's up and running and I can see it in active packages on disk under folder with packages..

At the moment only subdirectories are supported in toRelativePath

akin to what this is doing for nuget.exe

Using FAKE and love it. However, I find myself going to the source fairly frequently to figure things out. It seems to me that the documentation is mainly blog posts and the main readme on Github. Is there other documentation that I am missing?

I would like to start contributing to an effort to extend the documentation. My initial thought would be to create the forki/FAKE github wiki. We could then add a page per pre-defined task (and link this off the homepage task list).

This would help me and might increase FAKE adoption. What do you think?

Should we create http://fsharp.github.com/FAKE as the landing page for FAKE?

See the same question here about FSharpx:

fsprojects/FSharpx.Extras#101

When running build.bat, everything runs up to the tests then fails on building docs:
...
Finished Target: Test
Starting Target: BuildDocu
Building project: .\docu\Build.proj
c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe .\docu\Build.proj /target:Build /p:Configuration=Release
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.1]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

MSBUILD : error MSB1009: Project file does not exist.
Switch: .\docu\Build.proj
Running build failed.
Error:
Building .\docu\Build.proj project failed.

Build Time Report

Target Duration

Clean 00:00:00.0360124
BuildApp 00:00:32.2998481
BuildTest 00:00:15.8708876
Test 00:00:32.0909287
Total: 00:01:20.8012103
----------------F-a-k-e-.-T-a-r-g-e-t-H-e-l-per+-B-u-i-l-d-E-r-r-o-r-:- -S-t-o-p-p-e-d- -b-u-i-l-d-!- -E-r-r-o-r- -o-c-c-u-r-e
d in target "BuildDocu".
Message: Building .\docu\Build.proj project failed.
at [email protected](BuildError exn)
at Microsoft.FSharp.Primitives.Basics.List.iter[T](FSharpFunc2 f, FSharpList1 x)
at Microsoft.FSharp.Collections.ListModule.Iterate[T](FSharpFunc2 action, FSharpList1 list)
at Fake.TargetHelper.run(String targetName)
at [email protected](String targetName)
at <StartupCode$FSI_0001>.$FSI_0001.main@() in C:\Users\ryan\dev\FAKE\build.fsx:line 122
Stopped due to error
Press any key to continue . . .

I'm trying to install Fake.Deploy (downloaded from nuget) as a windows service on Win7x64 using command "fake.deploy.exe /install". I've got some undefined error during installation. When I launch Fake.Deploy as a console application using /listen key all is allright.