Powershell

Yes, I know I whine about it a lot. But it is a step in the right direction. From a technical standpoint, it is exactly what users in the Microsoft world needed. The main reason I complain is because I like the way that unix shells work in general compared to the way windows shells do. It’s a cultural/ease of use thing. It was a welcome, though LONG OVERDUE tool.

Asp.Net MVC

Once again, a very welcome release. As I said in the last post, it still lacks compared to other MVC frameworks, but it is absolutely a step in the right direction. Maybe you will never even convince WebForms guys to use it, but at least it’s there and it seems to be taking off. You’ll never get rid of webforms from the standpoint of legacy apps that are too big/expensive to rewrite, but going forward we’ve at least got a choice.

My biggest concern with this one is that they shipped MVC2 with Visual Studio 2010. _If_ this means that ASP.Net MVC releases are going to be tied to the Visual Studio releases, they’ve just shot themselves in the foot big time.

The Big One – JQuery

Let’s face it, this was probably one of the biggest announcements MS has ever made. It (could possibly) signify a shift in MS’s stance on open source and community projects. Instead of going out and writing yet another half baked framework, they went out and found a way to package (arguably) the best one with their framework. I understand there are other frameworks out there (and have even used them), but none seems to be nearly as popular as JQuery. In fact, JQuery has basically become the Kleenex of Javascript. Often time’s we on our team will say “I’m gonna JQuery that up” or “Throw some JQuery there”. It’s a noun, a verb… whatever it needs to be for us to say “Use Javascript”.

In fact, I don’t think there would be very many open source libraries with more acceptance and use than JQuery.

Razor

Okay, so maybe I don’t get it, but it does seem a lot better than webforms. But why release it just to throw into webmatrix? Unless I’m missing something here and it’s going to be in ASP.Net MVC next week, or V3.0 (when will that get released?) then it’s ridiculous that it isn’t integrated already.

The big picture

So, though I may not exactly like all the techs I’m about to list, let’s look at them from a high level. MS now has it set up that they can offer an MVC Stack (ASP.Net MVC), a great Javascript Library (JQuery), an IoC container (Unity), an ORM (Entity Framework) and a decent command line environment to deploy it with (using psake and Pstrami if it ever comes out . Again very positive.

So why the big rant?

My biggest point in my last post was “What took so long?” I’ve heard two stories regarding why MVC came to fruition. One is that they were worried about all the MVC frameworks and finally decided to build their own. The other (way cooler) one is that the Gu was given a demo of rails at a conference and loved it so much that he wrote the humble beginnings of ASP.Net on the plane ride home.

Either way, imagine if, instead of a reactive release in 2009 we had gotten a more proactive release even in 2006? Imagine if RIGHT NOW we had in our hands what ASP.Net MVC is going to look like in 2013. Look at the other frameworks. Whenever someone gets something right, they copy it almost immediately. Imagine we had a framework like that.

Or what about entity framework. I haven’t used it yet. I don’t have a need. But in talking to people I have found that EF4 is a huge step forward. Not great yet, but not bad either. It works, but still has shortcomings. Once again, imagine if instead of a 2008 release we had something more along the lines of, i don’t know, 2006? Imagine if EF were nearly as mature as NHibernate.

All I’ve been trying to say is that MS is always late to the party and then tries to get people to push these tools when they know there are better ones out there. There may come a day when an MVP who knows both EF and NHibernate will push  EF before NHibernate (it may even happen already) but it will not be common for a few more releases of EF.

But once again the positive

All these releases seem to be coming closer and closer together now. The IIS Express, Sql Server Compact Edition, Razor announcements recently are examples of that. It seems as though MS is paying attention to the developers and seemingly even other developer communities again. If they can continue to do that and continue shoving resources towards improving the development story on Windows, things are bound to improve. Hopefully quickly.

Let’s face it, outside Visual Studio, windows development is second rate compared to everything else, and I hope they change that because I don’t want to be second rate.

I’m going to start by saying that the first part (and majority) of this post will be negative. Not the whole thing, but you’ve been warned.

With the introduction of the Razor view engine today and the subsequent very expected questioning and praise, I’m feeling the same way I do about so many releases that Microsoft has made since I’ve been a .Net developer:

At best, a little pissed off. But let’s get to that later.

Let’s start with Razor. High level, is it:

• New? Check.
• Different? A little bit.
• Ground breaking? No.
• Revolutionary? Not even close.

If you take a look at the example’s in Scott Gu’s introductory post and the examples for the Spark View Engine, you’ll see why people are commenting about the similarity.

The fact of the matter is, it’s been done. So really, why be upset when people question the use of it? It’s this attitude that starts me on my rant.

ASP.Net

Let’s start way back on January 5, 2002. Love it or hate it, Microsoft introduced ASP.Net Webforms. Whether you agree with it’s methodology or not, you can’t deny that it was:

In fact, it was so revolutionary, that it took until March 17, 2009 before they even released the ASP.Net MVC framework that acknowledged there was another point of view on web development. Now was ASP.Net MVC:

Yet there everyone the pure MS developers were finally being enlightened on what web development could be like. And we were supposed to be grateful. Grateful that literally years after other developers figured it out, MS did. Java got struts in 2000. Ruby got Rails in 2005. There’s numerous others, but to finally get to the subject of my annoyance:

WHAT IN THE F@%& TOOK MICROSOFT SO LONG?

Powershell

Yet another leap forward…. at least for the Microsoft world. How does it stack up:

• New? Nope.
• Different? A little.
• Ground Breaking? Maybe if you include the .Net Integration.
• Revolutionary? Not at all.

There’s literally hundreds of shells. Microsoft finally got up to creating a real one. Reaching at least as far back as 1971, shells have a long and storied history. Probably the most celebrated of the shells, the Bourne Again Shell (bash) was first released in 1987, and was blowing the Microsoft world out of the water in terms of usability, capability and power from even back in the days of DOS. So why is it that it took until 2006 for Microsoft to take the next step?

The obvious omissions for me are: a real history search and a preserved history. Two of the most beneficial tools in a bash user’s aresenal. Credit where credit is due though: The .Net integration story in powershell is immensely intriguing.

Are you seri-OSS?

Bad pun, I know. But the problem is so bad that the developer community has had to take it upon themselves to solve these problems and innovate themselves. There is too many for me to go into each one so I’m going to short list it:

• Entity Framework vs NHibernate
• MSTest vs NUnit, MBUnit and others
• Unity vs Structure Map, Castle Windsor
• MSBuild vs NAnt
• IIS Express vs WEBrick and Mongrel and the like

And the four point system of New, Different, Ground Breaking and Revolutionary is going to look the same for all these. Even the aforementioned items had OSS precursors (MonoRail vs MVC and cygwin/bash vs Powershell).

So why all the acclaim?

Instead of looking from the outside in, let’s take a look at these from the average Microsoft Developer who never strays from the walled garden. Every single technology mentioned would answer something like:

• New? And shiny too!
• Different? Mind bendingly so.
• Ground Breaking? I’ve never seen anything like it!
• Revolutionary? Unbelievably so!

I’ve been an avid *nix user and had at least one or more *nix based systems in my house for 10+ years. I’ve been working (very casually) on a Rails site since 2006. I was a Java developer before I was a .Net developer. To me it always feel like we finally are arriving at the party, years after everyone else.

Better late than never

Truth be told, there _is_ a bright side to all this. Microsoft is finally starting to provide their developers with tools that other platforms have had for decades. Is there a push to be more developer friendly again? I’m not sure. All I know is that finally, they are attempting to move in the right direction. This is very positive. They aren’t there yet.

In fact, currently Microsoft is playing catch up. But it seems like once you awaken the sleeping Beast of Redmond that things start to get done.

It’s not all a miss

I’ve personally used some Microsoft Techs with great success in projects. The ones that come to mind immediately to mind are Prism and WPF. Though both could be improved (we rolled our own Event Aggregator in Prism) and WPF’s INotifyPropertyChanged is frustrating, both are a great step over what we previously had.

In fact, I think that the Framework itself is, overally, extremely impressive. I love C# as a language. I enjoy it and enjoy using it. It’s in many ways, far ahead of most other static languages, combined with VS and R# it’s a dream to use too.

But…

What happens if tomorrow the python devs make some huge leap forward that no other platform has? I would put money on the Java/Ruby/etc communities to mimic it almost immediately. Probably even the .Net OSS community will get something out. But will Microsoft have to wait for “the next release cycle”?

Grateful?

I’m going to be honest, I’m not happy with being second rate. In fact, I’m downright insulted that second rate is shoved in our faces and we’re expected to act like it’s the greatest thing ever. Yes new framework X IS much better than what we’ve got, but it’s still years behind what the other guys have. It’s a classic grass is greener situation, except for that the grass is measurably greener. You want to know why so many leaders are leaving .Net? It’s because Microsoft is behind the times and seemingly refuses to outright acknowledge it until people whine, bitch and complain for YEARS.

Here’s an idea

Wow me. Let’s go back to 2002. Do something. ANYTHING. Don’t just play catch up. Take it to the next level. Be the innovator. Beat the OSS community to the punch. If nothing else, Microsoft is putting itself in the position to do so. But intentions don’t keep developers on your platform.

I’ve been saying it for the last few years: .Net is in many ways stagnant, old and behind the times.

But I couldn’t be happier if they just came out and PROVED ME WRONG.

So prove me wrong. PLEASE.

Of course, I didn’t have a generate assembly info method, so I basically took Oren’s and ported it as well (sorry Oren, I’ll take it out if you want). At the same time, I took the opportunity to remove the dependency on configatron from rubicant as well. It just seemed like overkill to require configatron when it really wasn’t buying me much.

In the end, I came up with this, which on the whole I don’t think looks too bad. I personally like it better, but I’ve been on a bit of a vendetta against PowerShell scripts since I wrote my first one some time ago. I don’t know why, but the friction it gave me over writing ruby scripts just always rubbed me the wrong way.

require 'fileutils'
require 'rake'
require 'rubicant'
include Rubicant

base_dir  = File.expand_path(".")
lib_dir = "#{base_dir}\\SharedLibs"
build_dir = "#{base_dir}\\build"
buildartifacts_dir = "#{build_dir}\\"
sln_file = "#{base_dir}\\Rhino.Mocks-vs2008.sln"
version = "3.6.0.0"
human_readable_version = "3.6"
tools_dir = "#{base_dir}\\Tools"
release_dir = "#{base_dir}\\Release"
upload_category = "Rhino-Mocks"
upload_script = "C:\\Builds\\Upload\\PublishBuild.build"
mbunit_dir = "#{tools_dir}\\MbUnit"

task :default => :release do
end

task :clean do
  rm_rf buildartifacts_dir
  rm_rf release_dir
end

task :init => :clean do

	generate_assembly_info({
		:path => "#{base_dir}\\Rhino.Mocks\\Properties",
		:title => "Rhino Mocks #{version}",
		:description => "Mocking Framework for .NET",
		:company => "Hibernating Rhinos",
		:product => "Rhino Mocks #{version}",
		:version => version,
		:cls_compliant => false,
		:copyright => "Hibernating Rhinos & Ayende Rahien 2004 - 2009"})

	generate_assembly_info({
		:path => "#{base_dir}\\Rhino.Mocks.Tests\\Properties",
		:title => "Rhino Mocks Tests #{version}",
		:description => "Mocking Framework for .NET",
		:company => "Hibernating Rhinos",
		:product => "Rhino Mocks Test #{version}",
		:version => version,
		:cls_compliant => false,
		:copyright => "Hibernating Rhinos & Ayende Rahien 2004 - 2009"})

	generate_assembly_info({
		:path => "#{base_dir}\\Rhino.Mocks.Tests.Model\\Properties",
		:title => "Rhino Mocks Tests #{version}",
		:description => "Mocking Framework for .NET",
		:company => "Hibernating Rhinos",
		:product => "Rhino Mocks Test Model #{version}",
		:version => version,
		:cls_compliant => false,
		:copyright => "Hibernating Rhinos & Ayende Rahien 2004 - 2009"})

	mkdir release_dir
	mkdir buildartifacts_dir

	cp_r "#{mbunit_dir}\\.", build_dir
end

task :compile => :init do
	MsBuildRunner.new(:properties => { :OutDir => buildartifacts_dir },
					  :project_file => sln_file).run
end

task :test => :compile do
	begin
		MbUnitRunner.new(:mbunit_dir => build_dir,
					 :test_files => ["Rhino.Mocks.Tests.dll"],
					 :report_type => 'Html').run
	rescue
		fail 'Error: Failed to execute tests'
	end
end

task :merge do
	begin
		rm_f "#{build_dir}\\Rhino.Mocks.Partial.dll"
		mv "#{build_dir}\\Rhino.Mocks.dll", "#{build_dir}\\Rhino.Mocks.Partial.dll"

		sh "#{tools_dir}\\IlMerge.exe " +
			"#{build_dir}\\Rhino.Mocks.Partial.dll " +
			"#{build_dir}\\Castle.DynamicProxy2.dll " +
			"#{build_dir}\\Castle.Core.dll " +
			"/out:#{build_dir}\\Rhino.Mocks.dll "+
			"/t:library "+
			"/keyfile:#{base_dir}\\ayende-open-source.snk " +
			"/internalize:#{base_dir}\\ilmerge.exclude"

	rescue
        fail 'Error: Failed to merge assemblies!'
	end

	puts "done merge"
end

task :release => [:test, :merge] do
	begin
		puts "Zipping files"
		sh "#{tools_dir}\\zip.exe -9 -A -j " +
			"#{release_dir}\\Rhino.Mocks-#{human_readable_version}-Build-#{ENV['ccnetnumericlabel']}.zip " +
			"#{build_dir}\\Rhino.Mocks.dll " +
			"#{build_dir}\\Rhino.Mocks.xml " +
			"license.txt " +
			"acknowledgements.txt"

	rescue
        fail 'Error: Failed to execute ZIP command'
	end
end

task :upload => :release do
	if (File.exists?(upload_script) )
		begin
			log = sh 'git log -n 1 --oneline'
			MsBuildRunner.new({:properties => { :Category => upload_category,
											   :Comment => log,
											   :File => "#{release_dir}\\Rhino.Mocks-#{human_readable_version}-Build-#{ENV['ccnetnumericlabel']}.zip" },
							   :project_file => upload_script }).run

		rescue
			fail "Error: Failed to publish build"
		end
	else
		puts "could not find upload script #{upload_script}, skipping upload"
	end
end

If you want to give this script a try (I’ve tried everything but the upload piece, which for obvious reasons I couldn’t test) just follow these steps:

1. Get a copy of the rhino mocks source.
2. Make sure you’ve got ruby installed.
3. Make sure gem is up to date: “gem update –system”
4. Add github to your gem sources: “gem sources -a http://gems.github.com”
5. Install rubicant: “gem install mendicantx-rubicant”
6. Copy the above script into a file named rakefile.rb in the rhino mocks directory.
7. Run it: “rake release”

God willing, this will work. I’ve tried it on a couple of fresh systems, but have no good way of knowing if it works beyond my machines. If you do on the offhand decide to try it, please let me know below!

The MsBuild Task is used to create tasks which will use MsBuild. This should help with people who need to build WPF applications (since MsBuild is the only way right now), or (fingers crossed) migrate from MsBuild.

The MsBuild Task is used as follows:

   1: MsBuildTask.new(:task_name => :dependencies) do |msb|

   2:   msb.no_autoresponse

   3:   msb.target

   4:   msb.logger

   5:   msb.distributed_logger

   6:   msb.console_logger_parameters

   7:   msb.validate

   8:   msb.verbosity

   9:   msb.no_console_logger

  10:   msb.max_cpu_count

  11:   msb.ignore_project_extensions

  12:   msb.file_logger

  13:   msb.distributed_file_logger

  14:   msb.node_reuse

  15:   msb.properties

  16:   msb.file_logger_parameters

  17:   msb.project_file

  18: end

Each of setters matches a command line option for MsBuild. For more information on what each one does, please view the documentation at http://msdn.microsoft.com/en-us/library/ms164311.aspx.

Values that can only be set (for example, /noautoresponse) can be set to true (set) or nil (unset).

Values, such as /property that take a list of option settings, must be passed a hash where the keys are the options and the values are the option values. For example, to set the output directory and Warning Level for a csproj compile, you could use:

   1: MsBuildTask.new(:compile) do |msb|

   2:   msb.properties = { :OutputDir => ".\\Output", :WarningLevel => 2 }

   3:   msb.project_file = ".\\Project1\\project.csproj"

   4: end

As of yet, I haven’t added an MsBuild helper to help create this function. I will probably get this done fairly shortly.

In addition, you can also install rubicant via gem:

   1: gem sources -a http://gems.github.com

   2: sudo gem install mendicantx-rubicant

You should only ever have to run the gem sources command once. This adds github to your sources of remote gems. From what I understand, there’s a ton of great projects there.

Now you don’t have an excuse to try it out!

Rubicant basically has 4 main parts, as mentioned in the first part of this series. They are as follows:

The CscTask

The CscTask is used for compiling C# files. It’s usage is like:

   1: CscTask.new(:task_name => :dependencies) do |csc|

   2:   csc.target = 'library'

   3:   csc.references = FileList["libs\*.dll"]

   4:   csc.out = "hello_world.exe"

   5:   csc.debug = "full"

   6:   csc.files = FileList["src/**/*.cs"]

   7: end

target: Any target that the csc compiler takes (exe, winexe, library, etc)

references: The list of assemblies that are referenced during compilation

out: The output filename

debug: if this is set(to anything), the compiler will be passed /debug:full to create debugging information

files: The list of files to be compiled

CscTask also has a shortcut that can be accessed as follows:

   1: csc(name, dependencies, opts)

   2:  

   3: ex:

   4: csc :name, [:dependencies], { :target => 'library',

   5:                               :references = FileList["libs\*.dll"],

   6:                               :out = "hello_world.exe",

   7:                               :debug = "full",

   8:                               :files = FileList["src/**/*.cs"] }

The MBUnit Helper

The MBUnit helper is used to run tests using mbunit v2. It is used as follows:

   1: mbunit(mbunit_dir, test_dir, test_files, opts={})

   2:  

   3: ex:

   4: mbunit("/path/to/mbunit/dlls",

   5:         FileList["/test/dlls/test.dll"],

   6:         {:working_dir => "/dir/to/run/tests/in",

   7:          :assembly_path => FileList["/assemblies/to/include/*.dll"],

   8:          :report_folder => "sets /rf:",

   9:          :report_name_format => "sets /rnf:",

  10:          :report_type => "sets /rt:",

  11:          :show_reports => "sets /sr:",

  12:          :transform => "sets /tr:",

  13:          :filter_category => "sets /fc:",

  14:          :exclude_category => "sets /ec:",

  15:          :filter_author => "sets /fa:",

  16:          :filter_type => "sets /ft:",

  17:          :filter_namespace => "sets /fn:",

  18:          :verbose => "sets /v{optionvalue}",

  19:          :shadow_copy => "sets /sc:" }

For a complete listing of the mbunit command line options, please visit http://docs.mbunit.com/help/html/gettingstarted/MbUnitConsoleRunner.htm.

This runs the tests in test_files in the test_dir with the dlls from mbunit_dir using the options in opts. Currently, this will physically copy the minimum required mbunit dlls and mbunit.cons.exe to the test dir, run the tests and then remove the files.

The CopyFiles Task

The copy files task will copy files from one directory to another, while maintaining the folder structure.

   1: CopyFiles.new(:name) do |cf|

   2:   cf.base_dir = "/some/dir"

   3:   cf.file_globs = ["**/somefiles/*.cs", **/otherfiles/*.cs"]

   4:   cf.target_dir = "/another/dir"

   5:   cf.excludes = ["AssemblyInfo.cs"]

   6: end

base_dir: The base directory to start copying files from

file_globs: The globs of files to be copied from base_dir

target_dir: The target directory to place the files in

excludes: (Optional) list of files to be excluded from the copy.

The Expand Template File Task

Usage is:

   1: expand_template(template, output_file)

This will read in the file specified by template and expand it out and write it to the location of output_file.

WARNING: I am fairly certain that the only reason this is working right now for me is because I use configatron, which is accessed as a singleton. It is entirely possible that variables declared in your build script will not be accessible during template expansion. I will be testing this in the near future, however.

Framework Selection

Currently, only the .Net 2.0 and .Net 3.5 frameworks are configured. .Net 3.5 is the selection by default. However, you can choose which framework you want to use by adding framework={framework} in the build line. For example:

   1: rake deploy_local framework=net20

This will run the deploy_local task in the default rakefile using the .Net 2.0 framework.

Valid framework values are:

net20 – .Net 2.0

net35 - .Net 3.5

These frameworks are discovered using the registry, so you shouldn’t have to put in the location of your csc.exe file.

What else?

Well, that’s about all it really does right now. The rest is just built in rake and ruby goodness. I would like to add msbuild support for those that are building WPF apps. I would also like to add some nunit support, as well as some support for other things like easy creation of assemblyinfo.cs files and possibly some deployment tasks for iis7. Who knows. We’ll see how I like things and if I really take to using this (I think I will).

Alright, so here is a sample build script for rubicant. First you will have to get rubicant installed. To do that, you need to get the source from https://rubicant.googlecode.com/svn/trunk/. I believe the username is rubicant-read-only.

In the root directory type:

   1: E:\projects\rubicant>rake gem

   2: (in E:/projects/rubicant)

   3: c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake/gempackagetask.rb:13:Warning:

   4:  Gem::manage_gems is deprecated and will be removed on or after March 2009.

   5: mkdir -p pkg

   6: WARNING:  no rubyforge_project specified

   7: WARNING:  RDoc will not be generated (has_rdoc == false)

   8: WARNING:  deprecated autorequire specified

   9:   Successfully built RubyGem

  10:   Name: Rubicant

  11:   Version: 0.0.1

  12:   File: Rubicant-0.0.1.gem

  13: mv Rubicant-0.0.1.gem pkg/Rubicant-0.0.1.gem

  14:  

  15: E:\projects\rubicant>

Now you’ve got the gem built, you just need to install it:

   1: E:\projects\rubicant>gem install pkg\Rubicant-0.0.1.gem

   2: Successfully installed Rubicant-0.0.1

   3: 1 gem installed

   4:  

   5: E:\projects\rubicant>

There. Now for a test application. Suppose we’ve got 3 projects that make up a console app. The UI, the Engine (I KNOW) and the Tests. They look like:

For now, let’s ignore the internal workings and focus on building it.

The build script looks like this:

   1: require 'rubicant'

   2: require 'configatron'

   3: include Rubicant

   4:  

   5: BASE_DIR = File.expand_path(".")

   6: SRC_DIR = "#{BASE_DIR}/src"

   7: SRC_APP_DIR = "#{SRC_DIR}/app"

   8: SRC_TEST_DIR = "#{SRC_DIR}/test"

   9: CONFIG_DIR = "#{BASE_DIR}/config"

  10: BUILD_DIR = "#{BASE_DIR}/build"

  11: DEPLOY_DIR = "#{BASE_DIR}/deploy"

  12: TOOLS_DIR = "#{BASE_DIR}/tools"

  13: MBUNIT_DIR = "#{TOOLS_DIR}/mbunit"

  14: RHINO_DIR = "#{TOOLS_DIR}/rhino"

  15:  

  16: UI_SOURCES = FileList["#{SRC_APP_DIR}/Rubicant.Test.App.UI/**/*.cs"]

  17: ENGINE_SOURCES = FileList["#{SRC_APP_DIR}/Rubicant.Test.App.Engine/**/*.cs"]

  18: TEST_SOURCES = FileList["#{SRC_TEST_DIR}/**/*.cs"]

  19:  

  20: #### Build Initialization

  21: task :initialize_build do

  22:     rm_rf BUILD_DIR if File.exists?(BUILD_DIR)

  23:     mkdir_p BUILD_DIR

  24:     rm_rf DEPLOY_DIR if File.exists?(DEPLOY_DIR)

  25:     mkdir_p DEPLOY_DIR

  26: end

  27:  

  28: #### Loading Properties

  29: task :load_local_properties do

  30:     configatron.configure_from_yaml("local.properties.yml")

  31: end

  32:  

  33: task :load_test_properties do

  34:     configatron.configure_from_yaml("test.properties.yml")

  35: end

  36:  

  37: #### Deployment Targets

  38: task :deploy_local => [:load_local_properties, :deploy]

  39:  

  40: task :deploy_test => [:load_test_properties, :deploy]

  41:  

  42: task :deploy => [:test, :expand_app_config] do

  43:     cp FileList["#{BUILD_DIR}/{hello.exe,engine.dll}"], DEPLOY_DIR

  44: end

  45:  

  46:  

  47: #### Compile Targets

  48: csc :compile, [:initialize_build, :compile_engine], {:files => UI_SOURCES,

  49:                                                      :target => "exe",

  50:                                                      :out => "#{BUILD_DIR}/hello.exe",

  51:                                                      :references => FileList["#{BUILD_DIR}/*.dll"] }

  52:                 

  53: csc :compile_engine, [], {:files => ENGINE_SOURCES,

  54:                           :target => "library",

  55:                           :out => "#{BUILD_DIR}/engine.dll"}

  56:                 

  57: #### Testing Targets                

  58: task :test => [:compile_tests, :run_tests]

  59:  

  60: csc :compile_tests, [:compile], {:files => TEST_SOURCES,

  61:                                           :target => "library",

  62:                                           :out => "#{BUILD_DIR}/tests.dll",

  63:                                           :references => FileList["#{BUILD_DIR}/**/*.{dll,exe}", "#{RHINO_DIR}/*.dll", "#{MBUNIT_DIR}/*.dll"]}

  64:  

  65: task :run_tests do

  66:     mbunit(MBUNIT_DIR, BUILD_DIR, FileList["#{BUILD_DIR}/tests.dll"], {:assembly_path => FileList["#{BUILD_DIR}/engine.dll", "#{RHINO_DIR}/*.dll"].to_a})

  67: end

  68:  

  69:  

  70: #### App.config expansion

  71: task :expand_app_config do

  72:     expand_template "#{CONFIG_DIR}/App.Config.template", "#{DEPLOY_DIR}/hello.exe.config"

  73: end

The point of this build file is to be able to churn out two different builds based on two different sets of properties. This is based off of my builds that I do at work where we need to deploy and test in a test environment before going into production. It would be as simple as adding a production.properties.yml and a deploy_production target to simulate this fully in this script.

So basically, we call deploy_test (or deploy_local), which in turn loads the test properties, and then the deploy task.

Deploy calls the test task, which builds the app, builds the tests, runs the tests. If any tests fail, the build will fail here, making sure we don’t deploy any code that doesn’t pass tests.

Finally, we expand our app.config in a way suitable for the environment we’re going into.

Finally, run the executable to see that it worked!

   1: E:\projects\Rubicant.Test.App>deploy\hello.exe

   2: Hello, World! (Test Version)

   3:  

   4: E:\projects\Rubicant.Test.App>

You can download the source from http://blog.beigesunshine.com/wp-content/uploads/2009/01/rubicanttestapp.zip and try it out for yourself. The default rakefile goes to an exe and an assembly. You can also run both deploy_local and deploy_test and create a single exe file by using rake -f rakefile_single_exe.rb deploy_local.

Coming up, a post on some of the specifics of rubicant.

In previous posts I have mentioned that I think that there might be a better way to automate builds than NAnt. I also mentioned that I had looked at a few of them and been mostly underwhelmed. I’ve spent a large amount of time building a process for builds that works well for me and none of them seemed to erase my pains.

I also mentioned that I would be working on some items that may even drive some content to this blog, among other things. Today, I introduce the fruits of my labour.

Please note that this is NOT recommended for any sort of production environment. It is currently at best a way to try out Rake on .Net projects.

What is rubicant?

rubicant is my own personal set of tasks that sit on top of rake, a rubyish interpretation of make. I’ve used ruby for some scripting in the past, and also used rake in a rails app that I developed. I felt that the combination of both would alleviate some of the pains that I (and I’m pretty sure I’m not alone here) feel when I use NAnt.

I was admittedly scared to even try building my own set of tasks, and actually didn’t even know where to start. I kept rolling the idea around. One day I was going to start doing it now. Then the next I wasn’t. As a father of young children my spare time is very limited and very few and far between, especially for something that would demand so much of it.

And then the I started coming across others experimenting with exactly what I was talking about. First it was a post by Dave Laribee, as well as another post in his comments. And now as I read over them again, I’m seeing that there’s more people feeling like I do. I started to google and found some great posts by Jay Fields and to a lesser extent one by Martin Fowler.

Anyway, in my looking it seemed like no one had actually put out a reusable library that anyone could just pick up and automatically compile a project within 5 minutes.

And thus, with some much needed inspiration from the above sources, rubicant was born.

What isn’t rubicant?

Well written for one thing. Take a look at my tests and they’re enough to make someone blow a gasket (I kid, I LOVE his twitter rants) I started writing them thinking I knew what I was doing and let me clear something up for you. At the time, I had a greatly misguided view on BDD/Specification testing. Either way, it’s still got my code covered and has helped to drive out some of the design, especially when loading framework information.

Another thing it is not is a complete solution. I had 4 goals in functionality that I wanted. They were:

1. Build C# code
2. Test C# code (with MBUnit)
3. Copy selected files in a meaningful hierarchy
4. Template expansion using configatron to allow for easy configuration swapping.

Why rubicant?

First off, automated builds are the only thing that I feel I truly have a grasp on. I feel comfortable enough in myself and my process that I could come up with something useful. I don’t think of myself as a guru, but I do know that I have a set of build scripts at work that are robust and involved while trying to stay (somewhat simple). In other words, I don’t consider myself a guru, but I do feel I have a grasp on the subject.

I was also feeling too much pain with NAnt. As well, I didn’t feel that any of the other solutions out there really felt like what I was looking for. I was also looking for a learning project in ruby. I wanted to try driving out a design via testing using ruby. A lot of things. Either way, I felt like I wanted to do something for myself, but that also might provide some sort of benefit to the community, even if it just ended up as a failed attempt. In a sentence: I wanted to try and provide SOMETHING back to a community that I feel has given me so much.

Even if this ends in failure, it’s been exactly the experience that I’ve wanted thus far, and though I’m sure I’m in for some rough waters ahead, I think that it will continue to drive me to learn, improve and better myself. Okay, so there is definitely some selfishness there, but hopefully you can forgive me in the name of Continuous Improvement, even if it’s my own.

How do I get it? How do I use it?

Well, if you want to get it, you can go to the project site on google code and download the source. There are instructions there on how to install it. As for how to use it… stay tuned for a sample project and build file. Hopefully very soon.

Update: Don’t forget to check out Part 2 and Part 3.

Let me get this off my chest. I think about Build Scripts all the time. I spent the better part of the first 6 months at my current job migrating old legacy .Net 1.1 web apps from  CVS to .Net 2.0 and Subversion. Part of that included migrating the projects from CVS to SVN, then taking the old projects and migrating those into our current directory structure for projects. After that, I had to template the config files and create build scripts that could build a local, test or production version of an app with a single command.

During the course of this, I used PowerShell, Ruby and of course, NAnt.

I found that, like many things, I was able to find some things I loved about all of them. And lots of things I hated about most of them. PowerShell, for one, has some great ideas in it. It’s truly a good idea. I love the idea of being able to leverage the .Net Framework from my scripts. It really is a good idea. But after the few scripts that I wrote in PowerShell, I don’t think that I could use it again. I found the syntax either annoying or clunky the whole time. Especially once I started writing the scripts in Ruby.

Now Ruby I have some experience in as I’ve done a bit of Rails development. Lots of the notations I like. I have some difficulty in using a dynamic language at times, most notably I find myself missing method signatures that are strongly typed. However, the annoyances are small, and mostly come in the form of me running into issues with working with the file system. I think those annoyances mostly come from me not fully understanding some of the intricacies of working with the filesystem on windows with ruby.

I find the biggest difference between the two is how easy it is to use Ruby from within a CygWin Bash shell. I’ve been a longtime linux user, and actually my first unix-like operating system that I used at home was FreeBSD. Because of FreeBSD, I was a long time user of tcsh. In fact, it was less than a year ago that I finally made the move over to bash. Either way, both of these shells provide power, ease of use and so many advantages that I can’t believe that Microsoft doesn’t have them in any of it’s shells. I mean seriously, how does anyone live without a searchable history in a command prompt?

And this brings us to NAnt. I was in love with NAnt when I first started. It was great to use, simple and it could do so much. But I started to find myself hitting situations where things would become very murky and difficult to keep track of where things were happening, especially when I tried to make things generic so they could be called in many places. For example, here is how a template file is expanded in our code:

   1: <target name="expand.template.file">

   2:     <copy file="${template.file}.template" tofile="${template.file}" overwrite="true">

   3:         <filterchain>

   4:             <replacetokens>

   5:                 ....lots of tokens...

   6:             </replacetokens>

   7:         </filterchain>

   8:     </copy>

   9: </target>

But where does ${template.file} get set? Why, the line before we call expand.template.file of course!

   1: <property name="template.file" value="${some.dir}\app.config"/>

   2: <call target="expand.template.file" />

I just find that this can be confusing, especially to newcomers who don’t know which targets act as functions. I know that you could do a search through the code and find it, but it’s just not as clean or explicit as something like:

   1: expandTemplate(filename)

   2:  

   3: def expandTemplate(filename)

   4:     ...expand in here...

   5: end

So I think that you can see where I’m going with this. After a while of doing this, I started to think a lot about Rake. After all, I had used it in Rails projects previously. As you can tell, I’m quite a fan of Ruby. After a while, things began to cool off. I had gotten almost all of our projects converted and I wasn’t writing build files as much anymore. But I kept on thinking about it. Recently, I’ve been writing build files again. I’ve also been reading that I’m not the only person who feels this way.

I’ve noticed a few projects that seem to be reaching for what I want. There’s Boo Build System (and yes, it is shortened to BooBS. Nice work Ayende), PSake (which JP seems to have picked up) and then there’s Rake. Rake seems to be the only one that isn’t geared towards some sort of .Net problem (not that it can’t). It turns out that though there was a lot of hype around boo a while back, I just don’t think it’s something I’m up for learning just yet. And as for PSake, I downloaded the source and nothing against James (it’s not his fault, it’s the syntax!) I barely made it through the first PS1 file before my head hurt and I remembered why I stopped writing PowerShell scripts in the first place.

That leaves me with Rake. And it seems like I’m not the only one. The only difference is that I would absolutely love to see a Gem built with some custom .Net tasks for rake. This is something that I’ve been seriously contemplating putting some time into, but haven’t fully explored yet. Most notably, I would like to take the syntax of:

   1: require 'lib/nunittask'

   2:  

   3: Rake::NUnit.new do |nunit|

   4:   nunit.library = "foo.dll"

   5: end

And replace it with something along the lines of:

   1: require 'lib/nunittask'

   2:  

   3: nunit :test, :library => 'foo.dll', :depends => [:load_properties, :compile]

I get the feeling that this could be wrapped up in a function which could use Hash which could hide away the nastiness of Rake::Task.new do |task| block and take these scripts to an entirely new level. I’m not entirely sure how the naming would work, but I’m sure it would.

After writing this, I think I’m going to start taking a much closer look. Has anyone heard of anything like this in the works/already released?