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 :-)

So, if you’re running off HEAD, you’ll get it in the continuous-builds’ artifacts [most-recent successful build] at the codebetter.com teamcity instance.  You can also download it from codeplex.com – I just noticed builds are published there automatically.

There are a few known issues / areas for improvement that I’ll push into the codeplex.com issue tracker from the github.com issue tracker where I was keeping them, over the next few days.  I’ll also transfer documentation from my blog to the codeplex wiki, though there is a demo-site; see MvcContrib.Samples.IncludeHandling.  But, essentially, it’s 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

• Reduce the number of external requests (or; make one big Javascript/CSS request instead of many little ones) – browsers typically will only hold two open connections per domain, and scripts load sequentially (I gather because of the possibility of document.write calls modifying the DOM, which would be a shared resource if they were allowed to load and execute in parallel).
• Reduce the size of external requests (less on-the-wire weight is better; remove comments and white-space).
• Compress external requests where possible (gzip/deflate compression will trade CPU cycles per request to gain better on-the-wire weight).
• Use a far-future cache-header for assets that won’t change often (so that clients don’t need to receive a new copy on each visit).
• Move scripts to the end of the document so the content loads first – the user has stuff to look at while scripts arrive.

Happily, all achievable with only a modicum of effort.  Yahoo has released its YUICompressor component to open-source, and there’s a .NET version available from codeplex – this takes care of minifying Javascript and CSS.  So, all we need to do is glue the files together and push that glob to the compressor.  Right?  Well, we also have to tell our component which things to work on.  This set will vary, usually, per page (ideally, we will offload all script/style to separately-loaded assets, since we can cache those and slim down our actual document at the same time by doing so).  It’s more pleasant to develop within individual files; one file per class/feature/whatever; given that we’re not perfect, it would also be invaluable to be able to turn on a debug-mode so we can debug through readable code.  

Lastly, do this stuff at run-time, because maintaining config or build-automation to do it would save some CPU cycles at the expense of developer time (can you spot someone that’s been burned by that kind of thing…? :-P ).

I’m going to be doing this within the context of ASP.NET MVC (and maybe fiddle with Spark’s modularity feature once it’s done).  My list of features:

• Register an include (from both the master-page and the views).
• Write out the include-combination (or, in debug mode, write out each include separately, raw and untouched).
• Combine the includes within the set that is registered (glue the files together – and, necessarily, read the files from where-ever they live!).
• Make it possible to link to the combination (a controller with actions to respond with the combination when tickled via an appropriate GET)
• Minify the combination.
• Compress the combination (gzip/deflate – and detect which browsers we shouldn’t do this for – I’m looking at you, IE<=6, you lying so-and-so…).
• Cache the combination with a far-future expiry (and therefore also use a URL amenable to browsers caching it).
• Generate an ETag.
• Support a debug-mode where the includes are written out one-by-one and raw.
• Be trivial to understand and add to your own application :-)

I’ll host the source in github, and blog as I go.

Some more references for front-end performance:

• CSS @import considered harmful: http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
• Hammerhead (another Firefox extension): http://www.stevesouders.com/blog/2008/09/30/hammerhead-moving-performance-testing-upstream/

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…