For many people change is a scary concept - and in the world of technology it can cause a roller coaster ride of emotions. As developers, you would think that we would be used to change, as we are typically the instruments of change. But try as we might, the new release of a software product causes a good amount stress in terms of having to learn new approaches, change our processes, and possibly rethink how we do things. On the other hand, progressive change that complements our processes, expands our thinking, and provides us with powerful new approaches - although rare - is highly welcome. We often term this type of change - evolution.

Evolution is exactly what the next release of the Microsoft Framework and Visual Studio .NET is all about. As stated by Microsoft senior vice president of Servers and Tools, Eric Rudder, "Developers are the driving force behind the success of not only Visual Studio, but of Microsoft itself." Microsoft has worked very hard to ensure that with the next release of .NET, developers realize that they are the key to the success of Microsoft. Whidbey, the Microsoft internal code name for the next .NET release, isn't simply a bunch of new features but rather real improvements that endow software developers at all levels with new power and flexibility.

With this article we are going to dive into some of the key improvements that are slated for Whidbey. We will establish a foundation and in the future, through this column and other articles in .NET Developers Journal, we will explore the key areas of Whidbey and provide you with the knowledge, information, and skills that you need to embrace this evolution in how we approach the craft of software development. But before we begin, a quick disclaimer is necessary. It is important to understand that the information I discuss in this article is subject to change. Although Whidbey is rather far along in its development cycle, with those attending the Microsoft Professional Developers Conference in October getting advanced copies, it is the prerogative of all software developers to change their minds about what makes it into a final release. So keep in mind that what I discuss here may change by the time Whidbey becomes a released product.

Something for Everyone
The Whidbey evolution does not discriminate; there are key improvements that affect developers and architects of all languages. Whidbey brings a series of enhancements and altogether new advancements to all areas of the .NET Framework and Visual Studio. Whidbey affects the class libraries, the CLR, all core .NET programming languages, and the IDE. Whidbey also sets the stage for a longer-term vision that begins to more tightly integrate language and data. For instance, when the next release of Microsoft SQL Server, code-named "Yukon," becomes available, developers will be able to write stored procedures using .NET languages such as C#, Visual Basic, or possibly even J#. Isn't it amazing what you can do when you have a common type system and robust intermediate language?

You can break down the Whidbey evolution into three areas of the .NET and Visual Studio DNA: programming language enhancements, .NET Framework changes, and enterprise development enhancements. In the area of programming languages there are key changes to C#, Visual Basic .NET, J#, and C++. The framework changes include improvements to the WinForms rendering engine and ADO.NET, plus better support for new or updated Web services standards. Enterprise developers are not being left behind in this evolution, as Microsoft has included enhancements or new tools that improve application design, management, and deployment. The ".NET Developer's Journal Guide to Whidbey" that accompanies this article will help you gain a better understanding of what is coming with Whidbey. The remainder of this article will highlight some of the key aspects of what is changing and give you some previews of what to expect and what to consider now so your system can evolve with .NET.

Language Enhancements
As we now know, all the languages that ship with Visual Studio will be updated. Visual Basic developers can look forward to enhanced debugging, better support for data-driven applications, and advanced features like unsigned data types, operator overloading, and partial types. C++ developers will find they now have better support for MFC integration with WinForms, the ability to develop native C++ applications in Visual Studio .NET, and a new technology known as Windows Fusion to help manage native DLL deployment. C# developers will now have access to generics, anonymous methods, iterators, and other features that dramatically improve code reuse and streamline software design. Visual J# developers will now have support for the "assert" and "volatile" keywords, and can now author Enums and value types. This will help set the stage for J# to take advantage of generics and other key CLR enhancements in the future.

One of the areas of the Whidbey evolution that is very exciting is that of code reuse and streamlined code design. The Microsoft .NET team has added a series of enhancements that will help developers and architects take things to the next level of elegance when it comes to software design and reuse. Generics, iterators, anonymous methods, and partial types are powerful new capabilities. I will spend a little time here to help you understand more about them.

Generics
Generics is a powerful concept that allows us to design code that can adapt to execution requirements. Consider a situation in which you have a bit of code that manages a list of items and also allows the items in the list to be sorted or printed. Now consider that the requirement is that your application keep a list of "patients" that would more than likely be stored as a String data type, and another list of "patient temperatures" that would be stored as an Integer data type. Today, you would have to create two code snippets to manage this, even though all the sorting and printing code is the same. Basically, you pay a penalty in this case to make things, well - generic. In Whidbey, the use of generics will allow you to create a generic list that can have its type defined at runtime. So you might have something that looks like this:

MyList<DataType>

in which

<DataType>

is a place holder that can be defined later, thereby allowing you to use the same snippet of code for different types of data and thereby getting a high level of code reuse and all the subsequent benefits associated with maintaining a single code base.

Iterators
ForEach is a handy little approach and can be rather powerful. For readers who don't know, ForEach relies on a what is known as the "enumerator pattern." Unfortunately, writing an enumerator - a good and well-behaved enumerator - can be a difficult endeavor. Iterators help to reduce complexity and, subsequently, errors and problems by allowing us to move through a list or collection using a higher-level technique that is simple and elegant.

Who Was That Method?
Ever consider how wonderful life would be if you could just do what you want when you want? For software developers, the introduction of "anonymous methods" is a step in that direction. Anonymous methods are defined dynamically at the point where they are used, rather than at some specific point, such as in a class. One of the powerful concepts of anonymous methods is the ability to change the method signature at runtime. This type of dynamic support helps to reduce the need for complicated object designs and allows you to focus on writing more flexible software without having to jury-rig your design.

Going Halfway
In many software design situations you can create base functionality, but as user and business requirements change you find that the core functionality of a routine needs to adapt or be defined later. Consider the scenario in which you have a patient going into a hospital for treatment. You know you will need to collect the patient's vital signs but beyond that you aren't really sure what to do with the patient. Using the new partial types capability in Whidbey, you don't really need to worry about how to deal with the patient until that behavior is ready to be defined. Here's how it works.

Let's create a class called "Patient" and define it with the "partial" keyword so it looks like this:

public partial class Patient

We then define some variables of the class, such as blood pressure, temperature, height, weight, and gender. Later, we can create another class called Patient and use the partial keyword. At runtime the compiler will bring together the two classes and treat them as one class. This is a very powerful concept that allows developers to model software more closely to how the real world works.

Continuing Evolution
Whidbey is not the end of the line in our evolution. Microsoft is already working on the release after Whidbey - known as "Orcas," which is targeted for release in 2005. It's important to recognize that change is only difficult when it occurs without planning or notice. When change is well thought out and part of a long-term vision, it is easier to accept and plan for - and, well, evolve.

This article was meant to give you just a taste of what is coming. In future articles I will dive deeply into generics, partial types, the improvements in the WinForms threading engine, and the new debugging enhancements. Microsoft may be responsible for giving us the tools for evolution, but my sincerest hope is that I provide you with the knowledge and power to utilize those tools. Let the evolution continue!

SIDEBAR

.NET Developer's Journal Guide to Whidbey
Programming Languages
Visual Basic

• XML Support in Whidbey