Since joining the MSBuild team, I've learned more than I ever thought imaginable about .NET references and dependencies, largely because I'm responsible for testing the ResolveAssemblyReference task we'll be shipping as part of our task library. Between my testing of that task and the patient guidance of one of our developers, I've learned about many of the intricate details of reference resolution. It's amazing to me how much this thing can do, and how many scenarios rely on this little (ok, well, not so little) task in one way or another.
One cool new feature in Whidbey is at build time the ResolveAssemblyReference task can automatically choose the latest versions of your references and dependencies. So if I have some cool MusicWidget in my app which depends on Version 1.0 of WidgetBackend.dll but my MovieWidget depends on Version 2.0 of WidgetBackend.dll, the ResolveAssemblyReference task can ensure my app is compiled with Version 2.0. In most cases, when the owners of WidgetBackend.dll are playing nicely and maintaining backwards compatibility, this is exactly what I'd want, but I'd rather not have to worry about the details of which versions of support files my widgets are using. I just want to use my widgets! Of course, there will still be cases when for one reason or another I'm not prepared to migrate to Version 2.0, and I'll be able to direct the ResolveAssemblyReference task to still use the old version if so.
Similarly, 99.99% of apps written against version 1.1 of the .NET Framework will depend on some Framework assembly such as System.dll or System.Data.dll. When you install the Whidbey .NET Framework and rebuild your apps, the ResolveAssemblyReference task will see your Whidbey .NET Framework and pick those versions of System.dll and System.Data.dll for the compiler to use. And you won't even have to so much as browse to a file on disk. Of course the same provision applies here for those who aren't ready to move all of their dependencies to Whidbey: you can just tell MSBuild to use the specific version you've been using all along.
Hopefully the work we're doing in this area will give developers confidence in choosing the right solutions for their problems rather than worrying about what new problems may be introduced by their solutions...