In-Depth

Longhorn Redux

The next version of Windows will differ dramatically from its PDC 2003 preview version. Gauge the impact, if any, that Longhorn and its back-ported Avalon and Indigo components will have on VS developers.

The Longhorn feature set has undergone a major metamorphosis since Microsoft released the first Preview Edition at 2003's Professional Developers Conference. The original three "Pillars of Longhorn"—Presentation (Avalon), Data (WinFS), and Communication (Indigo)—have dropped to two. WinFS and the System.Search, System.Storage, and System.Data.ObjectSpaces namespaces are missing as elements of the Longhorn client and server releases that are now scheduled for 2006 and 2007, respectively. (Microsoft promises a WinFS preview or beta version for release with Longhorn client.)

Microsoft has now back-ported the remaining two Longhorn pillars to Windows XP SP-2 and Windows Server 2003. You can download the release candidate for the Beta 1 runtime of Avalon and Indigo and an ISO image of the Visual Studio 2005 Beta 2-compatible WinFX SDK. Promised Longhorn-specific features are missing from the forthcoming Office 12 upgrade, and there's little news about the post-2005 version of Visual Studio—codenamed Orcas—that once was to accompany the release of Longhorn client. Orcas is now scheduled to release in the Longhorn server timeframe.

Developer mindshare and enthusiasm are the key to operating system success and are unquestionably responsible for Steve Ballmer's infamous "Developers! Developers! Developers! ... " mantra. The premature hype for Longhorn that Microsoft generated at PDC 2003 appears to be morphing into developer ennui as release dates slip and Microsoft back-ports the two Longhorn pillars to current Windows versions. A search of the Tech•Ed 2005 Agenda & Sessions page with Longhorn as the keyword returns only four breakout and two birds-of-a-feather sessions. The paucity of Longhorn-related Tech•Ed sessions for a new Windows operating system that's scheduled to release next year is surprising.

PDC 2005 promises to unveil the "next waves of Windows 'Longhorn' features and Microsoft Office System platform" in mid-September. But with Windows XP SP-2, Windows Server 2003, and VS 2005 supporting Avalon and Indigo, there's little—if any—incentive for professional .NET developers to target with Orcas what promises to be a small initial Longhorn installed base.

Longhorn client and Avalon-based Windows forms appear to be intended primarily for consumers rather than corporate users. Vic Gundotra, general manager of Microsoft's Developer Platform and Evangelism group, emphasizes simplifying users' access to "music, photos, documents, feeds, and other sources of data" while protecting them from "viruses, malware, and other malicious hacker-inspired code" with Longhorn. However, Windows AntiSpyware and the forthcoming Windows OneCare service promise consumers running Windows XP similar protection. Gundotra contends that Indigo simplifies the .NET programming model, but replacing ASP.NET 2.0 Web services and Web Service Extensions (WSE) 3.0 with Indigo's message bus and its underlying WS-* specifications clearly is a long-term endeavor for developers who are planning or implementing service-oriented architecture (SOA).

Most new features planned for Longhorn server benefit network admins rather than VS 2005 developers. However, Longhorn does promise a major upgrade to Internet Information Server (IIS) 5.0 and 6.0. Scott Guthrie, Microsoft's Product Unit Manager in charge of the Web platform and tools team, provided an early introduction to IIS 7.0 in a two-part Channel 9 interview (February 24, 2005 and February 28, 2005).

Guthrie describes IIS 7.0 as a "major, major, major release" for Longhorn. He emphasizes the capability to configure IIS 7.0 by ASP.NET Web.config files, instead of the IIS metabase. This eliminates the need for ASP.NET developers to be Web server machine admins, and lets site owners and app developers administer their own virtual directories. The ASP.NET application's Web.config file also includes Indigo configuration settings.

Guthrie also explains that IIS 7.0 is componentized and substitutes individual modules for the unmanaged ISAPI extensions of IIS 6.0 and earlier. The Web server consists of 40 to 50 managed-code modules; modules also include native-code versions as required by the operating environment. You minimize the Web server's attack surface by choosing which modules to install and writing custom managed-code modules or HTTP handlers to add any special features your applications need.

IIS 7.0 also improves error handling by storing request exceptions in a buffer that's saved to a log file for debugging and performance analysis. Tech•Ed 2005's WEB340 breakout session, "IIS7: Discover and Move to the Next Generation Web Application Server Platform," provides an advance look at this totally refactored Web server (link requires login).

Other bloggers familiar with IIS 7.0 note that today's incarnation runs under Windows Server 2003 SP-1. This means that Microsoft might decouple IIS 7.0 from Longhorn and, like Indigo, enable ASP.NET developers to run the new Web server services without waiting until 2007 or later for Longhorn server. Microsoft's current plan is to include a request-limited IIS 7.0 version with Longhorn client and the unrestricted version with the server edition.

"Longhorn waves" certainly won't generate a tsunami in this decade and, unless Longhorn client gains more favor than expected with Fortune 1000 IT departments, might fade to ripples in the next five years. Adding a 450-MB Avalon/Indigo runtime to the .NET Framework 2.0 setup for Windows XP clients and Windows 2003 servers carries an insignificant installation penalty for existing OSs. Waiting two or three years after Orcas for the succeeding Visual Studio version—code-named Hawaii—and a significant Longhorn client installed base appears to be a viable option for professional VS developers. VS Hawaii probably will support the Microsoft Business Framework's object-relational mapping features that were originally intended for inclusion with VS 2005 as ObjectSpaces but then rescheduled for integration with Longhorn and the now-missing WinFS pillar. In the meantime, count on Longhorn and its immediate successors to exhibit substantial short-term and long-term uncertainty for .NET development opportunities.

About the Author

Roger Jennings is an independent XML Web services and database developer and writer. His latest books include "Special Edition Using Microsoft Office Access 2007" (QUE Books, 2007) and "Expert One-on-One Visual Basic 2005 Database Programming" (WROX/Wiley, 2005). He’s also a VSM contributing editor and online columnist and manages the OakLeaf Systems blog. Jennings’ Code of Federal Regulations Web services won Microsoft’s 2002 .NET Best Horizontal Solution Award. Reach him at [email protected].

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube