Untidy.NAntTasks
- some tasks for NAnt.
Tasks:
Inno Setup | MKS Source Integrity | Version Number Tasks | Build Lock
Download:
download untidytasks.zip (28k). This includes the source and a compiled assembly to drop into your nant directory.Inno Setup Task:
This task calls the Inno Setup compiler with a setup script. The task uses the registry to attempt to find where the compiler is installed - if this path cannot be found then iscc.exe needs to be in the path. The task can also search specifically for the ISX (Inno Setup eXtensions) compiler executable.
<iscompiler filename="installer.iss" />
- Build the setup program described in installer.iss.
MKS Source Integrity Task:
This task allows you to perform common MKS SI operations such as creating a sandbox, updating a sandbox, and tagging files (or rather it will do, only sandbox is implemented currently). e.g.
<mkssi project="\\mks\sources\project1\project.pj" dir="c:\sandbox" />
- Create a sandbox in "c:\sandbox" for the project "\\mks\sourc...".
Version Number Tasks:
This is a set of tasks from reading and writing version numbers with a variety of file types. You can read/write from a resource file's (.rc) VERSIONINFO block, a simple file with a version number in it, and any type of file using a regular expression.One part of these tasks is the VersionNumber type. This type can either define a version number or read one from a source file. Any of the output file types can be used as input file types. When doing this, you can change all parts of the version number either by incrementing/decrementing them or setting them to a specific value.
You can write a version number out to several types of file (or use the version number as a string stored in a property). Each file type takes a Version sub-element which can either be a VersionNumber reference or a complete VersionNumber item. Different file types support different extra features. For example, Suffixes can be placed on the end of the version number strings for File or Product entries in VERSIONINFO blocks.
All version numbers are generally represented as major.minor.revision.build, e.g. 1.3.11.444.
Some examples of using the different tasks:
Example 1
<versioninfo filename="myproduct.rc">
<version source="VersionInfoFile" file="myproduct.rc" id="vn" build="1" />
</versioninfo>
- increment the build part of a version number read from a .rc file and then write it back to the same file. You can choose whether to update the file or product part of the VERSIONINFO structure or to update both (the default). This is set with the type parameter - set it to File, Product or Both. The task also allows you to set a suffix on either of these version fields using the filesuffix and productsuffix attributes.
Example 2
<versionnumber source="VersionNumberFile" file="myproduct.version"
major="2" id="theversion" />
<versionnumberfile filename="myproduct.version">
<version refid="theversion" />
</versionnumberfile>
<versioninfo filename="myproduct.rc" productsuffix="-internal">
<version refid="theversion" />
</versioninfo>
- load the version number from the file "myproduct.version", increment the major part by 2, and store it in both "myproduct.rc" and "myproduct.version". The version number file contains a single line with the version number surrounded in quotes.
Example 3
<version source="RegExFile" file="version.h" setversion="2.12.22.32" id="version"
regex='#define version _T\("((?<a>[0-9]+)\.(?<b>[0-9]+)\. ignore line wrap...
(?<c>[0-9]+)\.(?<d>[0-9]+))"\)"\)' />
<versionregex filename="version.h"
regex='#define version _T\("([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)"\)'>
<version refid="version" />
</versionregex>
- read the version number from a file using a regular expression, then set the version to be something completely different (yes, I'm aware this doesn't make sense, but it squeezes examples up!) and finally write the new version back to a file using a different regular expression.
There are two types of regular expression in use here. The first is the one used to find a place in a file to replace with a version number. This can either be a simple expression to match - the entire expression will be replaced - or it can be an expression with a single group in it (groups are surrounded by brackets). The group will be replaced with the version. The example above uses a group.
The second type of regular expression is the one used to read a version number from a file. This is more complicated because it has to find particular parts of the version number. Each part (major, minor, revision, build) is represented by a named group (a, b, c and d respectively). Unfortunately, .NET uses the angle-bracket symbol to name groups and this character is invalid in XML attributes. You therefore need to use the < and > replacements. You can match any form of version number with this regex.
You can also change the format that the version number is written out in by adding a format parameter to the versionregex task. The format string uses a single character to represent each part of the version number 'M' is major, 'm' is minor, 'r' is revision, 'b' is build and 's' is suffix. The suffix is specified in the optional suffix parameter. e.g. format="M.m.r-s (b)" suffix="devel"
source: included in the download, BSD-style license.
Build Locker:
This is a simple task to create a .lock file while a build is running. The lock file is removed when the build finishes. e.g.
<lock /> or <lock name="mylock.lock" />