In an article I published at DevX about some of the new features in VB9, I described how you could use extension methods, which are a new feature available in VB9, even in projects targeted at the .NET 2.0 framework. When I first read about extension methods, my mind began racing through all the features I wish various classes and products had implemented. A short list of the extension methods I implemented and used frequently are described below.
- IsSomething(Object) and IsNothing(Object): These methods make it easy to check object references.
- SafeString(String): This method always returns a string. In the event that a string was set to Nothing, it returned String.Empty. An overloaded version of the method also accepted a default value that would be returned when the string was set to Nothing.
- SafeDBString(SQLDataReader), SafeDBInteger(SQLDataReader), etc: These methods allow safe access to fields returned in a result set. In most cases, when I want to read a string from a database, especially for display, I want an empty string instead of DBNull. This method does this neatly and concisely.
I know there are various ways to implement these methods without using extension methods, but the dot syntax used when you call extension methods appeals to me. The syntax of strMyString.IsNullOrEmpty() seems more natural than String.IsNullOrEmpty(strMyString).
That said, I will offer you a warning that my article referenced above did not mention. If 1) you work in an environment where classes containing plumbing code, business classes, and the like are created, and 2) you have used extension methods created in .NET 2.0 projects, you will find yourself in a sticky situation when (if) you decide to use those classes from a .NET 3.5 project. The problem is caused by duplicate definitions for the ExtensionAttribute: one in your .NET 2.0 project and one in the .NET 3.5 framework.
When you attempt to compile a .NET 3.5 project with references to duplicate ExtensionAttribute definitions, the build output console in Visual Studio doesn't show a specific error. It merely indicates that the build failed. If you attempt to build the project manually using command line tools, the error message looks like the output below.
Microsoft (R) Visual Basic Compiler version 9.0.30729.1
Copyright (c) Microsoft Corporation. All rights reserved
InternalXmlHelper.vb(9) : error BC30560: 'ExtensionAttribute' is
ambiguous in the namespace 'System.Runtime.CompilerServices'.
<Global.System.Runtime.CompilerServices.ExtensionAttribute()> _
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you have the luxury of upgrading your entire code base to .NET 3.5 at one time, then you will be safe. Simply remove the 'hacked' ExtensionAttribute definition from your code. When the projects are recompiled, references to the ExtensionAttribute will naturally pick up the definition provided in the .NET 3.5 framework.
If you run in a mixed environment, like I do most of the time, then you will run into the problem that the ExtensionAttribute will be defined both in your .NET 2.0 project (as described in the DevX article) and in the .NET 3.5 framework. This will prevent you from compiling any .NET 3.5 projects that reference any of your .NET 2.0 classes that use extension methods. Keep in mind that this means that any project that contains the .NET 2.0 assembly where you 'hacked' a definition for ExtensionAttribute, even if it is an indirect reference (you reference an assembly that references it), cannot be referenced by a .NET 3.5 project until the 'hacked' definition is removed.
Extension methods are still useful in some smaller projects where the entire project will be upgraded to .NET 3.5 at one time. Extension method users beware: if you work in an environment where you have multiple versions of .NET assemblies in use, you are heading into a world of pain.
