In-Depth

Get a Grip on Longhorn

• 02/01/2004

Technology Toolbox: VB.NET, XML, Windows "Longhorn" (PDC Preview Edition, build 4051), Microsoft Longhorn SDK (PDC Preview Edition), Microsoft Visual Studio .NET Enterprise Architect "Whidbey" (Technology Preview)

Attendees at the Microsoft Professional Developers Conference 2003 took their first look at Longhorn, the future successor to Windows XP and, ultimately, Windows Server 2003. Even in Longhorn's pre-alpha state, there's a lot to like in this major Windows overhaul, which some analysts compare in importance to the move from Windows 3.1+ to Windows 95 (see the sidebar, "Longhorn Might Face Long Odds"). Major changes are in store for Visual Studio developers in the Longhorn era—the last half of the 21st century's first decade. I'll help you prepare for these changes by taking a close look at Longhorn's innovations and their implications for VS.NET programming.

The Win32 API, reigning king of the desktop for a decade, is dead; long live WinFX, Win32's successor. WinFX is a new .NET-based API that provides managed access to the three Longhorn pillars—Avalon, WinFS, and Indigo—and all other new Longhorn functionality. Secure managed code is in; native code and buffer overruns are out. The move from Win32 to WinFX is undoubtedly the largest software refactoring project ever attempted. Win32 will remain, of course, for backward compatibility, but WinFX is where the action will be. If you aren't using managed code for all new Web and Windows apps, it's time to refactor your development strategy. Win32 will go into maintenance mode in the Longhorn timeframe.

The primary benefit you'll gain from the refactoring of the Win32 API to a new set of .NET namespaces is rationalization and dramatic simplification of a code base that grew like Topsy over the last 10 or more years. The 70,000 individual APIs in the Win32 stack will shrink to about 8,000 .NET namespaces and types, according to an article by Paula Rooney about the Windows Hardware Conference (see Additional Resources). The WinFX Developer Preview chart, distributed to PDC attendees, lists 156 high-level System namespaces and types, most of which are available in the Whidbey Technology Preview installed on Longhorn. Providing a pair of APIs leads to a hefty installation footprint: The 32-bit PDC Client Preview weighs in at about 4 GB. Adding the Whidbey Technology Preview and Longhorn SDK brings total development installation disk space to about 7 GB.

WinFX divides Longhorn development projects into four basic application-model categories: Client (Avalon and Windows Forms), Web and Services (ASP.NET and Indigo), Data Systems (WinFS and Yukon), and Mobile PC and Devices (Compact Framework and Mobile PC Optimized). Each application model relies on namespaces and types classified as Presentation, Data, Communication, and Fundamentals groups. Presentation contains System.Windows (Avalon), System.Windows.Forms (Win32-based WinForms), System.Web.UI (ASP.NET WebForms), System.Help, System.Drawing, System.NaturalLanguageServices, and System.Speech namespaces. The Data namespaces include System.Data, which duplicates the .NET 1.2 preview version; System.Search and System.Storage to support WinFS and Windows Logging System (WinLS); System.XML; and System.Web's Personalization, Caching, and Session State namespaces. Communication offers System.MessageBus for Indigo, System.Messaging, System.WebSevices, System.DirectoryServices, System.Remoting, System.Runtime.Remoting, System.Discovery (for Active Directory and Universal Description Discovery and Integration [UDDI]), and System.Net. Fundamentals delivers common Base and Application Services, Security, Configuration, and Deployment/Management functions to all groups.

Declare Avalon Windows With XAML
Avalon represents a totally new presentation model for rendering Windows graphics. Avalon replaces traditional GDI and GDI+ bitmapped graphics with vector-based graphics delivered from what Jim Allchin described in his PDC keynote as a "cross-process compositing engine." Manipulating, buffering, and rendering bitmaps consumes an increasing percentage of available CPU cycles as displays increase in size and resolution. Scalable vector graphics offload the rendering and buffering chores to the display adapter's graphical processing unit (GPU). Avalon uses a single hardware driver to handle 2-D and 3-D graphics, and it takes full advantage of current and future GPUs' high-speed rendering engines. Avalon's unified System.Windows namespaces include UIElement, Documents, Shapes, Ink, Explorer, Navigation, Media, Controls, and Design. (MSAvalon.Windows maps to System.Windows in the PDC Client Preview.)

The Navigation namespace provides a uniform presentation model, which lets WinForms emulate Web apps with flowing text, forward-backward form navigation, and page history. Longhorn Navigation projects with Aero UI elements eliminate the disconnect users experience when alternating between Web and Windows apps (see Figure 1). Making thick clients resemble thin, browser-based apps appears to be one of Avalon's primary objectives.

Avalon also delivers a radical change to the WinForms design experience. Avalon substitutes declarative form design for the traditional drag-and-draw approach that VB 1.0 introduced and VS.NET extended to WinForms and Web Forms. Separating form design and control design from procedural code enables graphic designers to lay out an application's forms and then turn the design over to programmers to add business-logic code behind the forms. You generate an Avalon form and its controls with a new Microsoft XML dialect called Extensible Application Markup Language (XAML, pronounced "zamel"). You open a page in Longhorn's Internet Explorer (IE) 6.05 that contains a basic text panel by double-clicking on a file containing XAML code (see Figure 2):

<Document ID="root"
xmlns="http://schemas.microsoft.com/
	2003/xaml/"
xmlns:def="Definition">
	<AdaptiveMetricsContext>
		<TextPanel>
			This page was generated by 
			double-clicking a simple 
			XAML file that
			defines a text panel.
		</TextPanel>
	</AdaptiveMetricsContext>
</Document>

You're in for a surprise when you open a new Longhorn project in Whidbey. The seven Longhorn project templates add MyApp.xaml, MyApp.xaml.cs or MyApp.xaml.vb, Window1.xaml, and Window1.xaml.cs or Window1.xaml.vb to Solution Explorer, instead of Form1.cs or Form1.vb. MyApp.xaml is a markup file that defines the application object and its shared resources. The Window1.xaml markup file defines the application's primary window. The CS or VB code-behind files define startup and interaction logic for windows and controls generated by XAML files. Some templates, such as Longhorn Hosted Application, add a Panel1.xaml and code-behind files to define a primary panel. Hosted applications run in an IE sandbox. Fortunately, Longhorn templates include starter code to display an empty primary window and, if applicable, a primary panel when you run the project. IntelliSense simplifies adding Avalon SimpleText and control objects, such as a ComboBox and Button to the XAML file.

Delegate Event Handling
You delegate window and control event handling to VB procedures or C# functions in Window1.xaml.vb or Window1.xaml.cs by adding an attribute/value pair to the root window or a control. For example, the <Window ... Loaded="OnLoaded" > attribute passes the Loaded event to a Private Sub OnLoaded ... event handler. Similarly, a <Button ... Click="ButtonClicked" attribute enables you to add a Private Sub ButtonClicked ... delegate (see Listings 1 and 2 and Figure 3).

The PDC Hands-On Labs' UsingAvalonInWindowsForms sample application (HOL-010) demonstrates how to add Avalon controls to a conventional WinForms project that replaces XAML with procedural VB.NET code. Code in Sub Main spawns a separate thread for the Avalon controls in this case. You add an Avalon ElementHost to a WinForms Panel control, establish an Avalon DockPanel as an ElementHost child, then embed Avalon controls as DockPanel children (see Listing 3). The process isn't simple, and Avalon controls aren't visually consistent with WinForms controls (see Figure 4.)

Microsoft's goal for the WinFS storage subsystem—the second Longhorn pillar—is to provide users with unified views of all their data and eliminate wasted hours searching for individual documents, messages, images, and other media related to the task at hand. The 70 percent per year increase in individual disk capacity over the last decade demonstrates a corollary of Parkinson's First Law: Saved data expands to fill available disk space. As the number and types of files on users' machines grow, the difficulty of organizing data storage in hierarchical folders and finding files buried in the hierarchy becomes overwhelming. Windows' Indexing Service was a first step toward organizing data by attributes but required users to complete the Summary page of Filename Properties dialogs and learn an arcane query language to perform a useful search.

Longhorn adds Documents, Contacts, Photos and Videos, Games, and Music WinFS folders for storing files or links to files of the corresponding types. You can't use New | Folder to create a new folder in the WinFS folders, but you can add groupings based on property values (called stacks) to Documents. Items in default locations represent pointers (called holding links) to files stored in the WinFS DefaultStore or in other NTFS folders. For example, the 11 games included with Longhorn appear in Games and are classified by Title, Genre, Publisher, and Developer, and they link to the Game Library's GDF folder that's buried in your \Documents and Settings folder.

WinFS automatically creates a separate stack for each Category property value when you copy a subfolder of Word files to Documents; files whose Category value is missing fall into the default (flat) Documents list. You'll also notice that updates to WinFS' Yukon-based relational engine slow down copying files or importing contacts to these default WinFS folders. Longhorn's Outlook Express 7 uses Contacts as its address book; clicking on the Addresses button or My Contacts link opens the Contacts window. Contacts has an Import Wizard for adding Contact Items from Exchange Server, VCard files, and legacy Windows address books (WAB files).

Access Items as .NET Objects
The WinFS data model consists of Items, Relationships, and Extensions. Items use an XML schema to define the metadata properties of everything that's stored in WinFS. The schema lets WinFS serialize Items as .NET objects, which you access with members of the System.Storage namespace. For example, System.Storage.Contact provides the context required to find, add, and delete Person objects, which have DisplayName, PersonalEmailAddresses, PersonalTelephoneNumbers, and several other predefined properties. The Longhorn SDK's strangely named "Hello World Using 'WinFS' and Windows Forms" sample project (listed under Samples, "WinFS") shows you how to manipulate Contact Items. Populating a listbox with Contact display names and e-mail addresses takes only a few lines of code (see Figure 5).

Relationships create joins between Item metadata values to return multiple Item types in query resultsets. For example, you can relate an Office document's Author property to a Contact Item's DisplayName property. A natural-language search returns links to matching document and contact Items. Extensions let you add new properties to an existing item's XML schema. Other WinFS features include Notifications, which let users subscribe to events raised by Item-related changes. Synchronization between WinFS stores on multiple machines takes place through a "community folder" that's associated with groups of Items on local machines. Synchronization replicates Items between machines according to instructions contained in send-only, receive-only, or send-receive synchronization profiles. Information Agents automate actions for users based on WinFS data, rules, preferences, and contexts.

WinFS in the Longhorn PDC Preview isn't fully cooked. Clicking on the Search button of the Contacts or Documents window opens the standard Windows XP search pane, not a WinFS-enabled natural-language search window. The Aero UI for direct interaction with WinFS is missing, but you can preview some experimental WinFS UI elements in Microsoft's "The Windows File System" white paper (see Additional Resources). According to Quentin Clark, Microsoft's director of program management for WinFS, the "fundamental model" will be complete in beta 1, but plan on waiting for beta 2 to explore the final WinFS UI. In the meantime, test-drive the Longhorn SDK's WinFS samples, most of which (as usual) are C# console apps, to gain a developer's perspective on this new approach to information management. If you hope to derive any future productivity benefits from WinFS, convince users to complete the Summary page for all documents that offer a Properties dialog. Establishing a standard document Category taxonomy today will return substantial dividends when your organization upgrades to Longhorn.

Board Indigo's Message Bus
Longhorn's third pillar is Indigo—a set of messaging services that provide secure and reliable asynchronous communication channels between applications or independent systems over multiple network transports. Indigo supports two basic application types—Web services and RemoteObject services—that share a common Simple Object Access Protocol (SOAP) messaging, security, and transaction infrastructure. Web services replace traditional ASP.NET ASMX projects, and RemoteObject services supplant .NET remoting.

Indigo—represented by the System.MessageBus namespace—is the plumbing for Microsoft's next generation of service-oriented architecture, design, and programming practices (see Additional Resources). Indigo subsumes the Web Services Enhancements (WSE) 2.0 Technical Preview's WS-Security, WS-Policy, WS-SecurityPolicy, WS-Trust, WS-SecureConversation, and WS-Addressing implementations, and it adds support for WS-Federation, WS-ReliableMessaging, and WS-AtomicTransactions. Indigo consists of Service Models (System.MessageBus.Service), Connectors (System.MessageBus.Channel, System.MessageBus.Transport, and System.MessageBus.Port), and Hosting Environments, such as an EXE file, DllHost, NT service, or ASP.NET/IIS. Indigo relies on the Base and Applications Services Group for federated and single-domain security functions (System.Windows.TrustManagement, System.MessageBus.Security, and System.Security) and configuration services (System.MessageBus.Configuration).

Indigo is much closer to fruition in the PDC Preview bits than WinFS, and Microsoft promises to provide Indigo implementations for Windows XP and Windows Server 2003. This makes good marketing sense, especially for Windows Server 2003. Otherwise, the release version of the Longhorn client wouldn't have Indigo-compliant servers with which to trade messages. Arrival of Indigo in the Whidbey timeframe—prior to Longhorn's release—means that WSE 2.0 will have a relatively brief lifespan. Indigo installations on pre-Longhorn OSs, however, aren't likely to fully support all WS-series specs.

The Longhorn SDK adds three Indigo templates to the Whidbey Technology Preview: Indigo Service Framework Service, Indigo Messaging Framework Service, and Indigo Messaging Framework Client. Indigo Service Framework Service implements a default "Hello World" Web service hosted as an EXE file. The Messaging Framework Service template contains the code to run a sample asynchronous MsgSvrService, which listens for and receives a SOAP request message over TCP from the Messaging Framework Client's default MsgClient, and then sends the client a response message. Test-drive the service and client by creating default IndigoMFxService1 and IndigoMFxClient1 projects. Uncomment the lines beginning with Console.WriteLine in IndigoMFXService1's ProcessMessage function, then press F5 to build and run the message-server project, which opens a Command window. Add a breakpoint on the Finally line of the MsgServerClient's SendMessage Sub or function, then run IndigoMFxClient1, which also opens a Command window. Press Enter in the client's Command window to send a message to the server and display the response message ("How are you?"). Display the server's Command window, which shows the request message ("Hello from MsgClient") and other incoming message details (see Figure 6). Then, give IndigoMFxClient1 the focus and press F8 to close its Command window.

Easy creation of basic, point-to-point ASP.NET XML Web services has been one of VS.NET's hallmarks since version 1.0. At this point in Indigo and Whidbey's development, developing an interoperable SOAP 1.1 or 1.2 Web service and client consumer involves a steep learning curve and hand-writing a substantial amount of code. It's a good bet that later Whidbey versions will include wizards to generate the code and configuration files that are required to take advantage of Indigo's feature set under Windows XP and Windows Server 2003.

The economic and security traumas of the past few years have jaded IT management, developers, and users. The enthusiasm demonstrated by PDC attendees for the three Longhorn pillars shows a potential to reverse this dismal trend. If you don't have the PDC bits, beta 1 of Longhorn and VS Whidbey should arrive in a few months. If you want a shorter-term payoff for the time you invest in exploring Longhorn, concentrate on Indigo's MessageBus. Otherwise, make the effort to gain an equal working knowledge of all three pillars. If Microsoft's bet on Longhorn pays off, you'll be amply rewarded by the demand for competent Longhorn programmers.

• Code Download