Lambda expressions, new in Visual Basic® 2008, are a handy addition to any programmer's toolbox. They are callable entities that are defined within a function, and they're first-class citizens; you can return a lambda expression from a function and you can pass lambda expressions to other functions. Lambda expressions were added to Visual Basic 2008, formerly code-named "Orcas," in order to support Language Integrated Queries (LINQ), which adds data programmability to Visual Basic (more on that later). As you use lambda expressions, you will begin to see the power and flexibility they promote. I invite you to sample the basic concepts of lambda expressions, explore their benefits, and witness how to use them to write more expressive programs.

Knowing that I love to play with such things, a friend recently asked me to help write a simple tool that could export to Microsoft® Excel® a sortable list of all the members of a new assembly that she was required to document. The tool needed to provide information about the properties, methods, events, and interfaces, and list all the parameters for each of the members. Having played with reflection before, it seemed like fun. As I began, though, I kept finding member names that were formatted oddly.

It turns out that names like those exist for a reason. The Microsoft .NET Framework exposes information about generic types and methods differently than it does for those that are non-generic. This realization led me to investigate—and now document—reflection features as they relate to generics. While generics are new as of the .NET Framework 2.0, using reflection to investigate and fabricate or call generic types and methods isn't terribly difficult.

If generics are completely new to you, see "Overview of Generics in the .NET Framework" at msdn2.microsoft.com/ms172193. Most importantly, review the terms described in the article because my goal is to show you how to extend existing reflection-based applications to handle generic types and methods.

By now you've probably heard of LINQ (or Language Integrated Query), the new query technology coming in Visual Studio® 2008. LINQ-enabled languages like Visual Basic® give you a rich set of query operators that can be applied to various data sources, such as in-memory collections, databases, datasets, and XML. That alone is pretty cool, but Visual Basic 9.0 actually goes beyond that and makes XML a first-class data type directly in the language.

Now you may be wondering why you would want an XML data type integrated directly into Visual Basic. Today many applications use XML for both storage and data transfer. XML has gained broad adoption across the industry due to its flexibility and simplicity, and it is used in many apps for both storage and data transfer. It works particularly well for transferring data among systems since it is self-describing (meaning that the structure of the data is included with the data). Plus, it's much easier to read data structured inside XML tags than it is to write parsing logic for various custom file formats.

The problem with XML, however, is that it has never been particularly easy for developers to work with. Awkward and inconsistent APIs, such as the Document Object Model (DOM), and languages such as XSLT and XQuery lead to writing a lot of tedious code that is often difficult to read and understand. But with the introduction of LINQ and Visual Basic 9.0, XML development becomes much easier. In this column I will explore the current XML programming experience, how LINQ improves the experience, and how Visual Basic provides even more support when working with XML.

XML comments provide an easy and effective way to document your code. We’ll show you how to use and customize XML comments in your Visual Basic projects.

Standard refactoring techniques coupled with automated refactoring tools provide an excellent platform for upgrading legacy VB code. Legacy VB code suffers poor structure and ‘bloated code’ due to lacking inheritance and other object-oriented capabilities. Upgrading old VB code without any restructuring will not bring the benefits of .NET architecture. Restructuring legacy VB code in order to eliminate most obvious shortcomings can often help us discover much more efficient and robust design, and even code that we were poised to discard can find new life in the .NET world.