VS2005 SP1 Update for Vista

Wednesday, 14 March 2007

This was a perfectly timed release - just before I reloaded my machine, the RTM of the Vista compatibility update for Visual Studio 2005. Install service pack 1, and then install this update. 

Moving to Vista RTM

Saturday, 10 March 2007

After a few test runs (including confirming that all my data was copied over to an external hard disk), I finally took the plunge yesterday.

I'm now running Windows Vista Enterprise, and one big change is that I've gone back to 32-bit. I'm a little disappointed as 64-bit was working pretty well, but there were a few things that didn't work at all, like Oracle client software and Centra (which forced me to run both inside Virtual PC)

I'm pleased to report that Oracle has installed ok now.

I also repartitioned the disk, so now I've got my data back on D: where it belongs. I did some rough calculations and decided on 60 Gigabytes for the primary C: partition.

Overall, RTM seems pretty solid. One good thing was that I noticed running SourceSafe now seems a lot faster than on the 64-bit RC2 environment. Don't know if it's the move back to 32bit or RTM that has fixed that problem - but a "Get Latest" was taking minutes to complete, and we're back now to a few seconds, which is much more respectable.

About the only thing I forgot to do before reformatting was to check-in some pending changes into our Team Foundation Server. Because I forgot to do that, it left the changes "orphaned" in the old workspace. This was causing some weird things to happen on the new install until I realised that it might not be happy using the old workspace in the new OS. Removing the old workspace and doing some careful updating (manually updating those files I hadn't checked in) and I'm ok now.

Asia Pacific SharePoint Conference update

Wednesday, 7 March 2007

It's now official, the conference that had been hinted at last month will be on May 15-16th at the Sydney Hilton Hotel.

Now to wait and see if there's enough "technical" content to make it worth me attending.

Preferred feed URL for my blog

Wednesday, 7 March 2007

My blog feed has been available through FeedBurner for a long time, but I've now changed the blog template so that it publicises the FeedBurner feed directly.

If you've subscribed to my feed, first of all "Thanks!"

I'd encourage you to update the URL to point to the new feed source. That way if anything changes in the future, you won't need to worry - it should all just continue to work.

Subscribe to Dave's Daydreams

Preparing for Vista RTM - backing up your profile folder

Wednesday, 7 March 2007

I'm preparing to re-install my workstation and go from Vista RC2 to the RTM version, now that we've got access to the volume license versions. As they are only "Upgrade" versions, I'm planning to try this workaround to achieve a clean install without having to install XP first.

When I installed RC2, I didn't re-partition the disk - I just left it as one big C: drive. This has now come back to haunt me, as it means in order to to a clean install of the new OS, I've got to move everything that I want to keep onto an external disk, and then copy it all back when the new OS is up and running. Previous machines have always had two drives, so didn't used to be such a problem.

I've created a batch file to run robocopy.exe (which is actually included in Vista now), so I can select which folders I want to backup to the external disk.

That all worked fine until I pointed robocopy at my profile folder.

Your profile is located in %USERPROFILE% in case you were wondering - on a clean install of Vista, that maps to a folder under C:\Users. The old "C:\Documents and Settings" as used by XP is still there, but it redirects to the new folder.

This is related to where things went wrong. The way Vista does the redirect is by using Junction Points - they're kind of like symbolic links in Unix. The trouble is that Junction Points are also used inside your profile folder to redirect from the old name (eg. "Application Data" to the new name "AppData").

I wondered why robocopy was taking so long, and then looked at what it was doing - it seemed to be copying the same files over and over again - and then I realised that's exactly what it was doing - it was stuck in a recursive loop because it kept hitting a junction point that took it one directory deeper each time. Eek!

So I stopped the batch file, but now I needed to remove the mess on the external disk. This handy batch file did the trick - curiously it also relies on robocopy to remove a directory heirarchy that suffers from "the path is too long" errors.

I'm now using an extra argument "/xj" with robocopy to tell it to ignore junction points and it should all be fine.

robocopy c:\users\username e:\users\username /mir /r:0 /xj