December 6, 2012 Update: The virtual machine and corresponding hands-on-labs / demo scripts have been upgraded to use Visual Studio 2012 Update 1. You can download them from here.
Now that Visual Studio 2012 Update 1 is available, several people have asked whether or not I am updating my ALM virtual machine. The answer is yes – and it will be available by sometime next week. Watch my blog for details. There are some really nice improvements in Update 1 that I think developers, architects, project managers and testers alike will enjoy.
A longer question I have also been asked is whether or not Update 1 can be installed by end-users into my virtual machine. The answer is “not really” (unless you want to jump through some workaround steps). The reason for this requires a bit longer of an explanation.
If you have worked with my virtual machine you may have noticed that every time you boot it up, the date and time jumps to May 16, 2012. The reason for this is that in order to show a pseudo-realistic example of how Team Foundation Server can be used to support an actual development team, we need to pin the system date to a specific day in the middle of an iteration. If we didn’t do this, then the VM might look great on the day I shipped it, but if you downloaded it a month later the data is going to start to look stale. You’ll be in some future iteration with no recent work item activity, a flat burndown chart, etc., sort of like any good post-apocalyptic zombie movie where life and routine as we know it stopped months ago.
Setting your operating system to an older date and time is of course a “hack” that you should never use on your actual Team Foundation Server instance, but since my virtual machine is for training and evaluation purposes I have taken this (and a few other) liberties where necessary to optimize the virtual machine for those experiences.
One implication of this hack is that after you boot the virtual machine and start working with Team Foundation Server you should never reboot the virtual machine. If you do, then the operating system will reboot into the morning of May 16, 2012, and Team Foundation Server will get confused since you will be going “back in time” – something that Team Foundation Server is simply not designed to support. Instead, I always suggest that users take a Hyper-V snapshot of my virtual machine after they boot it up for the first time but before they start working with it so that they can always roll back to a known clean state in case they make a mistake or simply want to repeat a scenario (which is what I do routinely when I am demonstrating Team Foundation Server at conferences and customer meetings).
Which brings us to Visual Studio 2012 Update 1. If you try installing Update 1 into my virtual machine you will notice that you are prompted to reboot during the installation process. While you won’t receive any errors or warnings during the setup/upgrade process, if you attempt this you will start to notice problems later on – especially in web access. This is because you are going back in time every time you reboot.
I know a few people were burned by this and I’m sorry for the time you may have wasted going down this path. Generally speaking, I always tell people that the virtual machine was built specifically to support the nearly two dozen hands-on-labs / demo scripts which go along with it. While you are welcome to use it for other purposes, your mileage may vary, and this is a good example of something which just won’t work.
One workaround if you really want to install Update 1 yourself into my virtual machine would be to go into the Task Scheduler and disable the task which configures the date and time to May 16, 2012. After you disable this you can run Update 1 as expected, but keep in mind that the project management data will no longer look accurate since you will be many months ahead of when it was designed for. Or, you can wait a week until I publish an official version.
Thanks for reading and as always for all of the feedback.