A quick trip to Les Schwab fixed me up, but that was $50 worth of battery I really wasn’t prepared to spend over lunch. And it doesn’t enhance my mood any. Could’ve been worse, I suppose. Might have been a starter or alternator or something. Then again, the day ain’t over yet.
I use NAnt to do my automated builds both at home and at work. As such, I decided to start keeping a little library of custom NAnt tasks that help me get things done. I’ll add to this library of custom tasks as things get fixed and new things get added.
To use the tasks, add a standard
<loadtasks /> line to your NAnt
build script and reference the custom task assembly. After that, you can
use the tasks just like you would any other built-in NAnt task. It’ll
look like this:
<loadtasks assembly="Paraesthesia.Tools.NAntTasks.dll" />
The available tasks include:
<alpharesx />task is used to alphabetize resource files (
*.resx) by resource ID. This is helpful in an environment where automated tools are used to merge resource file contents (like the built-in merge facilities in many source control products). Since many diff products don’t do XML data differencing, odd merging tends to happen, especially when several developers are working in the same .resx file. Keeping the resources in a fixed order, in this case alphabetical, reduces confusion for the diff tool and makes automated merging much simpler and more reliable. It also helps when hand-editing the .resx file to be able to find what you’re looking for in an easier fashion.
lintrelativepaths: When you add a reference to an assembly from a project, a “HintPath” is added to point to the location of that assembly. If it’s a standard .NET Framework assembly, that “HintPath” will point to the .NET Framework assembly deep inside the WINDOWS folder. That’s not a problem… until you get multiple developers working on the same source but checking it out to different locations on their machines. The reason is that by default, references get added with relative paths - so you might see something like
..\..\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.dll. However, if that’s not the relative path to the .NET 1.1 System.dll from where I checked out the code, my build will fail. How do you solve it? I solve it by using absolute paths - rather than
..\..\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.dll, I put
\WINDOWS\Microsoft.NET\Framework\v1.1.4322\System.dll. (Not foolproof, but far more reliable.)
This task searches specified files using a regular expression and fails the build if you have relative paths to common locations like
<nunitexec />task is a replacement for the built-in
<nunit2 />task. With NAnt and NUnit versions changing, there’s all nature of trouble in getting the built-in task to work using assembly binding redirects and so forth. Generally people switch over to use the NUnit console application to avoid the issue, but the
<exec />task doesn’t allow the nice syntax of the built-in
<nunit2 />task and changing working build scripts over is a pain.
<nunitexec />has identical syntax to the built-in
<nunit2 />task, it just runs the console app. An option is included to allow you to specify the location of the NUnit console application. Refer to the
<nunit2 />documentation for a description of how to specify formatters and tests to run.
propertydelete: NAnt lets you create properties, change property values… but not delete them. That makes the
property::existstest fairly limited. There are times when you might want to make a property not exist so you can better make use of simple tests like
property::exists. That’s what the
<propertydelete />task does - it doesn’t just unset the property, it deletes it so it no longer exists.
Usage documentation is included in a CHM file in the binary distribution (or as XML doc in the code). It includes syntax descriptions and examples. You can get the source to the tasks as well. If you find a bug, send me email or leave a comment and give me a way to reproduce the issue.
1.0.0: First release. Includes nunitexec task.
1.1.0: Added alpharesx, lintrelativepaths, and propertydelete.
- Updated to .NET 2.0.
- Updated to NAnt 0.86 beta 1.
- Fixed nunitexec task to no longer output the “framework” parameter.
- Fixed nunitexec task to properly quote only the value of command-line parameters.
- Fixed alpharesx to output .resx files in 2.0 schema format.
In my continued research into how best to go about digitizing my movie collection and making it more accessible than it currently is (binders full of DVDs aren’t too accessible) I’m reconsidering my position on storing the movie as ISO and might now just copy the VIDEO_TS folders to a drive instead. (I like DVD Decrypter for this.)
It turns out that both MediaPortal and My Movies for Media Center will support ISO playback using Daemon Tools, but ISO doesn’t work for Media Center Extenders like the Xbox 360. Ideally you’d just store one copy of the movie, but with ISO not working, saving ISO would mean having to save two versions of it - the ISO and a MCE-compatible version. Talk about space usage.
My Movies has a document talking about which format to store movies in (they recommend VIDEO_TS over ISO) and the Xbox 360 as a media extender. Turns out Transcode360 can handle VIDEO_TS now, too, so from a “lossless” standpoint, it may be that VIDEO_TS is the way to go.
You can even burn VIDEO_TS to a watchable DVD later, which was my original notion of saving the ISO - so if the original DVD gets corrupted or scratched, I can re-create it. The only thing I don’t know is how the various audio tracks (commentary, etc.) and extras (menus, behind-the-scenes videos) live on via VIDEO_TS and/or manifest on the Media Center Extender.
For one reason or another, I occasionally need to run Internet Explorer from the command line - maybe a script, maybe a shortcut, whatever. Good luck finding documentation on the available command line arguments for it, though, and iexplore doesn’t respond to “/?” or anything.