I don't know if you've been spending much time working with any of the .NET 2.0 based systems we are building (Longhorn, Yukon, Whidbey), but I've been working with some form of them for about a year and a half now.  One of the difficulties I've had is trying to work with any combination of these as to keep things relatively stable and happy, you need to make sure the version of the redist is the same.  For example, if you went to PDC, you got the Goods which were a version of the three of these that were all built using .NET 1.2.xxxx.yy (I can't remember anymore).  So you could install the kit together and they were relatively happy together.  Try doing that outside a planned milestone when downloading releases from each of the build servers.  Not pretty, and not something that the product teams should be wasting cycles on when driving to get these out, but it makes for an interesting challenge for those of us that can't wait to get our hands on the latest bits...

With the release of the official Whidbey Beta 1 and Yukon Beta 2, I don't know if you noticed but they both have different releases of .NET 2.0 (40607.16 and 40607.42, respectively).  While all works relatively well if you install Yukon first and then Whidbey, try and get both of those to work on top of a recent Longhorn build (say 4091 which uses a later build release of the framework)...  Good luck - there is a black art method to do this, but with the frequency of needing to updating your builds, this isn't ideal.

So, to combat this I've resolved to running to Windows XP SP2 as my base OS today and focus on getting my dynamic releases isolated to Virtual PC's.  At MGB, a friend (JEQ) pointed out to me the value of differencing disks and how to setup a more space sensitive virtualized environment that also saved considerable time in setting up virtualized machines to run these releases.  I haven't had time to consider this until I blew up my OS the other day with an unexpected .NET install by the Ocracoke tools as I tried to "simply" add in the testing tools to my sync'd up Whidbey/Yukon install where I had them both running 40607.40.  Ooops.  The world is not happy with two installs of .NET 2.0 on the same box and don't even try to gracefully uninstall...  time to rebuild and rethink how I'm doing this and JEQ's differencing drives popped into mind.

Using an ISO image from MSDN I created a base Server 2003 Standard Edition disk, got it all patched and then sysprep'd it (also for XP). Then you mark that disk read-only and go into Virtual PC and create a new disk, select differencing and point to the Server 2003 image as the base.  Now create a new Virtual PC system that uses the differencing disk.  When you boot it, voila you can now have a new SID system that you can install whatever release of whatever app on top of.  This is nice for me as I now have a clean SQL 2000 SP3 machine and a Yukon Beta 2 machine that uses very little space because they are both load up the base image and then add the "differences". I can then boot one or the other and hit it from my VS.NET base installation.

Now I'm on the path to doing the same with some XP Images to keep a Whidbey build loaded into and an isolated Ocracoke; I'll also build Server instances with BizTalk 2004, HIS 2004 and others (LCS...) while never installing Server 2003 again.  The same also works for Longhorn so I can install and not hose myself anymore...