Links for 25-Dec Bumper catch-up edition

2010 having spanned the run from first integration point through to RTM and GA for XenDesktop 5, I was being increasingly preoccupied as the year went on; and blogging of any form was one of the main casualties. Which means I have a not-so-little list of backlog of things I want to keep track of from the last couple of months:

F#

• F# Goes Open Source
• MonoDevelop plugin for F# now available
• The MVVM Pattern Using F#

.net General

• Creating Zip files with System.IO.Packaging namespace
• Kill That Util Class! with C# extension methods
• Debugging with Async -- C#5 CTP
• Dynamic Language Integration in a C# World
• Algorithmia Source Code released on CodePlex
• Mono: What we are Cooking (9-Dec-10)
• How to: Determine which Microsoft .Net Framework version and service pack installed?
• Decoding clr20r3 .NET exception – using mono cecil
• C# Closure Constructors -- from the original Javascript

Build Process

• Fixing Incorrect solution build ordering when using MSBuild.exe
• StyleCop Compliant Visual Studio 2010 Code Snippets November Release
• Taming Sandcastle: A .NET Programmer's Guide to Documenting Your Code
• ILMerge – How to Merge Assemblies After A Build
• MSI Explorer
• Creating a NuGet Package

Misc.

• An HTML5 Remote Desktop - Part II
• Are we documenting the wrong things?
• Javascript: Defining Classes with Closures

Alpha-encoding file versions

When building installers the UpgradeVersion must have a unique property value that is an installer public property (upper-case alpha). So, what better way of adding uniqueness than making it have the form "product name + product version" with the version suitably encoded...

So, a script for turning a file version (4 x 16bit ints) encoded as a System.Version into a short alpha string, assuming that Major and Minor will be small, and that common approaches are to step Build, to use a stepped Build plus date-stamped Revision, or a timestamp Build and Revision --

where the first two facets are encoded as telescoped base-13 (with a bit to say "more to come"), and the second two are encoded as pairs of bytes -- Z for a zero byte or as a 2-character base-25 representation if non-zero, with a zero Revision being dropped. This gives 10 characters in a plausible worst case, or as low as 5 in some conventions (stepped build numbers only); as opposed to the naive 64-bit as all-base-26 which would give 11 characters always.

IronPython for build scripting

Following on from the earlier post with the snippet about generating GUIDs -- and covering a good chunk of what's been occupying me since...

I have ended up in charge of the build system for the current project at work. This started out with one framework that used a number of custom projects inside a solution to perform unit test, FxCop and coverage analysis, with a lot of magic happening in post-build steps, including direct calls to Wix command-line utilities. Another team had developed a better separated MSBuild-based system, which split out things like the analysis and installer building from the assembly-building solution. We can argue the merits of taking the unit tests out of every checking compile; but separating out the installer build does have a significant benefit in terms of cycle time for a recompilation.

Frankensteining the two together was an interesting task; and IronPython has been a valuable component of the mix. As I noted quite a while ago, the convenience of an XCOPY install on a machine with a current .net installation (any build or dev machine), and the access to the full APIs makes for a powerful tool during a build -- it's not just the fact that you get better string manipulation than a batch file, or can easily spawn off a call to source control to get a synch-level value to stamp an assembly with.

In the current context, there are a number of components being built with a common architecture, so there are plenty of opportunities to DRY the system out.

• There are repetitive pieces of code (declaring concrete subtypes of shared base classes, to inject component specific information) which can be run by having a couple of .py files (just containing a single map initialization with common keys and component or project specific values) to define the files affected and the component-specific substitutions to make (including in some cases stable but component specific GUIDs, that can be keyed off the component specific names)
• The shared architecture makes the MSBuild .proj file just as valid for such String.Format based substitution
• Wix source files are just XML documents -- they can be generated programmatically from XML fragments, inspecting the solution output and filling in the appropriate entities.
• So are Wix project files (or any MSBuild project for that matter) -- a project to build a 64-bit installer can be derived from a 32-bit installer project by a similar set of XML manipulations.

Taking the latter as an example

Of course, assumes that the .wxs files have Win64='$(var.X64)' attributes sprinkled appropriately.

Generating strong repeatable GUIDs

In recent weeks I've had the problem of wanting to generate GUIDs that are distinct, but are repeatable -- in particular for things like COM class UIDs, and for installer component IDs, for a project using a lot of generated code.

So this is what I did in part of my build scripts (note, this is not totally RFC 4122 compliant, but it suffices in practice)

The input is the individual name of the thing I'm generating, concatenated with a constant GUID string used as a salt. The ToUpperInvariant is there to permit WiX to be run in pedantic mode.

Yes, it's exactly as vulnerable to hash collisions as MD5 -- but then my input is not maliciously aiming at such.

Later:-- or you could just use

but that makes the RFC 4122 guid-for-salt explicit for you.

Links for 10-Feb

InstEd -- MSI installer editor.

Mocks vs Stubs.

5 ways to call a JavaScript function.

At 23:31:30 this Friday, the time will be 1234567890 precisely.

23 UsefulRuby 1.9 resources.

Links for 22-May

Hard-core concurrency considerations

JavaScript -- Lisp in 'C's clothing -- used to demonstrate the Y combinator

HTML5 now accepted for review

You think you know JavaScript but you have no idea -- excellent presentations

The high cost of free tools

An Introduction to Ranges (JavaScript/DOM)

Is HTML5 a slippery slope?

Zoomable UIs

Design Patterns Aren't

"Maybe" in Java

Process is about people

Managed Code Custom Actions : no support on the way and here's why --why we still need to do installer custom actions the hard way

Apple's new Invisble UI

Another look at HTML5

Modularity, Ruby and doing the right thing -- cross language behaviour in Silverlight/DLR

C# and the compilation tax -- " Over the last four years, I've basically given up on the idea that .NET is a multiple language runtime."  I know how he feels.

Web 2.0 is neglecting good design -- BBC News picks up on Jakob Nielsen's comments

Design by Grid -- grid layout in the post <table> age

A nostalgic look at using XMLHttpRequest with SOAP -- how to call a web service from your browser the "old-fashioned" way (i.e. how to write the code that ASP.NET AJAX does for you).

Silverlight at the command line -- Test your Silverlight applications in the real thing in scripts (the Silverlight engine is highly sandboxed, so it's going to be limited as an application context)

Silverlight : dynamic languages in the browser -- roundup article

Ruby on Rails on TDD -- a 15-step guide to test-driven web apps

JavaScript Libraries : the big picture -- high level, high speed. Also, good stuff in the comments.

Breaking out of the box -- Learn the rules and then break them for grid-based page designs.

LessMSI -- MSI unarchiver 

Hackers and Fighters -- or, Theory vs. Practice 

IronPython URLs -- aggregator blog

Hello, Dynamic Language Runtime-enabled World! -- IronPython 2.0 now runs on Mono.  Shame that 1.2.4 came out about 24 hours before this was checked in.

Identity Providers, Authentication, Self-Issued cards

AD FS/SiteMinder integration via federation

Web Content Accessibility Guidelines 2.0 up for public review 

The implications of OpenID 

IronPython Console Syntax colouring and tab completion —
tl;dr: ipy -D -X:TabCompletion -X:ColorfulConsole

IronPython Community Edition (FePy) -- at v1.1 with added tighter integration with CPython libraries.

Reducing User Interface Friction

Color Oracle -- colour-blindness simulator

Current Browsers and WCAG1.0

JavaScript -- the Lingua Franca of the web

1023 bit number factorized.  Time to move to 2kbits, and retire those decade-old PGP keys, I think.

Form validation with Prototype+Scriptaculous -- an example

Productivity tip -- not all Pentium-4 class processors are born equal.

Phew. Caught up