Good to see that the scalpers are out in force on eBay, proving that you can sell any old crap; how about a boxed copy of Windows Vista RC1? Sheesh... (You've gotta love the comment - "This is a prerelease versaion[sic] of Windows vista , works perfectly "!)

Last week, Microsoft quietly released Windows Powershell 1.0 (formally known as Monad) to the world. This is a great piece of technology that's worth taking some notice of - it's destined to become my Windows shell of choice; at least when a version for Vista is released. As it is, I'm stuck using it on my development laptop (running XP SP2). Previously, if I needed to do any form of complex scripting on a Windows box, I'd install Cygwin and knock something up in bash. Powershell will now take preference however; it ties in the .NET Framework with a scripting environment, so it gives me a library that I'm already familiar with (and one that I'm likely to be staying with for some time). As a quick example, how to display the number of days until Christmas using Powershell:

[String]::Format("{0} days until Christmas!", ([DateTime]"25 Dec 2006" - [DateTime]::Now).Days)

That's not to say that Cygwin is coming off my systems any time soon, I like having the GNU toolchain available (I'd be lost without rsync, ssh and wget), but for day to day scripting it'll be Powershell.

When it's available for Vista that is!

Damn, this sorta thing makes me so mad....!

I've just been fighting with a SQL Server 2005 Enterprise Edition upgrade at my employer; it should have been a simple upgrade from SQL Server 2000, but halfway through the installation process I was getting a "SQL Server setup could not validate the service accounts" error. Following the online help led me to a help page that suggested the problem was to do with password strength. Cue several hours following a red herring.

After examining the Security log, I had a light-bulb moment; the old SQL instance had the service accounts in the user@domain format. Changing the service account to the older DOMAIN\user format in the Services control panel and restarting the installation process allowed the upgrade to happen. Easy once you know how.

Amongst the many roles I seem to undertake at my current employer (.NET Evangelist, NHibernate Evangelist, ATLAS Evangelist and so on), I also spend a large amount of my time dealing with XML technologies - whether it be transformation, serialization, querying or whatever.

Over time I've seen some truly awful implementations of so-called XML 'solutions'; one of my favourites involved the DVLA here in the UK. They proudly announced that they'd implemented an XML based system to enable the querying of Driving Licence details (whether the driver was banned, how many points on the licence and so on). So, given an XSD schema describing the object graph required for the query I coded up a simple .NET application to produce the correct XML fragment.

The DVLA instantly rejected it because:

1. Every element needed to start on a new line
2. There was an 'encoding' attribute in the XML declaration
3. Even though the source XSD had specified a target namespace, namespace declarations were not understood

Aaaargh!

Even worse was the size of the response - every single line in the response document was padded to over 200 characters, and with one element on each line this produced a document that was 62,771,702 bytes long.

A simple

cat results.xml | tidy -xml -indent -o parsed.xml

produced a document that was a mere 8,604,602 bytes in length.

Now this is a bit of an extreme example, but I've seen several variations along this theme in active use and nearly all of them stem from one single problem - string concatenated XML, like this:

Console.WriteLine(@"<?xml version='1.0' encoding='utf8'?>");
Console.WriteLine("<root><element attribute='value' /></root>");

XML has a problem in that it is very easy to read and understand, but there are enough pitfalls for the unwary/lazy. I've had documents in the past where the encoding has been specified as UTF-8, but the characters supplied have been ISO-8859-1 which lead to some truly awful hacking with 'awk' and 'sed' later in a complex overnight batch process.

The MSDN article "Five Ways to Emit Test Results as XML" by James McCaffrey provides some interesting XML generation options for the .NET framework which I fully agree with - except for the end of Technique 1.

There are many, many toolkits out there for XML processing and generation - don't resort to string concatenation, you'll get it wrong!