Loosely coupled snippets

Installing Windows 7 on an old machine (code 5 fun…)

2009-12-03T20:32:36Z

I recently had to install a fresh copy of Windows 7 Home Premium on a relative’s six year old PC.

Not anticipating any problems I booted from the 32-bit DVD and was expecting the installation process to start. This is when I saw the following BIOS error:

Cannot boot from CD Code 5

After a bit of searching I found that this was because the machine’s BIOS is quite old and doesn’t support the EFI boot records on the installation media.

Next I dutifully updated the BIOS after burning a CD with the latest BIOS from the motherboard manufacturer’s website. Still no joy….

After this failed, I tried installing from a USB stick containing the Windows 7 installation files. Still no joy…

After deducing there was no easy way to force the machine to boot from the Windows 7 media, I thought I’d try and fool it by booting from something it understood.

If this scenario sounds familiar to you, then these are the steps I followed to fix it.

1. Boot the machine from a Vista installation DVD.
2. Choose a language, press Next, then choose Repair My Computer. 3. Next again, ignoring the driver selection, and choose “Command Prompt” for recovery.
4. Remove the Vista DVD and insert the Windows 7 DVD.
5. Change drive to the DVD, in most cases, D:
6. Change directory to the sources folder (cd sources)
7. Run setup by typing setup and pressing return.
8. The Windows 7 set-up should now start

Good luck!

Multi-threaded robocopy in Windows 7

2009-11-03T14:25:35Z

Robocopy has been part of Windows for a little while now. It's an excellent command line tool for copying files around if you haven't seen it before.

New to Windows 7 (and Windows Server 2008 R2) is the /MT option. This causes robocopy to operate in multi-threaded mode which realises a noticeable performance boost. It's well worth trying it next time you have to copy a large number of files around.

e.g.

robocopy \\server\share\folder c:\users\tblack\downloads\folder /tbd /s /z /mt

You can see a full list of the available options by typing

robocopy /?

within a command prompt window. This is the help for the /mt option.

/MT[:n] :: Do multi-threaded copies with n threads (default 8). n must be at least 1 and not greater than 128. This option is incompatible with the /IPG and /EFSRAW options.

.NET Framework Source Code available

2007-10-03T19:49:39Z

Have you ever been writing some code and got to the point where you just can't figure out what the .NET Framework is doing? You know, one of those really gnarly bugs that you just can't decide where the problem lies.

Most good devs will reach for Lutz Roeder's Reflector for .NET at this point and try and figure out what is happening in the .NET Framework. Wouldn't it be nice to have a fully integrated experience where you could debug from your code directly into the .NET Framework code?

Today, Microsoft has announced that later this year, with the final release of Visual Studio .NET 2008, the source code to many of the .NET libraries will be released under the Microsoft Reference License. This means that you can browse and view the source code providing you accept the license terms.

Additionally an Internet facing server will publish symbols for the source to allow an integrated debugging experience in VS.NET 2008. When debugging VS.NET will request source code from the server as needed when a developer steps in to .NET Framework code. The first download of the code will require explicit acceptance of the license but from then on you're free to debug all published .NET Framework source code.

Scott Guthrie has published a post which provides further details along with several screen shots to show how this process works in anger. Check it out here!

Converting VS2005 solutions to VS2008 Beta 2 (Orcas)

2007-08-31T15:26:00Z

Visual Studio .NET 2008 (codename Orcas) is just around the corner. With the release of Beta2 a few weeks ago I decided to update some of our work to use VS.NET 2008 Beta 2 instead of VS.NET 2005.

VS.NET 2008 Beta 2 introduces a host of productivity improvements for developers. Many of these are documented on Scott Guthrie's blog entry here. Of particular interest to me is the multi-targeting feature introduced in Orcas. With previous versions of VS.NET each version was tied to a particular release of the .NET Framework.

So, you have:

VS.NET 2002 can only build .NET 1.0.
VS.NET 2003 can only build .NET 1.1.
VS.NET 2005 can only build .NET 2.0.

Orcas allows the following permutations:

VS.NET 2008 can build .NET 2.0 or .NET 3.0 or .NET 3.5.

There's a great blog post by Soma here if you want to learn more about the differences between some of the more recent versions of the .NET Framework including an explanation of 'red' bits and 'green' bits.

Multi-targeting is important to me because our customers currently use VS.NET 2005 and may well continue to do so for some time after VS.NET 2008 RTMs. Yet I'd like our development team to get the most out of the cool new features in Orcas without having to wait for all of our customers to upgrade. Multi-targeting allows us to do this by using VS.NET 2008 internally but shipping VS.NET 2005 code.

However, there are a few issues to be weary of and I'll describe these below.

When you open a VS.NET 2005 .sln file in VS.NET 2008 Beta 2 the Visual Studio Conversion Wizard steps in to convert files as required. The good news is that the .csproj file formats have not changed. However the .sln, .vsmdi amd .testrunconfig file formats have all changed.

If the conversion wizard runs fine, the resulting solution should compile and run in VS.NET 2008 Beta 2 quite happily. For our project we need to ship the source code as well as binaries so the upgraded projects have to also continue working in VS.NET 2005 and this is where I found problems.

Because we must maintain compatibility between the two VS.NET versions, and we have incompatible file formats (.sln, .vsmdi & .testrunconfig) we maintain multiple copies of the files that have changed format. This means that under source control we have:

Main.sln AND MainVS9.sln
Main.vsmdi AND MainVS9.vsmdi
LocalWithCoverage.testrunconfig AND LocalWithCoverageVS9.testrunconfig

Maintaining parallel copies of these files isn't great but due to our requirement to support both formats and lack of time to develop an automated build based solution this is what we have at present.

Conversion problems

This issue is to do with the .csproj files for Web Application Projects which are format compatible between VS.NET 2005 and VS.NET 2008 Beta 2. If I open my original unconverted Main.sln in VS.NET 2005 it references the converted, but compatible, .CSProj files contained in my solution. Within any Web Application Projects the conversion changes the following line (amongst other things)

Before conversion:

After conversion:

If you try this on a machine without VS.NET 2008 Beta 2 installed the project will fail to load because it cannot find the v9.0 path being referred to. The solution is to alter the converted line and replace it (using Notepad) with:

This way the correct version of the Web Application Projects targets will be loaded depending on the version of VS.NET you are using.

Microsoft Health Common User Interface

2007-08-30T23:14:00Z

For the last couple of years I've been working in a team collaborating with the UK National Health Service (NHS). We've worked extensively with patient safety experts, clinicians, user interface designers, ISVs and representatives from the NHS' IT agency - Connecting for Health.

The purpose of this work? To produce a set of ASP.NET AJAX and Winforms controls together with some associated guidance that attempts to standardize clinical user interfaces. The guidance is designed to be platform agnostic so that it can be used in a broad range of environments. Whereas the controls embody the guidance using the Microsoft platform.

Two years ago the work started out as some early prototypes, preliminary guidance and some embryonic ASP.NET 2.0 Beta 2 controls. While the guidance work progressed we spun up a parallel track of work to develop a Windows Presentation Foundation (WPF) Demonstrator. This had many purposes that included engaging ISVs, providing a visionary look at future clinical user interfaces and demonstrating the capabilities of Microsoft's emerging UI platform.

While the Demonstrator proved to be very successful in raising the profile of the work we were doing it was clear that ISVs had a more immediate need for controls they could use in their current generation of applications. For this reason we've spent the last 6 months producing a set of ASP.NET AJAX based controls that lean heavily on the functionality provided by the AJAX Control Toolkit. They come complete with SDK style documentation that integrates into the Visual Studio help collection.

Until very recently much of this work has remained between Microsoft, the NHS and selected ISVs. However recently, with the encouragement of Microsoft Corporate Healthcare, much of the work has been published publicly at http://www.mscui.net. A large part of the guidance produced to date is available for download as well as the associated controls along with their source code.

We're starting to see some discussion now in the wider community and I'd encourage anyone with an interest in improving patient safety via a common user interface to participate in the discussions forums.

The work will continue now and is planned for at least another 18 months. We'll continue to work with our partners and listen to the community as we strive to work towards better, more consistent and safer clinical user interfaces.