Why is it that the only time I never get to upgrade is when I'm going somewhere by 'plane? Other than that, I seem to spend half of my life upgrading stuff. A few months ago I upgraded my network (well, some of it) to Windows Server 2003. I upgraded my laptop from an old Dell Inspiron to a gleamy new silver XPS. I even upgraded my main work machine to Office 2007 (and I'm still suffering the consequences of not being able to find any of the usual commands...). And it's not just computers. I upgraded my lawnmower from a tired electric rotary Flymo thing to a proper manly Honda petrol one (mainly because the old one was emitting more smoke and burning smells than grass-cuttings), and my camera from one that needs real film to a new "digi" kind. Even better, my wife - who has more money than me - recently upgraded her car to the new model. I just hope she's not planning a husband-upgrade next.
So, staying with the opening ramblings, this month I'm doing a "How hard is it to upgrade" diatribe. Starting, as befits a developer geek's diary, with something technical - Enterprise Library. The p&p guys in Redmond released an updated version of Enterprise Library (see http://www.codeplex.com/entlib/), going from version 3.0 to 3.1. This is documented by Tom Hollander as "basically a bug fix release", and so I guessed it should be fairly easy to upgrade the samples and demos for my articles and presentations to the latest version. As I'm doing some presentations about Enterprise Library at the VBUG Conference in October, it seemed like a good idea to be using the current version. OK, so you can't run it side-by-side with version 3.0, but as it's basically the same code I can just replace version 3.0 with version 3.1 and update all the Web.Config files that contain assembly version references.
PS: I liked the comment from one subscriber to Tom's blog who asked if the next release would be version 3.11 - Enterprise Library for Workgroups...
Anyway, I uninstalled the 3.0 version from my machine, downloaded the new 3.1 version, and started the installer. It all ran nice and smoothly (even on Vista), and even asked if I wanted to install the source code. Yes please, as my samples use several custom providers that I'll need to incorporate into the new version. So, open the main Enterprise Library solution into VS2005, and open a copy I kept of the v3.0 source code into another instance of VS2005. Also open both folders in Windows Explorer, copy across the custom files from the v3.0 folders into the v3.1 folders, and add them to the new v3.1 solution in VS2005 as I go. I'd forgotten how many files I'd added over the time I've been working with v2.0 and v3.0, including all the configuration and design classes required to support custom providers and the configuration tools. But, after half an hour, they were all incorporated into the new source solution. Then it's just a matter of merging the changes made to existing source files and resources in v3.0 into the v3.1 source files. These include the CommandRegistrar and NodeMapRegistrar classes, and the string values in the various .resx files used by the configuration tools, exception messages, etc. In all, it only took about an hour - including building the new version of Enterprise Library and running some of the QuickStarts to prove I hadn't broken anything.
Next, update the samples. In theory, this is easy. For samples that reference the signed Enterprise Library assemblies in the GAC, I just need to update the references to pick up the new versions of the assemblies. However, most of my samples demonstrate custom providers (the whole reason for building them), and these have unsigned versions of the assemblies in their Bin folder. In this case, I just had to copy the newly built v3.1 assemblies from the AppBlocks\Bin folder to the Bin folder of each sample, then do a search-and-replace in Web.Config to change the assembly reference from "Version=220.127.116.11" to "Version=18.104.22.168". As they are unsigned, the PublicKey values are all "null" anyway. Amazingly, nearly all the samples worked fine straight away!
But then I came to the awkward one - the one that demonstrates using Enterprise Library in an ASP.NET application running in a partial trust mode (rather than the default of Full Trust). In version 2.0 of Enterprise Library, you had to install a patch that allows you to run in less than Full Trust. Basically, the patch allows you to instruct the assemblies (through the requirePermission="false" attribute) not to demand Full Trust permissions. Version 3.0 incorporated the patch, but moved the problem by issuing all the EntLib assemblies with digital signatures so you can install them in the GAC. While you can still tell them not to demand Full Trust permissions, the underlying ObjectBuilder injection framework assembly is provided only as a digitally signed version. Therefore, to use partial trust, you had to go off and download the Composite UI Application Block (CAB), borrow the source for ObjectBuilder from it, and compile an unsigned version to put into your application's Bin folder.
Enterprise Library 3.1 uses an updated version of ObjectBuilder (1.0.51206.0), whereas version 3.0 used version 1.0.51205.0. Maybe they are the same? Or maybe not - do I chance it? In fact, you can now get the ObjectBuilder assembly and the source code directly from the Codeplex site, so it seems a good idea to use the correct version. So I download it, compile it, and drop it into the Bin folder of my partial trust sample application. Unfortunately, it all goes wrong from here. The unsigned versions of the Enterprise Library assemblies reference ObjectBuilder using its public key, and they won't use the unsigned version. But the signed version of ObjectBuilder won't work because the unsigned versions of the EntLib assemblies can't call into a signed assembly except in Full Trust mode. And if I edit the Assembly.cs file for ObjectBuilder to add the AllowPartiallyTrustedCallers attribute to the assembly, and then compile it, I can't sign it and get the correct Public Key value unless I can persuade Bill to lend me his private key (which seems unlikely when you see what rigmarole even the MS dev guys have to go through to sign code).
In the end, the only solution is to recompile the entire Enterprise Library as unsigned assemblies that reference an unsigned ObjectBuilder, and optionally re-sign all the assemblies yourself. The Enterprise Library source code contains the tools you need for this, and the documentation describes the process, so it's not too bad. However, you still need to regenerate the complete Enterprise Library, which - though not actually a trivial task - is (as I discovered from several sources as well as experience) reasonably easy if you do it the right way the first time! If you are planning this, here are the steps in detail:
Meanwhile, what else am I upgrading? Well, over the last month, you may have noticed that I've been trying to replace my Media Center box with something a bit more up-to-date. Unfortunately, the Sony experience (see Yet More Drive Image) kind of put me off doing anything at the moment. Instead, I picked up a rather cranky but extremely efficient PVR (Personal Video Recorder) from a local electrical retailer at a give-away price of 120 pounds - it's a discontinued product and they had a few with bashed boxes going at about a quarter of the original asking price. Another example of my recent upgrades. However, it's not a patch on Media Center, even if it does do digital TV and has twin tuners. But at least, I thought, the combination will keep us going televisionally until a suitable Vista Media Center system appears.
Oh how wrong I was. I have our Media Center box (still running MCE 2004) set up to reboot in the early hours of every morning, then auto-logon and restart Media Center. One day last week, I switched on the screen to find it sitting at the DOS boot screen doing nothing else useful. While it's nice to be able to sit back and read at leisure how much memory is installed, and what disk controller the machine contains, it doesn't have quite the same entertainment value as TV (although, with current TV scheduling, some might question that statement). Anyway, it did reboot OK after undergoing a BRST (Big Red Switch Time) procedure, so I thought no more about it. Then this week I was suddenly awoken from a half-asleep-watching-a-WebCast-supposed-to-be-writing-code moment by my wife asking why the TV said "Cannot find C:\Windows\System\some-really-important-file.sys". Hmmm... kind of worrying. It sounds like the disk has gone past it's MTBF thingy, and will shortly be off to join the rest of the world's pile of dead data.
So I've just ordered another new new Media Center box - this time the Acer iDea 510. Dave has one of these and is extremely happy with it - except he says the hard disk is noisy when seeking. Really? He obviously hasn't heard the fan-heater noise my old Evesham box makes. No doubt there will be more on this running (sore) topic in some future diary entry...