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.
The team has a RTM/RC version ready and it's in test. We should have something up on atlas.asp.net in the next day or two - early next week at the latest. I know a lot of people at PDC are asking so hopefully this will save someone the time of uninstalling a RC build and putting on Beta 2. We'll keep the Beta 2 versions around too, at least until Whidbey launches.
One of my roles in the Web Platform & Tools team is managing our ASP.NET websites, including www.asp.net, beta.asp.net (running ASP.NET 2.0 since April!) and the ASP.NET Forums.
We’re about 15 minutes away from going live with our new Atlas.asp.net preview website which will show the world what we’ve been doing with Atlas since Scott blogged it in June. Since then, the developers have been working at an amazing pace to get the preview together and ready for the PDC and I think we’re going to surprise people with what we have to date.
The site will include all of the Atlas content for PDC, including Hands-on labs, live quickstarts demoing Atlas features, documentation, and VSIs for creating your own Atlas apps with Visual Studio 2005! In the coming days, we’ll have even more – an Atlas Wiki, that demonstrates many of the great features we’ve built in. There are also three new Atlas forums for questions, feedback and bug reports. This is a technology preview - not even a beta, so we're relying on your feedback to help us improve Atlas even more in the coming months.
Everything goes live at 8:00am PDT. Check it out and let us know what you think!
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\22.214.171.124__a75671c2b10b8543\mnp.tableofcontents.dll' and 'c:\WINDOWS\assembly\GAC_MSIL\MNP.TableOfContents\126.96.36.199__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=188.8.131.52, 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.