Starin' at the Wall: November 2006

Tuesday, November 21, 2006

XSLT For MSDN Product Keys

Here at Coversant we're Microsoft partners. We have MSDN subscriptions for all our developers/testers, and we share the same set of license keys. Rather than give everyone willy-nilly access to the MSDN download web site (ick, lots of bandwidth suck) we setup an internal file share for MSDN installation files, CD images, etc. We used to have all the product keys in there just saved as html from Microsoft's web site. However, that's no fun!

In the spirit of having fun and being developer friendly, Microsoft is nice enough to offer an "Export Key List to XML" button on the web page where we view all our product keys. So, I clicked the button. Out popped a very nicely/simply formatted XML document, like the following:

<?xml version="1.0" standalone="yes"?>
<Your_Product_Keys>
 <Product_Key
  Name="All products requiring a 10-digit product key"
  Key="xxx-xxx-xxxx"
  Key_Type="Retail"/>
 <Product_Key
  Name="Windows Vista Ultimate"
  Key="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
  Key_Type="Retail"
  Date_Key_Claimed="2006-11-20 17:36:11.787"/>
 <Product_Key
  Name="Windows Server 2003 R2 Standard Edition"
  Key="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
  Key_Type="Retail"
  Date_Key_Claimed="2006-11-20 17:36:08.270"/>
 <Product_Key
  Name="Office 2007 Desktop Programs"
  Key="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
  Key_Type="Retail"
  Date_Key_Claimed="2006-11-20 17:35:57.537"/>

  ...

</Your_Product_Keys>

I whipped up a quick XSLT you might find useful to transform this to a really ugly, really simple, x-html page (yeah without the namespace declaration).

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">
 <html>
 <body>
   <h2>MSDN Product Keys</h2>
   <table border="1">
   <tr bgcolor="#9acd32">
     <th align="left">Product Name</th>
     <th align="left">Product Key</th>
   </tr>
   <xsl:for-each select="/Your_Product_Keys/Product_Key">
   <tr>
     <td><xsl:value-of select="@Name"/></td>
     <td><xsl:value-of select="@Key"/></td>
   </tr>
   </xsl:for-each>
   </table>
 </body>
 </html>
</xsl:template>

</xsl:stylesheet>

Then I made one quick edit to the xml file so friendly xslt aware web browsers will do the transform for me:

<?xml version="1.0" standalone="yes"?>
<?xml-stylesheet type="text/xsl" href="productkeys.xslt"?>
<Your_Product_Keys>
  ...
</Your_Product_Keys>

Presto-chango, we now have an easy to update central listing of our MSDN keys. Now if only MS had a web service that took my Live ID credentials and gave me back that XML...

Wednesday, November 8, 2006

Compact Framework WaitHandle.WaitOne Gotcha

I ran into a behavior in the 2.0 Compact Framework today that was most vexing. It wasn't hard to find like a subtle race condition. It wasn't an issue that only duplicated with a certain system configuration, under a full moon, on Wednesday. No, it duplicated every single time the code was ran. But, it wasn't documented anywhere I could find.

One of my favorite new features in the Compact Framework is the availability of the WaitHandle.WaitOne(int, bool) overload. That's something we use quite a bit in our test code and here and there in the actual SoapBox Framework. We used to have our own ManualResetEvent implementation for the Compact Framework that P/Invoked out to Windows CE. But Micrsoft was nice enough to add this into the 2.0 Framework. Yay! (In case you never had the joy of programming to the .NET 1.0 framework, the only WaitOne overload that was there was the indefinitely blocking one. No timeouts allowed.)

I was running our unit test suite against the Compact Framework and tests that used to pass until I ripped out our custom P/Invoking ManualResetEvent implementation were failing. Odd... Well, it turned out to be very easy to track down. WaitHandle.WaitOne(int, true) throws an ArgumentException every single time. That's right. If you pass true to that second parameter, the exception is thrown.

Don't get me wrong, I understand the implications of exiting the synchronization domain for the context or not. It turns out the code that was causing the error should have been passing "false" for the parameter anyway. But, why did the call throw an exception? Why not just ignore the argument when it's not relevant as the documentation alludes? And I quote from MSDN2: "The exitContext parameter has no effect unless the WaitOne method is called from inside a nondefault managed context."

Anyway, if you're doing any Compact Framework development, make sure to pass "false" into the exitContext parameter of your WaitHandle.WaitOne calls.

Tuesday, November 21, 2006

XSLT For MSDN Product Keys

Wednesday, November 8, 2006

Compact Framework WaitHandle.WaitOne Gotcha

About the Author