More fun with ones and zeros: My previous post referred to some C# examples for creating simple extension methods. But if you're working in VB, how does that help? Well, I'll let me give you an example; then I'll do the compare-and-contrast thing with C# to highlight the differences. (If Dr. Smith, my college writing prof, were here to read this, he'd be so happy!) Here is a sample method, in VB: Module Extensions <Extension()> Public Sub WriteToConsole(str As String) Console.Write(str) End Sub End Module Here is the same method in C#: public static class Extensions { [Extension()] public static void WriteToConsole(string str) { Console.Write(str); } } The key is how the "extensionness" of the method is established. The two languages have the similarity such that a module (VB) or static class (C#) must be used as a container. There, the differences begin to emerge: you are required to use the System.Runtime.CompilerServices.ExtensionAttribute to decorate your method in VB. You may do the same thing in C#, or you may use the following shorthand on the method declaration: public static void WriteToConsole(this string str) { Console.Write(str); } The "this" keyword on the parameter list, in place of the ExtensionAttribute, also clues the compiler to your intent. Finally, the remaining difference between the two languages is that the C# method must be static, while the Shared keyword is not required in VB. Taken all together, these syntactical tweaks tell the compiler to do its magic, which is essentially to fake out Intellisense to include your extension method, and to structure the IL code to invoke your method. Pure syntactical sugar, with no calories, and no government price supports. Sweet!