One of my pet peeves has always been how hard it is to read the output of a build in a dos window. It is hard to navigate and with lots of output it is easy to loose content. To that end I decided to create a windows UI for FluentBuild that I just committed to source.

It still needs some work but it is there for any early adopters (click for a bigger screenshot):

While it was planned as a feature in the future, necessity bumped it up for me on my current project so I added some rudimentary FTP support.

Task.Publish.Ftp(x => x.Server(“ftp.server.com”)
.UserName(“username”)
.Password(“password”)
.LocalFilePath(@”c:\temp\test.txt”)
.Timeout(new TimeSpan(0,0,15,0))
.RemoteFilePath(“/html/”)
);

It only supports one file at a time and re-authenticates per request for now so uploading a folder structure is not recommended at this point. A more full fledged solution will be coming.

I came up with a new run syntax that I like:

Task.Run.Zip(x=>x.Compress.SourceFile(“test.dll”).OutputTo(“test.zip”));
Task.Run.Executable(x=>x.PathToExecutable(“test.exe”));

Due to the scope of the change (and the fact that I have not switched to git yet), I have committed this code but there are still a lot more changes to be polished (and some namespace moves still to be done). I hope to have some time for further refinement and a ton of cleanup after this change in the coming week.

I have completed the new build sytax of Task.Build(Using.[Compiler].[Options]); which I like way better than the old syntax. It is a bit annoying to have a few extra brackets but already makes it easier to use to me. I liked it so much that I started applying this to the Run syntax but that is where I found things did not work as well. I figured I would throw out the syntax ideas I had and see what people thought:

 
Option One: Generic run method
+simple to use
+expandable
-need to know what can be run (might be in one namespace)
-how do you handle executable return codes? (or other result objects)

Task.Run(Zip.Compress.SourceFile(“tests.dll”).UsingCompressionLevel.Ten);
Task.Run(Zip.Decompress.SourceFile(“tests.zip”));
Task.Run(Executable.Path(“test.exe”));
Task.Run(Debugger);
Task.Run(Nunit.Assembly(“tests.dll”));
Task.Run(MsTest.Assembly(“tests.dll”));

Option Two: Run narrows down choices then builders are used as arguments
+simple to use
+lets you know options available
+Allows for return codes for items that require it (or other result objects)
-much more language required to learn

Task.Run.Zip(Compress.SourceFile(“tests.dll”).UsingCompressionLevel.Ten);
Task.Run.Zip(Decompress.SourceFile(“tests.zip”));
Task.Run.Executable(Executable.Path(“test.exe”));
Task.Run.Debugger();
Task.Run.UnitTestFramework(Nunit.Assembly(“tests.dll”));
Task.Run.UnitTestFramework(MsTest.Assembly(“tests.dll”));
Option Three: Run narrows down choices to the most narrow point then builders are used as arguments
+simple to use
+lets you know options available
+Allows for return codes for items that require it (or other result objects)
+Intellisense would only give you one option for the arg to pass in
-Bit more verbose with the “Options” builders

Task.Run.Zip.Compress(CompressOptions.SourceFile(“tests.dll”).UsingCompressionLevel.Ten);
Task.Run.Zip.Decompress(DecompressOptions.SourceFile(“tests.zip”));
Task.Run.Executable(Executable.Path(“test.exe”));
Task.Run.Debugger();
Task.Run.UnitTestFramework.Nunit(NunitOptions.Assembly(“tests.dll”));
Task.Run.UnitTestFramework.MsTest(MsTestOptions.Assembly(“tests.dll”));
Option Four: Have a runners factory class that creates the builders
-need to know to do Runners.
+always know where to start (once you know to use Runners.
+simple syntax
-How do you handle executable return codes? (or other result objects)

Task.Run(Runners.Zip.Compress.SourceFile(“tests.dll”).UsingCompressionLevel.Ten);
Task.Run(Runners.Zip.Decompress.SourceFile(“tests.zip”));
Task.Run(Runners.Executable.Path(“test.exe”));
Task.Run(Runners.Debugger);
Task.Run(Runners.Nunit.Assembly(“tests.dll”));
Task.Run(Runners.MsTest.Assembly(“tests.dll”));

Let me know your thoughts or give me other options to make this simple and intuitive!

There are some features not included with the current beta but are available if you download from source.

TeamCityPlugin
This is a plugin that I wrote that allows TeamCity to work with FluentBuild. TeamCity plugins are written in Java and I am not a Java developer but it seems to work quite well in my environment(s) so far but I am still not 100% confident to officially release it.

BuildFileConverter
For my testing I was converting peoples NAnt scripts by hand and it started to get pretty tedious. I decided to create a really quick and dirty converter application. The application works fairly well to get the initial conversion from nant to FB. It will create your variables (and attempting to determine if they are BuildFolders or BuildArtifacts), initialize them, and create methods for each build target that you had. It does not parse build targets and convert them to FB syntax yet though.

BuildUI
I always found reading output on the command line was a pain so I started working on a UI component to run builds. It is in its very early stages but it is much nicer than using most command line applications I hope.

Where these features will go, I am not sure but if you want to play around with them then feel free.

For those of you that follow me on twitter (@gotwoods is my handle) you may have seen that I have been working on a new open source project called FluentBuild which I am happy to announce is in Beta. This project has kept me quite busy lately but the core of the app is now done.

FluentBuild is a .NET fluent language around builds. It makes doing builds way easier than in Nant, MsBuild, and (in my mind) other build languages. With it you can now write a build file in C# (other language support on the way) within visual studio which allows you to get intellisense, refactoring support, and you are even able to debug your build files.

The project site is http://code.google.com/p/fluent-build/

I just finished putting together a demo video. I recorded my screen at high resolution so full screen viewing is recommended and the volume recorded a bit loud so turn down your speakers to start.