C# .NET Extension Methods 3.0

.NET 3.5 Extension methods are a great new way of adding functionality to an existing type – even a type you don’t have the source code to modify that type. This article explains extension methods and provides clear examples along with pros and cons.

.Net 3.5 Extension methods are a great new way of adding functionality to an existing type – even a type you don’t have the source code to such as is the case with a .Net framework library type i.e. String.   Suppose you had a string and wanted to see if that string existed in another array of strings.  You can write your own loop to search, or you could write an extension method which would do it for you.  A method with the signature of bool IsInArray(string textToFind , string[] textArray) would appear to accomplish such a goal.  We can add such a method to the string type with C# 3.0 and the .Net Framework 3.5.

It isn’t completely obvious how this works so I’ll provide some clarification.  First of all, your extensions must be defined in a separate class and the namespace must be referenced in your code.  In this case we’d include a “using ExtensionMethodSample” statement to get access to StringExtensions.  Secondly, examine the signature of the IsInArray method.  The first parameter is “this string myString” which tells the compiler the method is an extension of string.  An argument isn’t explicitly passed to the method for myString, but the parameter can be used within the method as if it were.  Parameters 2…n are all explicitly supplied with arguments as you’ll see with Intellisense.

If we were to execute this call to IsInArray(this string myString, string[] stringArray), passing in the myStrings string array, we’d receive the Boolean value of True back because “hello” was in the myStrings array.


This appears to be a very promising way to add functionality to existing types however there are some “gotchas”: 

Signature Ambiguity (or lack thereof)

If you provide an extension method with the same signature as a method already available on the type you’re extending, the extension method is ignored.  Instead, you should create your own type derived from the type you’d like to extend and override the method or add an overload.  An example of this if you create an extension method of signature “string ToString()” for type String.  String already has a “string ToString()” method which would be the method called.

I did find I can create an additional overload of an existing type as an extension method.  Let’s take this same ToString() example.  If I added an overload which doesn’t yet exist for ToString() such as “public static string ToString(this string myString, int repeatCount)” then I’d have the base ToString() methods plus my new overloaded ToString method.

Type Modification

If the type you are writing an extension method for changes, your extension method may require modification to maintain compatibility.  This sort of goes without saying and is just as likely to be the case if you’ve derived a class from that type and added methods to your new class. 


As stated, Microsoft’s recommendation is to derive a class if possible and avoid extension methods.  I personally feel extension methods have their place with primitives and potentially asp.net built-in user controls.   These are types I just don’t want to derive from and modify – I prefer the built-in ease of use.  I’ve longed for a method on a checkbox list which returns a collection of items which were checked.  Instead we must loop through the checkbox list and build our own collection.  An extension method can resolve this issue for us without creating a completely new asp.net user control.

I’m sure we’ll see extension method libraries entering the community which provide often desired functionality not yet built into the .net framework and C#.

For more information on extension methods, check out Scott Guthrie's blog article on .Net Framework 3.5 extension methods.

For other great C# 3.0 information, visit Ian Suttle's Blog.

By Ian Suttle   Popularity  (13826 Views)