t the Professional Developer’s Conference (PDC) in Los Angeles this week, Microsoft’s presentations herald a sea change in application development capabilities. These changes have the potential to cause huge upheavals in the development and IT community. Many of the new capabilities shift responsibility for various aspects of application development from one group to another. Microsoft presented an enormous volume of exciting new technology and improved tools at this PDC, but despite this, one real question remains: How does all this new technology impact developers? The technological smorgasbord holds both real promise and presages some serious pain. With that, here’s what I think Microsoft is really saying.
The Future Belongs to Managed Code
If you’re not writing managed code now, you should immediately begin moving or planning to move your long-lived applications to managed code. Several presenters, including Bill Gates and Eric Rudder mentioned the importance of managed code in Microsoft’s vision of the future, saying that the framework will be “everywhere.” Although Microsoft plans to support unmanaged code for “a long time”, the duration of “a long time” was not specified. Five years? Ten years? Who knows?
Unfortunately, the level of support you can expect when moving applications forward is language specific. If you’re a VB classic programmer, but haven’t moved your applications to VB.NET because the upgrade path from COM-based programs to .NET has so far been rocky and labor-intensive, that hasn’t changed. The VB upgrade wizard has not featured prominently at this year’s PDC?in fact, it wasn’t even mentioned in the keynotes. But if you’re a C++ programmer, characterized by Brandon Bray as “the best programmers,” or a Java programmer, you don’t need to worry. Microsoft has made bringing existing C and C++ applications into managed code as easy as recompiling with a /clr switch. Bray boasted that a team was able to recompile Quake II to run in managed code in only one hour. Similarly, Microsoft has provided Java developers with the tools to port Java code to J# with little effort. It’s ironic that the “best programmers” get the most help in bringing their applications forward, while the “most programmers” get, well, I’m sure you’re well aware by this point exactly what you did get. The only bright spot for VB developers is that, for those who make the leap to VB.NET, Microsoft’s commitment to that language seems undiminished.
XML’s Early Promise Has Reached Fruition
XML is now ubiquitous, providing the foundation not only for Web services, but also for the new WinFS file system in Longhorn, data controls in VS Whidbey, Indigo (Microsoft’s new communications framework), the new format for Office documents, and, finally, as a declarative programming language called XAML. You can think of XAML roughly as the Microsoft equivalent of XUL. In one impressive demo, an XAML UI description, with tags defining buttons, text fields, images, and event handlers was combined with C# code dynamically to create a working form. This was done by taking advantage of the concept of partial types?a new framework capability that lets you define a class or other type among multiple files. By splitting the form definition across the XAML and .NET code files, organizations can offload design tasks to graphic designers while leaving implementation to developers. Adobe already has a graphic design tool that exports XAML, although that tool wasn’t part of the demonstration. Macromedia may not be far behind. The future is bright for graphic designers, at least until smart visual widgets appear and become commercialized (which may not take long). If you’re an ASP.NET developer, partial types and the idea of defining the UI in one file while implementing the code to activate it in another should sound extremely familiar (think code-behind), and your experience will stand you in good stead. It’s now obvious that a critical component of developers’ education lies in learning, using, and acquiring a deep understanding of XML and the various common XML languages.
Vector Victorious
The long-running feud between bitmaps and vector graphics has reached a new point of detente. Longhorn’s new Avalon graphic interface uses vector graphics. During the XAML/C# demo discussed in the preceding section, Don Box was able to tilt the entire form interface by ten degrees by adding a single tag attribute in the XAML file. Yes, the tilted interface included all the controls, even a combo box, which, when clicked, displayed its dropdown list using the same ten-degree tilt. The combination of XAML and .NET has enabled Microsoft to take the best ideas from HTML and browsers, such as simple declarative UI, flow layout, text reflow on resize, and style capabilities, and apply them to Windows development. While you may not want to display angled user interfaces in your own applications, you’ll still probably appreciate that this new layout and graphics capability make building resizable and localized applications a snap.
Downplaying Browsers
Microsoft is giving Windows applications browser-like features. As mentioned, the XAML/C#/Vector graphics combination brings tag-based development and simplified layout capabilities into the desktop application arena while ClickOnce deployment and Web services supply most of the advantages of browser-based application delivery while simultaneously removing many of the constraints. In this vision of the future, developers will be able to deliver Windows client applications that work both online and offline, and that can be installed or upgraded automatically or on demand from a centrally located server. Although much of this has been possible even with the current version of the .NET framework, via Assembly.LoadFrom, developing and deploying such applications has become a major and important feature in VS Whidbey. Still, many developers have shied away from building such applications now because the .NET framework is not available on enough client machines. Although Microsoft now provides the framework as a recommended download on Windows Update, ClickOnce is truly convenient and viable only if clients already have the framework installed. The number of machines with the .NET framework available will increase over time, but until then, browser-based applications will remain valuable.
Web Services Grow Up
Microsoft has made an immense effort to give Windows developers the tools to build robust distributed applications. The original release of Visual Studio .NET made building standard SOAP-based Web services easy. The upcoming Indigo communications framework and Yukon extend that simplicity to transactional, secure Web services. In Yukon, for example, you can expose any stored procedure, table, or view as a Web service, eliminating the need to write a custom database retrieval code within a .NET component to expose data via a Web service. That represents a huge savings in both Web services development and deployment. The message you should take away is that Microsoft’s commitment to Web services, far from waning over the past few years, has greatly increased. If you want your applications to deliver or consume the rich services being built today, you need to begin designing service-oriented applications. While Web services are not complete today, they comprise the infrastructure of tomorrow.
Office Development Is Moving to .NET
Although Office itself is not (yet) built in managed code, Microsoft has included new tools that embrace Office development and delivered them as an integral part of VS Whidbey. You can get .NET-based Office development capability today through the Visual Studio Tools for the Microsoft Office System from MSDN. In VS Whidbey, new Office project types let you target Word or Excel, and host those document types directly inside VS. Although VBA is still built into Office, it’s likely to become an increasingly less important part of future Office development, particularly as the .NET framework becomes more widely deployed, and IT staff become increasingly security-conscious. The message for VBA developers is that they have the breathing room to maintain their current applications, but that they should concentrate new development efforts on .NET.
To sum up, this PDC marks the end of the text-centric, tightly-coupled, COM-based era of Windows development. The future that Microsoft espouses is XML-centric, loosely-coupled, and .NET-based.
