rake-dotnet 0.1.9
I’ve done a bit of work on rake-dotnet since the last release I blogged about (which was 0.0.8); the latest release is v0.1.9 and includes:
- 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).
July 7th, 2009 in
development, tools | tags: automation, build, continuous-integration, development, rake, rake-dotnet, tools
Nice.
I have a question though. I need to write incremental builds, where I only build and update the assemblyinfo-file for the actual projects being built.
I need to have a clean version built, specifically for testing (is everything still working if we have to build everything from scratch), but I also need my application’s different dll’s to have independent versioning. Do you know how to get this done?
I know that MSBuild can take a solution-file and then only build the projects that needs building, and in correct dependency-order. But, if I use your method and update all assemblyInfo-files surely MSBuild will consider all projects “touched”, wouldn’t it?
Thanks,
Ronny
That’s right, msbuild will consider all the projects touched. rake has the same kind of incremental build as msbuild does with a solution file – only building those parts that have source files that are newer than the file-created of the output DLL.
At present, rake-dotnet doesn’t support taking the source-control revision from anywhere other than the directory that rake is being run from. This assumption works for me, because I’ve assumed that all code lives in the same repository. I think it ought to be possible to get rdn to take the revision from each project-directory instead, when generating the AssemblyInfo files – would that meet your need? If so, I’ll open a github issue (or you could, if I’ve missed what you meant?).