The upcoming release of the .NET 2.0 framework brings many new enhancements to the CLR and the C# and VB.NET languages, and with the availability of Beta2, it seems like an appropriate time to dive into the .NET 2.0 framework and see what’s cooking. Since .NET is a platform that supports multiple languages my approach with each new release has been to review what the CLR has to offer first, since it is the foundation for all languages, and then review what is common for the languages I use the most, which are C# and VB.NET. Last, I review each language on its own to see how each enhancement can solve the particular shortfalls of the previous version and how the new enhancements can improve the clarity and efficiency of my code. Now with this solid understanding behind me I can make better decisions as to which language or languages to use on my next project.

CLR Enhancements
The new enhancement that stands out the most in terms of enterprise computing is the 64-bit version of the .NET framework. This version of the framework allows you to take full advantage of the underlying 64-bit hardware platform without having to deal with the differences between 32-bit and 64-bit hardware platforms. What this means is if you created a 32-bit application that doesn’t rely on floating-point numbers or native code you can simply compile your code using the 64-bit compiler, for your language of choice, and begin running your application on a Windows 2003 SP1 or Windows XP 64-bit operating system with no modifications.
   
Generics are another enhancement that I will keep under the CLR umbrella due to the CLS compliance to them. Generics provide developers with a way to create type-safe data structures consisting of classes and interfaces that are data-type agnostic. This means that when you declare your type-safe data structure you put a placeholder for the agnostic type and during instance creation you specify the actual type used. An example of creating a custom generic type can be seen in Listing 1. One of the strengths you can see right away with Generics is their use in collections where you were previously forced to use the System.Object data type no matter what type you passed in. This of course incurred boxing for value types which let to a performance hit. To help us out Microsoft has created the System.Collections.Generic namespace. It provides an assortment of commonly used generic collections that you can use so you don’t have to create type-safe collections by hand unless you want to.
   
Friend assemblies are another new enhancement that enable developers to expose C# internal and VB.NET friend decorated types and methods to multiple assemblies. In the past this was accomplished by either making the type public, which exposed the type to all assemblies, or decorating each type or method with the StrongNameIdentity- Permission attribute, which was time consuming and error prone. With friend assemblies, adding the [assembly:InternalsVisibleTo(“AssemB, PublicKeyToken= 32ab9ba32e0a51a1” )] attribute to the assembly allows all friend-specified types or methods to be visible in the named assembly.

VB.NET and C# Common Language Enhancements
As I mentioned earlier it is always nice to know what is common across all of the languages you commonly use. This can be very helpful especially when working on a large team with different language skills. In this section I am going to cover some of the common enhancements of C# and VB.NET and describe differences they have, if any.
   
Partial types provide the ability to break types up into multiple files. An example of this can be seen in VS 2005 when creating WinForm applications. The VS 2005 IDE generates two files FormName.(cs or vb), which is were the event-generated code goes, and FormNameDesigner.(cs or vb), which is were the form’s auto generated code that Visual Studio generates goes. This breakup of the form class allows developers to write code in an area that the code generation feature of Visual Studio’s editor will not overwrite when they change things on a form. It should be noted that the implementation of partial types is different in each language, with VB.NET supporting classes and structures and C# supporting classes, structures, and interfaces, but with both languages requiring the partial keyword in the type declaration of each file.
   
Accessor accessibility is a feature that enables the developer to assign different accessibility to property get and set accessors. In previous versions of both languages you could create read-only properties that would allow only reading of a property, but you were never able to treat the get and set accessors differently in terms of accessibility. Now you can assign different accessibility keywords to the get and set accessors controlling who can see which accessor. This means that you can now declare a property that can be externally read-only and internally read/write by setting the get accessor to public and the set accessor to protected (see Listing 2).

C# Language Enhancements
In previous versions of C# when you wanted to create a collection class that supported foreach it was necessary to implement the System.Collections.IEnumerable and System.Collec-tions.IEnumerator interfaces. New to C# are Iterators, which are a section of code that returns an ordered sequence of values and can be used as the body of a method, an operator, or a get accessor. To code an Iterator you use the yield return statement to return each requested element as the foreach loops through your body of code. The return type of this body of code must be of type System.Collections.IEnumer- able, System.Collections.IEnumerator or one of the generic iterator interfaces in order to work. For a more detailed explanation of how to implement Iterators, please see Jason Whittington’s article Iterators in C#: “For Each ++: Iterators in C#” in the November issue of .NET Developers Journal (Vol. 2, issue 11).
   
Delegates (the .NET equivalent to function pointers) have been around since the beginning of .NET. Currently when using delegates, the developer has to create a method that would match the delegate signature and then tie the method to the delegate, which in some cases was a lot of overhead for a simple code block. Anonymous methods now let you create code “inline” when declaring a delegate type. This means that you can insert a code block inline with the delegate type declaration and not be required to create a separate method. In this “inline” code block you can reference variables outside the scope of the code block and pass parameters in as well. To create a delegate type that references an anonymous method, use the code block creation expression, which takes the form: delegate [(parameter-list)] { anonymous-method-block } (see Listing 3). There are a few rules to follow when using anonymous methods; they are detailed in the .NET SDK, so you might want to read them before jumping into things.


  
Let’s stay on the topic of delegates for just a little bit longer and talk about how delegates work with types. Currently delegates require an exact match of types between the signature and each instance declaration. This means that both the signature and the instance declaration must have the same parameter and return types. New to C# is the ability to have parameter and return types that are inherited from the type in the delegate signature. To clear this up, think about the age-old example in OOP books of a parent type of mammals and a derived type of dog. In the case of delegates you can have the type mammals in the signature and use a type of dog in the instance declaration. This works on the principle that since the return or parameter type is more specific than the delegate signature’s return or parameter type, the type can be implicitly converted. The flexibility that this feature provides makes it easier to create more general delegate methods that can be used with a larger number of classes.
   
A few final enhancements to wrap up under C# are Namespace Alias qualifiers, the extern modifier, static classes, and fixed size buffers. First the Namespace Alias qualifier gives the developer the ability to access a member in the global namespace by prefixing the namespace with the Global: syntax. This can be handy in situations where namespace duplication may occur and can sometimes be the only way to guarantee that you are calling the root namespace. Second is the extern modifier, which is used in a method declaration to indicate that the method is implemented externally. A common use of the extern modifier is with the DllImport attribute or to define an external assembly alias, making it possible to reference different versions of the same component from within a single assembly. Next are static classes, which are classes that are declared using the static keyword. What this keyword does is limit the class to only allow static fields, methods, and properties and turns the class into a true static class that is enforced by the compiler. Finally fixed-size buffers enable a developer to create a data structure of fixed size and are useful when working with code written in other languages, preexisting DLLs, or COM projects.