In-Depth
Navigate the Road to Whidbey
The next version of VS.NET includes a plethora of enterprise and RAD features, but the tool remains geared more toward higher-end than occupational or hobbyist programmers.
Technology Toolbox: VB.NET, C#, SQL Server 2000, ASP.NET
Microsoft's claims for Whidbey—the next version of VS.NET—are impressive: It represents the maturation of all the .NET tools and technologies with support ranging from the smallest devices to the largest servers. Microsoft also asserts that the tool is friendly to all developers, from hobbyists to seasoned professionals. As usual, the reality falls somewhere between this description and the notion that Whidbey is a nice upgrade to familiar tools. Some of Whidbey's more ambitious features won't make the cut before it ships, and many will evolve into more usable forms of real tools. Will it make a substantial difference to Windows development?
Microsoft began active work on the next two VS.NET releases (the release after Whidbey is called Orcas) long before it released the current 2003 version. Whidbey and Orcas are tied to the next releases of SQL Server (code-named Yukon) and Windows (code-named Longhorn) (see the sidebars, "What's in a Code Name?" and "Riding Up to Longhorn"), respectively.
Microsoft started its marketing machine early for the initial version of VS.NET, announcing a ".NET Day" long before there were any products based on .NET technology. It's getting started even earlier this time; Microsoft has begun announcing many of these products long before public betas will be available. If you attended Microsoft's Professional Developers Conference in October 2003, you heard about little besides products and development tools that will be unavailable until well into 2004 and beyond.
Other articles in this issue drill down into the details of Whidbey's new features, but it's important at this early date to have a sense of perspective on what has been promised—and what you'll likely receive—as well as how the disparate announcements fit together. This analysis of Whidbey's importance to you as a programmer or system architect should help you understand better the real benefits Whidbey and Orcas are likely to deliver to you as you read about the specific features of different aspects of the tools.
This much is indisputable: Microsoft doesn't lack ambition. The company has focused its considerable development resources on making Whidbey a complete development environment that provides potentially radical productivity gains. Whidbey's enhancements aren't merely evolutionary, like VS.NET 2003's; they're almost as revolutionary as the initial releases of .NET and VS.NET 2002. The most interesting and obvious productivity features are in the Whidbey IDE (see Figure 1). Whidbey finally treats code as the complex beast it can be. I get the feeling the Whidbey developers opened VS.NET 2003 and Microsoft Word side by side and figured out how to apply Word's authoring tools to code writing. This approach makes perfect sense the first time you experience Whidbey features such as line-revision marks, smart tags that expose IDE operations related to code and objects in the editor, and even niceties such as auto save and restore. You'll wonder how you ever managed to write nontrivial code without these features that word processors have included for years (see Figure 2 and Figure 3).
On the downside, I suspect that Whidbey will benefit higher-end users and leave programming novices even further behind. VS.NET 2003 targets every developer, from beginner through seasoned professional, with multiple editions. As of this writing, Microsoft hasn't announced the Whidbey editions, but I expect there will be a spread similar to VS.NET 2003's targeting academic, professional, and enterprise developers, as well as the enterprise architect. There are a lot of new features that target less experienced developers, but you still must have a good understanding of the .NET Framework and the various related tools to be productive with Whidbey, even in VB.NET (see the sidebar, "Connect With Indigo"). This isn't necessarily a bad thing. No tool, or even a comprehensive collection of tools, can be all things to all people. If Microsoft is serious about being the enterprise tool vendor of choice, it's going to have to leave some developers behind. The good news is that Whidbey opens up amazing possibilities once a professional programmer works up and over the learning curve.
Desktop and Web Clients Win Big
One of Microsoft's primary goals with .NET is to provide a development environment that supports applications for any device that runs almost any version of Windows. Whidbey continues to simplify creating apps for any device, but its strongest support continues to be for client apps on the desktop and server apps on the Web. It's still a long way from a develop-once-and-deploy-on-any-device-interface model, but it's making progress.
Whidbey takes .NET's WinForms model much further than before with support for improved development and deployment models. You'll probably never again write Web browser-based applications for intranet use once Whidbey is released. Why use a browser with a stunted UI and lame client-side scripting to host an application, when you can have a rich forms-based interface with no deployment to the client other than the .NET Framework? It's probably safe to assume this is exactly what Microsoft had in mind when it announced it's no longer doing any serious work on new versions of Internet Explorer.
Whidbey also improves integration with Microsoft Office. The October 2003 release of Visual Studio Tools for Office (VSTO) targets the next generation of Office development. You can use new hooks in Word and Excel to write applications that respond to COM events from Office as readily as you can from VBA embedded within a document. Whidbey takes this functionality a step further with its active document container for hosting Office documents. The name choice is unfortunate (it evokes painful memories of VB5's short-lived Active Documents), but the container provides a new and far better way to use Office features in custom applications.
Whidbey's enhancements to ASP.NET's Web Forms aren't quite as radical as they are for WinForms, but they do make Web development better. New controls for accessing and displaying data will reduce the work required to create dynamic Web apps. Master pages simplify the templating approach to ASP.NET forms that use a base page class to share functionality between pages.
One interesting shortcoming: Whidbey doesn't fulfill the expectation Microsoft has set up that the features of each .NET language will blend gracefully into the others. One of the purported major benefits of .NET is the ability to write .NET applications in virtually any programming language. All .NET languages—including Microsoft's VB.NET, C#, Managed C++, and J#—compile to Intermediate Language (IL), so it shouldn't matter, in theory, which one you choose. However, the theory doesn't work in practice. All .NET languages do compile to IL, but not to the same IL. The performance and efficiency of the IL each language generates depends on how well that language's compiler optimizes the output.
Whidbey disunites .NET languages further. For example, C# now has a using block that destroys objects created within the block automatically, but Whidbey's Visual Basic includes no sign of an equivalent feature. Each language has a slew of new language features that won't appear in other languages for a while, if ever. This long list includes VB.NET's improved and simplified data source design and My tools, C#'s anonymous methods and enumerator patterns, C++'s Profile Guided Optimizations (POGO) and simplified managed code extensions, and J#'s browser controls, enums, and value types.
A Different IDE for Everyone
The Whidbey IDE also implements different features for each Microsoft .NET language. VB.NET has regained edit-and-continue, and it features the highest-level abstractions that automate code generation and reduce the amount of code required. C++ includes full support for Windows Fusion, which solves some DLL Hell deployment issues with native code. C# has new features that better support the creation of frameworks and automate code generation. (I'll probably use C# more for my apps after Whidbey is released because of these enterprise-level features alone.)
No .NET language I'm aware of makes full use of IL's capabilities, leaving plenty of room for enhancements in new language versions. IL itself continues to receive enhancements that take it out of sync with higher-level languages. If Microsoft can't keep any of its own languages in sync, it's unlikely third-party language vendors will do any better with the other 20 or so .NET languages. I think it's safe to say that no .NET language will ever be in complete sync with any other. The choice of language has never been and never will be a simple matter of personal preference or convenience. Too many performance and feature differences among them emerge as the various language teams—both Microsoft's and third-party vendors'—strive to improve their languages' features.
However, the lack of synchronicity among .NET languages is a non-issue. You might prefer VB.NET because you've used VB forever, or C# because you used to do C++ coding, or J# because you think Java is cool, or any of the third-party languages because you used them on a mainframe. Assemblies you write in one language are usable with all the others. If one language has syntax or other language features you need for an app, choose it over the others. Your enterprise might need to use a single language for easy long-term application maintenance or for other reasons. In other words, don't gnash your teeth over your language choice. Pick one and get on with life, but be prepared to change languages when your needs change.
The IDE changes are significant, but the database changes will probably affect you more. Whidbey offers deep integration with Yukon. Yukon will contain the .NET Common Language Runtime (CLR), so you can write stored procedures in any .NET language. As I write this, Yukon is in its limited first beta release and the new features aren't fully implemented yet, so it remains to be seen how tightly the CLR is integrated and how well code not written with T-SQL will perform. Whidbey enhances integration with Yukon in the other direction as well, by including features in VS.NET that make it easy to use SQL Server data in your custom applications. For example, it'll be easier than ever before to use the SQL Server Desktop Edition (MSDE) as the deployment database for your apps. All the development tools you need are right in the IDE, even if you develop apps against MSDE instead of SQL Server. A new deployment toolkit will remove much of the current pain of deploying MSDE and custom databases.
ADO.NET Simplifies Enterprise Development
Whidbey includes many ADO.NET enhancements that will make enterprise applications simpler to build. The best features let you simplify writing code, access various back-end databases, and implement a form of object/relational mapping. ADO.NET has always had interfaces, such as IDbConnection and IDbDataAdaptor, that let you write database-agnostic code. However, these interfaces included only a subset of features from the database-specific namespaces, such as SqlClient. Whidbey lets you isolate your custom code from the provider-specific code while giving up fewer features of the underlying data engine.
Business applications rarely use middle-tier objects that are a direct mapping of data as stored in a relational database. A .NET component isn't a relational object, even though a relational database is frequently the most convenient way to store the object's underlying state information. As a result, tool vendors are working to make the mapping from relational data to objects and back again a realistic technology. ADO.NET's typed datasets were a first step in the direction of Object Role Modeling (ORM), but they suffered from performance problems and were more of a relational-only model than a bridge between relational data and objects. Microsoft's first real ORM support in VS.NET is Whidbey's ObjectSpaces technology in ADO.NET. ObjectSpaces aren't an evolution of typed datasets; they provide a layer between object-oriented application logic and a data source that stores and retrieves object data. This means that the object doesn't need to have any information about the structure of the underlying data source, whether it's relational or some other kind of store.
Whidbey includes many other enterprise features, especially in the area of application lifecycle management (ALM). Microsoft has been working on a complete suite of ALM tools based on Windows and .NET (see my earlier article, "Microsoft Commits to ALM"). Whidbey is the company's first major push to turn VS.NET into a soup-to-nuts development solution that could leap ahead of other tools. Now that .NET and Visual Studio have matured a bit, they're in better shape to compete with open source tools initiatives in the Java and Linux worlds that have rivaled Microsoft's on a variety of platforms.
Microsoft's plans for ALM are breathtaking in scope. Its roadmap for Visual Studio states that it will include "support for requirements gathering, software analysis and design, application construction, configuration and change management, application testing, and software deployment and operations" (see Additional Resources). This is a tall order, not least because Microsoft has never seemed to take its configuration-management product, Visual SourceSafe, seriously. SourceSafe hasn't had a meaningful upgrade in years and has fallen far behind its competitors.
Visio is a wonderful graphics-design application, but the version included with VS.NET Enterprise Architect edition is too generic an environment for the demanding needs of enterprise-level applications. Visio lets you create nice Unified Modeling Language (UML) and entity-relationship diagrams easily, but it lacks some of the robust analysis and code-generation tools of more focused competitors such as UML tools from IBM Rational or ER/Studio from Embarcadero Technologies.
There are other issues. Visio's page-oriented metaphor makes it difficult to create and manage complex designs, and its usefulness for creating UML or database diagrams is severely limited. The database diagrams require strange kludges for effects Microsoft marketing claims it can achieve, such as merging together database submodels. Visio is used widely for enterprise architecture design simply because it is "free" with VS.NET, not because it's up to the task. There isn't any word yet whether Microsoft will continue trying to force-fit Visio into an enterprise design role. Instead, I hope the company will introduce tools that truly fill those needs.
You can address some of these shortcomings by turning to third-party tools and products. Microsoft—to its credit—has opened up third-party tool integration into the VS.NET IDE in new and innovative ways. IBM Rational's XDE Developer for UML designs, for example, feels as much a part of VS.NET as any designer. Support for third-party tool integration will be one of the keys to Whidbey's success.
Whidbey is a revolutionary product from a company with lofty ambitions to be the dominant player in the enterprise tools space. Microsoft has made many intelligent decisions in implementing these technologies and supporting a dizzying variety of application types on many platforms, but there are still significant holes to address, and it remains to be seen what shape Whidbey will take when it finally ships.