Alright, so I’ve spent a lot of my time this summer (and more this fall) going to

various groups and talking about the features in C# 3.0. This is something of

a thorn in the side of my good friend Cory Smith,

who despite the fact that he is a “Visual Developer” MVP, is the staunchest Visual

Basic advocate that I’m aware of. I swear this man dreams VB, I know he blogs

VB over at As such, I thought

it was time to give all of my friends who prefer Visual Basic their fair time, or

at least some time, so this post details the new features and shows the syntax for

things. There is not exact parity to the C# feature list, but its a close thing,

so here we go.

Automatic Properties

We’ll start of with the biggest exclusion. VB does not get automatic properties,

so they are left with the more verbose version of the syntax.

Partial Methods

Partial Methods are very useful for light weight event handling in generated code.

For instance, lets assume that you had a generated class that looked like this:

Partial Class NewFeatures
    Partial PrivateSub BeforeTextChange(ByVal oldText AsString, ByVal newText AsString)




    Partial PrivateSub AfterTextChange(ByVal oldText AsString, ByVal newText AsString)




              Private _text AsString


              Property Text() AsString



              Return _text




              Set(ByVal value AsString)
            BeforeTextChange(_text, value)
            _text = value
            AfterTextChange(_text, value)











partial methods BeforeTextChange and AfterTextChange are convenient extension points

should the person using your generated code needs to hook into them, but the magic

is that any of these methods which are not given implementations (both in our case

above) get compiled away.On the right you can see the Reflector disassembly

for Text property. Note that there are no calls to the partial methods, because

the compiler did not emit IL for them since there were no implementations.

Now let’s add the following short code-snippet into our project:

Partial Class NewFeatures


              Sub BeforeTextChange(ByVal oldText AsString, ByVal newText AsString)
        newText += oldText




              End Class


this added, we can go examine the Reflector disassembly again, and this time we see

something very different. Now we see the call to BeforeTextChange but still

no AfterTextChange because it still has no implementation.

Now, some important notes about this feature. Partial Methods must be Subs and

they must be Private. This is to avoid them being compiled away either changing

your interface (private) or breaking other code which depends on its results (hence

no functions).

Implicitly Typed Variables

Implicitly typed variables are not variants, this is very important so I’ll repeat

myself, Implicitly typed variables are not variants. These are strongly typed

variables which you simply forgo the need to type (as in press keys) the type (as

in the class name).

The restrictions? You must initialize the object on the same line it is declared,

so that the compiler can infer the type. Here is an example:

              Dim myString

= "This is a string, I swear"

Now myString is a System.String, not a System.Object or anything else.

Object Initializers

This is a minor tweak to something which VB has always been better at than C#.

It makes a more compact version of the With syntax, at the cost of adding curly braces

into VB, so you can judge if it’s worth it for yourself.

              Sub Main()

              Dim ds

= New SqlClient.SqlConnection() _

              With {.ConnectionString

= "Blah"}




For C# this feature is a god send, but C# didn’t always have With, so it’s your call

if this is truly a great feature.

Anonymous Types

Now, the addition of With as part of an object initializer is a little ho-hum, but

this is not. Enter Anonymous Types, a strongly typed object where the type is

not explicitly declared, but rather implicitly declared.

              Sub Main()

              Dim ds

= NewWith {.FirstName

= "Tim", _
                       .LastName = "Rayburn"}





have I blown your mind yet? No? Well, then try this in for size… On the right is

the Intellisense you receive when you type “ds.” with this variable in scope.

The compiler has converted out simple syntax above into a full type with two properties

: FirstName and LastName. Pretty darned sexy if you ask me.

Restrictions? Of course there are restrictions. These can only be used

as private or local variables. If any other type will ever see this object them

you have to convert this to a full class. The VB compiler will let you make

these public, but it emits the type as System.Object and you loose intellisense.

Embedded Xml

This is a feature that C# 3.0 does not have, it is solely the province of Visual Basic

and I must admit, it kind of rocks. But it will also break your head the first

time you read it:

              Sub CreateCityXml(ByVal name AsString, ByVal lat AsDouble, ByVal lon AsDouble)

              Dim cityXml As XElement

= _
        <Name><%= name %></Name>
        <Latitude><%= lat %></Latitude>
        <Longitude><%= lon %></Longitude>

    cityXml.<City>.<Longitude>.Value = "XXX"




This feature has to do with LINQ to XML, the basic object of which is the XElement

class we are declaring above. You can with this embed XML directly in your VB

code. Notice there are no line continuation characters after the root node opens,

this is because it is assumed that the declare will end when the root node is closed.

Also note the use of the <% and %> like ASP and ASP.NET use to embed code into

the XML. This simple example is simply outputting variables, but there is no

reason why this couldn’t just as easily have contained a For loop or some other more

complex code.

The final line before the end of the sub shows how you can also use the XML node syntax

as if they were an object model. Now this does not include Intellisense support

for the .<tag> names, but it is still pretty slick.

Lambda Expressions

I know that Visual Basic has a tradition of being a less terse, more verbose language,

but I personally feel that VB got the short end of the stick on Lambda Expression

syntax. A Lambda expression is supposed to be a terse syntax for anonymous delegates

which also happens to be able to be explored via code if you’re using Expression Trees

(which we will not discuss here). For instance, let’s assume that you wanted

to select items from an List(of Integer) where the value was greater than 50.

You could write code like this:

              Function GreaterThan50(ByVal inputList As List(Of Integer)) As List(Of Integer)

              Return inputList.Where(Function(i)

i > 50)




This is much more verbose than the C# syntax for that Lambda Expression “i => i

> 50” but I will grant you it is more readable so hopefully people who prefer VB

will prefer the VB syntax.

Extension Methods

The best feature of the .NET Framework 3.5, hands down, is extension methods.

If anyone has sold you on LINQ as the best feature, laugh at them and remind them

that LINQ is entirely based on extension methods.

What are they? Simple : The ability to add a new method to an existing type which

is only visible to those who implement your extension library.

Restrictions? Some. The biggest is that you do not get access to anything you

wouldn’t have had access to already. So creating an extension method is not

going to allow you to get access to private or internal types for a class.

Benefits? Huge! As cool as being able to add new methods to classes is,

you’ll please note I said you could extend types! This means

you can create an Interface and then provide implementation for that

interface via extension methods. In fact, that’s how LINQ is done in great part.

The .NET Framework now contains extension methods such as “Where” and “First” and

“GroupBy”for the IEnumerable interface. As such any IEnumerable can use

these, without changing the interface at all.

Very important note to those who try to stay fluent in both languages, the VB syntax

for extension methods is very different than the C# syntax, you’ll

want to pay very close attention to this.

Here are two examples, one extends a class, the other an interface:

<Extension()> _

              Function ToStringNullSafe(ByVal inObj AsObject) AsString

              If inObj IsNothingThen





              Return inObj.ToString()







<Extension()> _

              Sub Dispose(ByVal inObj As IDisposable)

              If inObj

IsNot NothingThen




              End Sub

The first of these extension methods is something every UI developer has wished for,

a ToString function which does not blow up just because the variable is Nothing.

The second is an ingenious (if I say so myself) and beautiful hack of the IDisposable

interface. Most, but importantly not all, objects which implement IDisposable

implement a public Dispose method. Some however do not, even though they implement

it explicitly. This method will add a public Dispose method to any object which

implements IDisposable.

What if they already have one you ask? The actual method on an object always

wins out, and if there is a danger to extension methods, that is it. Should

the person who controls that type add a method which has the same name as your extension

method, your extension method becomes uncallable. A minimal risk for the incredible

power of being able to provide implementation to interfaces.