| Whidbey
: The next evolution of .NET |
 |
| By
John Gomez |
 |
| 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! |
 |
| About the Author: John Gomez,
open source editor for .NET Developer's Journal,
has over 25 years of software development
and architectural experience, and is considered
a leader in the design of highly distributed
transaction systems. His interests include
chaos- and fuzzy-based systems, self-healing
and self-reliant systems, and offensive security
technologies, as well as artificial intelligence.
John started developing software at age 9
and is currently the CTO of Eclipsys Corporation,
a worldwide leader in hospital and physician
information systems |
 |
| |