1. Jump onto an agent machine
2. Open up {agent-install-dir}\plugins\dotnetPlugin.zip\bin
3. Pull out JetBrains.TeamCity.NUnitAddin-NUnit-2.5.3.dll and .pdb
4. Drop those into your {nunit-in-source-control}\bin\net-2.0\addins directory in source-control
5. Commit
6. Marvel at the per-test reporting that then happens (because a build will kick off)

Thanks to John Leger for getting me most of the way there :-)

• CHANGE: Xunit.NET – cope with v1.5 release which packages an x86 console runner as well as x64 one, in combination with wanting to run x86 one if it exists because of WatiN seeming to not be happy running under x64.
• FIX: Versioner: Replace the RDNVERSION constant with calls to Versioner.new.get
• CHANGE: Added version task for convenience
• FIX: Versioner: Need to make the version.txt file a file-task, so assembly_info can depend on it.
• FIX: Versioner: Cache the version number to a file, so CI can pull/push it and maintain same version number throughout CI pipeline stages

• NEW: MsBuild: Can now take arbitrary properties list
• NEW: MsBuild: Default to treating warnings as errors, as stringently as possible
• NEW: MSBuild – support for building VB.NET and WiX projects
• NEW: AssemblyInfo – support for generating AssemblyInfo.vb into {project}/My Project/ (which I hope is the by-convention place)
• NEW: RDNPackageTask – generate a named task per package so they can be built individually
• NEW: SevenZip – wrapper for extracting an archive
• NEW: NCover: Generate the full-coverage report
• NEW: Add the ability for ncover.reporting to generate more than one report at a time
• NEW: Add FxCop -> TeamCity code-inspections reporting via TeamCity’s service-messages feature
• NEW: If VERBOSE=true is passed on the command line, command-line calls will get echoed before they’re run (otherwise, they get ellipsis’d by rake’s error tracing, which doesn’t let one see the arguments)
• NEW: clobber_fxcop will kill off the fxcop report in isolation
• CHANGE: SevenZip – wrapper is more useful ;-)
• CHANGE: MsBuild; use constants rather than hard-codings for verbosity of output and source-directory
• CHANGE: Harvesters – harvest dumps output into a config-version named directory now
• CHANGE: NCover: Ignore ISymWrapper assembly by default; seems to be an NCover artefact
• FIX: When TeamCity build-configs are out-of-sync, number-wise, we cannot rely on RDNVERSION to be a sensible default.
• FIX: Initialise bin_dir to correct defaults
• FIX: FxCop – support for running against .exe files instead of just DLLs.  Exclude *.vshost.exe by default
• FIX: NCover: Exclude-assemblies can be an array
• FIX: NCover: Implement working-directory on ncover so it executes from the same location as the DLLs it’s using a tool to profile
• FIX: If BUILD_NUMBER environment variable is not a number, use 0 (since only numbers are valid to the AssemblyFileVersion and AssemblyVersion attributes)
• FIX: Automatically create {project}/Properties directories when generating AssemblyInfo.cs files (git does not version empty directories)
• FIX: Detect processor architecture from environment variable rather than require user to figure it out and pass it in.
• FIX: make get_tools_dir correctly return the path instead of just think about it.

There’s currently one known bug; the fact that output is put into non-friendly-to-type paths (this doesn’t interact with CI well).

Perhaps this is the beginnings of an answer…?  I doubt it, but I still think it’s a cool feature-request ;-)

While we’re on the subject of Dear-JetBrains-Please-Fix, how about any of the following…?

• Formatting fluent-interface & lambda C#
• Don’t overwrite user-settings when more than one Visual Studio is opened then closed
• Naming conventions different for tests
• Make camel-humps work in dialog windows
• Don’t allow fonts/colors settings to change and the color-classes disappear

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

=== 0.0.8 / 2009-?
 
* CHANGE: Eliminate the need to pass stuff to AssemblyInfoTask when it can just use the defaults ... by default.
* FIX: Bug with harvesting when output contains directories
* FIX: Test-runner now executes from within the same directory as the DLL(s) containing tests that it's running through.
 
=== 0.0.7 / 2009-04-15
 
* CHANGE: Adjust TOOLS_DIR initialisation so it looks for a shared 3rdparty folder at the same level as the product folder first, then it looks for a 3rdparty folder inside of the product folder.
* CHANGE: Adjust the Demo's Rakefile to make FxCop ignore assemblies with "Tests" in their filename.
 
=== 0.0.6 / 2009-04-06
 
* Move source control to github at http://github.com/petemounce/rake-dotnet
* Change format of readme to markdown for prettiness on the repo homepage
* FIX: YYYYMMDD is invalid for file/assembly-version attribute; use '0' instead in non-svn source-control case.
* FIX: Fix harvesting a web-application when it's not under svn source-control

What’s next? The nice people at NCover have granted me a free license to their code-coverage tool; I’ll be wrapping that in the next major release. I also plan to implement tasks for NUnit and Gallio. That should do for planning, for the time being…

Oh – it occurs to me that I’ve talked about it, but not really shown what it allows (though there is a demo inside of source-control -> DemoRoot). So, here’s the ~35 line Rakefile that gets you:

• AssemblyInfo watermarking
• compilation
• XUnit.NET testing/reporting
• FxCop reporting
• simple NCover reporting (as in, only one report choice at the moment)
• harvesting-to-one-place for publishing to CI artifacts
• packaging output into zip files for xcopy-deployment (even if xcopy is so … DOS… ;-) )

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# Documentation: http://rake.rubyforge.org/ -> Files/doc/rakefile.rdoc
require 'rake'
require 'rake/tasklib'
require 'rake_dotnet'
 
PRODUCT_NAME = ENV['PRODUCT_NAME'] ? ENV['PRODUCT_NAME'] : 'IncludeCombiner'
COMPANY = ENV['COMPANY'] ? ENV['COMPANY'] : 'NeverRunWithScissors.com'
RDNVERSION = Versioner.new.get
 
Rake::AssemblyInfoTask.new
bin_out = File.join(OUT_DIR, 'bin')
Rake::MsBuildTask.new({:verbosity=>MSBUILD_VERBOSITY, :deps=>[bin_out, :assembly_info]})
 
Rake::HarvestOutputTask.new({:deps => [:compile]})
 
Rake::XUnitTask.new({:options=>{:html=>true,:xml=>true}, :deps=>[:compile, :harvest_output]})
Rake::FxCopTask.new({:deps=>[:compile, :harvest_output]}) do |fxc|
	fxc.dll_list.exclude("#{@suites_dir}/**/*Tests*.dll")
end
Rake::NCoverTask.new({:deps=>[:compile, :harvest_output], :ncover_options=>{:arch=>'amd64'}, :ncover_reporting_options=>{:arch=>'amd64'}})
 
demo_site = File.join(OUT_DIR, 'Demo.Site')
Rake::HarvestWebApplicationTask.new({:deps=>[:compile]})
 
Rake::RDNPackageTask.new(name='bin', version=RDNVERSION, {:deps=>[:harvest_output, :xunit]}) do |p|
	p.targets.include("#{bin_out}/*")
end
Rake::RDNPackageTask.new(name='Demo.Site', version=RDNVERSION, {:deps=>[:harvest_webapps, :xunit]}) do |p|
	p.targets.include("#{demo_site}/*")
end
 
task :default => [:compile, :harvest_output, :xunit, :package]

The Rakefile is from the other thing I’m working on at the moment while I’m at a loose end. Watch this space…

So I’ll explain a few of the design decisions I made when working on rake-dotnet.

Firstly, hopefully the aim to keep the Rakefile as short as possible is understood and well-received. I wanted it to be as by-convention as possible, because honestly, writing a build-script for the 80% case is surely pretty much a solved problem by now; conceptually, at least. It’s often making time to do it that’s the hard part, right?

Secondly: Why isn’t the Rakefile in the root, next to the solution file, so I can just type rake and have stuff happen? I need to cd build; rake before I see stuff! I did this because of the way TeamCity (TC) and subversion (svn) work together. In TeamCity you set up a Version Control System (VCS) root. The simplest thing is one pointed at the trunk of your codebase, so it gets everything. You can customise the VCS roots by telling TC to only check out paths matching some rules you tell it, or omit externals, and some other tricks. However, it doesn’t check out lazily, it checks out greedily (as at 4.0.2 anyhow). Say you set up the VCS root {svn}/trunk and a checkout rule to skip {svn}/trunk/foo – it’ll check out everything from {svn}/trunk and then, afterwards, delete the foo directory. This takes time – at my place, we’ve got a modest project, but sadly a slow svn server – the checkout takes more time than the do-work part of the build.

A bit of background. For this project, we have one svn repo for the code that we write, and one for the 3rd-party libraries, tools, code, and other artifacts that we depend on to produce a build. This keeps the size of checkouts smaller for remote staff over the VPN (which is also not the most robust), and backups quicker (since we make fewer changes to the 3rdparty repo, we back it up less frequently, especially since it’s not complicated to reconstruct because we’ve got commit emails of what changes happened to it). We also only have the one NCover license, which is installed on just one TC build-agent – this means our setup can’t just run all the build-tasks from beginning to end, since the other two agents don’t have an NCover license. So, TeamCity isn’t set up in the simplest-way-that-works. A build project has a number of build configs:

• Continuous (in Debug configuration) (this will generate AssemblyInfo.cs files, compile, run unit-tests, harvest the artifacts, and publish them to the CI server for later configs’ use)
• Coverage
• FxCop
• TeamCity Duplicate Finder
• Continuous (in Release configuration)

It would be easy to see that later we’d also want:

• Integration Tests
• NDepend
• Deploy to test environment
• UI Test
• Deploy to production
• Notify clients of new functionality drop :-)
• etc

As I say, running end-to-end in each build-configuration on each agent is not only not possible, it’s wasteful. It’s also wasteful to hammer our feeble little svn server for a full checkout of stuff we don’t need during subsequent stages (we don’t need the source-code if we’ve got a convenient zip file of all the build output already, right?). Fail fast. So, how? VCS roots. The table below describes how I’d set up the rake-dotnet Demo product in TeamCity (assuming the rdn FxCop task didn’t have a bug in it that I need to fix ;-) ).

(or as HTML: [download id="3"])

What all of this effort lets us have is a config up front that does the basics (compile, unit-tests-that-are-fast, package, etc), then pushes that up to the CI server; the process then branches out into parallel-building by taking advantage of the fact that TeamCity gives you 3 agents for free.  Each config pulls down the DLLs etc that the first one generated, and runs off them.  The subsequent configs will run in parallel, then the Continuous-Release one will run if all three of the Order-2 ones pass.

Now, if only I could get the git plugin to work.  No joy, so far.  Git renders some of this irrelevant, because its checkout speed is so much faster that svn’s (in our environment, at any rate).  Another day…

• AssemblyInfo generation – generate assembly-info files that pull in:
  • product name
  • company name
  • build configuration
  • build date
  • version number (major.minor from a text file; build from an environment variable (or 0 if not build with CI), revision from svn working copy).

  This task will overwrite Properties/AssemblyInfo.cs in each project within the source directory, either from a template side-by-side to it, or from the common template in the source directory.  If source-control is other than Subversion, revision number is replaced as YYYYMMDD of the current date.  If the script is run locally, build-number will not be set (since this environment variable comes from TeamCity, or another build-server).

• MsBuild compilation – compile projects using MsBuild.  Vary the output verbosity and the configuration.
• Harvest the output to an all-in-one directory, for later packaging for convenience of artifact-publishing to a build server like TeamCity.  This enables parallelisation, because we can push out the artifacts to other agents to process their own tasks against (farming out separate test suites or coverage processing, for example).
• Harvest web-applications to a directory each for later packaging for deployment convenience.
• Run XUnit.NET fixtures and generate reports
• Run FxCop and generate a report
• Run NCover to generate coverage data, and run NCover.Reporting to generate reports off that data (currently, just one report type of many in v3)
• Package up output for publishing to build-server artifacts.  The conventions are set up with a build-server distributed build in mind.
• All of that in a Rakefile that is currently less than 40 lines long :-)

So; I’ve wrapped up what I’ve done in a ruby gem; you can install it:

• First get ruby; running the installer with defaults is fine
• At a command-line: gem install rake-dotnet --include-dependencies (prepend ‘sudo’ if you’re not on Windows).
• Get a whole bunch of tools – see the gem’s README.txt for details (gems are installed under {ruby}/lib/ruby/gems/{ruby version}/gems/.
• svn checkout http://my-svn.assembla.com/svn/nrws/trunk/rake_dotnet/lib/DemoRoot to see the demo project.
• Populate the 3rdparty tools directory (inside DemoRoot) according to the readme.txt within (I plan to make this easier…).
• Try out the demo by changing into its build directory and running rake from the command-line.  rake -T will give you a breakdown of available tasks.

The tasks assume conventions for things like tools-location and solution layout.  So until I document those properly with rdoc (on my list of things to learn, right after unit-tests in ruby!), here they are:

• PRODUCT_ROOT defaults to .. – rake’s working directory is build/, where Rakefile.rb is used.  All paths are relative to the rake working directory.
• OUT_DIR defaults to out, hence equivalent to #{PRODUCT_ROOT}/build/out – build-output gets squirted here.
• SRC_DIR defaults to #{PRODUCT_ROOT}/src –  buildable projects should live here (this includes test projects).  One directory per project, directory-name matches project-filename matches generated assembly-name.
• TOOLS_DIR defaults to #{PRODUCT_ROOT}/../3rdparty – intentionally, tools are kept outside of the source tree.  This allows for efficient xcopy deployment, or a source-control symbolic link arrangement (svn:externals works well).
• test projects should have “Tests” somewhere in their project-name.
• web-application projects should have “Site” somewhere in their project-name.
• msbuild is assumed to follow its defaults and output into {project-being-built}/bin/{configuration} for class libraries and so forth.
• Each project directory within SRC_DIR is assumed to have a Properties directory where AssemblyInfo.cs in generated. The template for this file is taken either from a side-by-side AssemblyInfo.cs.template file, or #{SRC_DIR}/AssemblyInfo.cs.template

The Demo solution is set up with these in mind, obviously.  They are possible to override to some extent by passing constants via the command-line like rake MSBUILD_VERBOSITY=n CONFIGURATION=Release TOOLS_DIR=../tools.

Source code is available, of course.  I have yet to figure out rubyforge for a project home-page and announcements, rdoc for documentation, and ruby unit-tests for ensuring quality.  There’s a roadmap in the readme; next major release will be 0.1.0 and will see more in the way of test coverage, nunit support, and more ncover reports (I have to do these within the 21-day trial license, I think…).  I am also likely to move the source control to github, since I’ve been wanting to learn git, too…

There’s a whole different mindset to using a Mac.  I know, I know; “It just works” has surely been beaten to death (even though it’s pretty accurate).  The best way that I can articulate it is, well, you need to unlearn thinking complicatedly.  

Case in point – I inserted a DVD into the front of my MacBook Pro.  There’s no obvious way to eject it (having been conditioned to expect a little plastic eject button next to the slot, like on a PC), when it doesn’t mount (normally, it auto-mounts, and you special-click on the icon and click eject).  So, off to google – “how to eject dvd from macbook pro” – I plaintively type.  Several answers:

• Hold down the trackpad button during bootup (I don’t want to reboot right now!  How insane!)
• Power up the Mac and leave it alone for 10min (again.  And, how does it decide it should eject the DVD?)
• … press the eject key on the keyboard

Um.  Right.

It turns out “simplest thing that could possibly work” is still just not inside my tunnel vision, sometimes…