A quick update on a version of the Atlas VSIs that work with Whidbey RTM/RC. As noted in the 'Get Atlas' section, the downloads currently only work with Beta 2 builds. While it's possible to get them to install on RC with a minor tweak, there's a good chance something in your app will stumble on one of the breaking changes between those versions.
We depend heavily on 'dogfood', i.e., self-testing to make sure that ASP.NET 2.0 is ready to ship to our customers. Starting before Beta 2, I've been working with several large internal customers committed to deploying and testing ASP.NET 2.0 for us. Along the way we're learning a lot about the kind of issues that customers will face. We've fixed many of those problems and will also be providing documentation on how to deploy applications in various challenging scenarios.
For example, the Microsoft.com Download Center has been one of our earliest internal customers and has been running on 2.0 since last June. What's the big deal about this? All of Microsoft's downloadable content is hosted by the Download Center site. If you separated Download Center from the microsoft.com domain, it would still be one of the largest sites on the web. Consider these recent stats:
~37 Million unique users
~325 Million Page Views
28.14% of all traffic on Microsoft.com
769,155 Unique pages
From a software engineering perspective, this is a tremendous asset for us because although we do extensive stress testing with numerous scenarios and application variations, we can't possibly create an identical environment in the lab. It also helps us focus on the complexities of supporting applications from a variety of development teams together on the same machine. In the case of Download Center, we had the challenge of upgrading this application to ASP.NET 2.0 while other applications on the site continued running on ASP.NET 1.1.
Here's a real world example of some things we learned during the Download Center deployment: While we've put a lot of work into ensuring an easy upgrade of 1.1 to 2.0 apps and coexistence of apps created with both versions on the same machine, an application's architecture and environmental factors can also affect deployment. ASP.NET 2.0 supports running 1.1 and 2.0 versions of the framework side-by-side on the same machine, using IIS Application Pools to isolate each framework instance. But what happens when your 1.1 and 2.0 apps both depend on a second application for part of their functionality and that application is supported by another group? This was the case with MNP, a UI layer developed internally by Microsoft.com that renders XML-based content and provides the 'chrome' - the common look and feel - across all Microsoft.com properties. The solution in this case was to create an ASP.NET 2.0 version of MNP specifically for Download Center and future Microsoft.com sites that would upgrade to ASP.NET 2.0 later.
However, we still needed to overcome a few things. First, the new version of MNP had to coexist on the same machine with the remaining apps that used the old version. Second, to maintain compatibility with MNP-dependent apps, we had to maintain the same class names across both versions. In early testing, we saw the following error:
Compiler Error Message: CS0433: The type 'Microsoft.MSCOM.MNP.TableOfContents.TableOfContentsPage' exists in both 'c:\WINDOWS\assembly\GAC\MNP.TableOfContents\220.127.116.11__a75671c2b10b8543\mnp.tableofcontents.dll' and 'c:\WINDOWS\assembly\GAC_MSIL\MNP.TableOfContents\18.104.22.168__a75671c2b10b8543\MNP.TableOfContents.dll'
In other words, the compiler needed help to distinguish between MNP version 2.0.8 and the new version 2.1.0, which both existed in the GAC. We used bindingRedirects in Web.Config to explictly reference the correct assembly:
And in the page directive, we also had to force the pages using the classes in that assembly to use the new version:
Inherits="Microsoft.MSCOM.MNP.Framework.Page, MNP.Framework, Version=22.214.171.124, Culture=neutral, PublicKeyToken=a75671c2b10b8543"
This fixed the problems, and Microsoft.com has been running this site reliably since June. So while we encountered a few issues during the upgrade, the great news is that we're moving Microsoft.com to a very stable platform which is easier to maintain and troubleshoot (through improvements in CLR and the new eventing and tracing features).
In the future, I hope to provide more examples here of our internal customer experiences with ASP.NET 2.0.