We help IT Professionals succeed at work.

VB.net Class vs standard module

Murray Brown
Murray Brown asked

I have written an important piece of code that my client wants me to put in a class.
I have never done this and by my understanding, its like a standard module that just gets
used a lot. Please would someone explain how classes are used and what the benefits are.

Watch Question

.Net and Infrastructure Consultant
This page explains it


but to be fair the easiest way to understand it is that a module IS just a class whose members are automatically set to Shared.

(sorry just pseudo code here but it should be enough)

public module Mod1
public Function ComplicatedMethod() as string
''do loads of stuff
end function
end module

is pretty much the same thing as

public Shared Class Class1
public Shared Function ComplicatedMethod() as string
''do loads of stuff
end function
end class

then your customer can use

If SomeOption then
console.writeline (Class1.ComplicatedMethod())
end If
Most Valuable Expert 2012
Top Expert 2014
There is another big difference I have not seen mentioned above. All the variables, functions etc in module are directly accessible everywhere in the application whereas shared members of a class would need to be accessed with the classname first and then member name.

You would call function by


if its in module and


if its a shared method in another class.
lojk.Net and Infrastructure Consultant

CC is correct but as a heavy C# user these days I would expect to call a Helper method from a static class in a clearly defined namespace (and/or with a using/imports statement) and that leads onto a whole VB/C# discussion that i dont want to get into.

For me, even if i could just write 'Bobs House' on a letter and i knew it would get there (compile) i would still much rather write (and read/use) an address that said 'UK.England.London.PutneyGreen.BobsHouse'

Yeah the latter is longer but there can be no doubt as to which Bob I am referring.
Top Expert 2015
It is just a question of preference and how you want your code to be meaningful.

As stated by lojk, a module is a static class. VB uses the keyword Shared because Static is already defined for another use. But the real name of the thing is a static class. All the other .NET languages use the word static where VB uses Shared.

When you compile a VB module, it is compiled as a static class. Other languages would not be able to call a VB dll otherwise, because modules as they are known in VB do not exist in the framework.

A static class is a class that possesses methods that you can call without having to instantiate an object. You do not need a variable initialized with New in order to call the methods. Said otherwise, it is simply a collection of routines that you associate to a certain type of operations through the name of the class. Look at the Math class in .NET. You simply call Math.MethodName to perform any type of mathematical operation. Same for the IO.File class, that is a collection of routines to work with files in the file system.

This different from a standard class, where you need to create a variable before you can use it.

Modules are just a way for Microsoft to make VB.NET feel like classic VB, where classes as we know them in .NET did not exist, and modules were king for the majority of programmers. Programmers who were used to modules in VB6 very often continue to use modules in .NET. Programmers who are beginning also often use modules because they are easier to use, you just call the method.

But as lojk pointed out, having things in a class forces you to write code that is easier to understand, because you know where your methods are coming from, because you need to specily the name of the class to access a method. Advanced programmers, programmers who work in many languages and programmers who are strict in their coding conventions usually prefer to use static classes over modules.

But they are exactly the same thing and compile to the same thing. The only difference is the convention that you use to call their methods. Note that you can call methods in a module as you would in a static class, by giving the name fo the module dot the name of the method.

In my training, I suggest to professional programmers to learn to use static classes instead of modules. Since this is the only way to to in other languages such as C#, it's one less thing to adapt to when they need to learn a new language after VB.

As for your customer, you could argue with him that it makes no difference to have the code in a module or in a static class. They are the same thing, and he can call the methods in the module exactly the same way as if it was a static class, no matter the language he uses to access your application or your class library.

However, maybe what he wants is that you create standard classes. If you happen to somehting aking to variables and methods to work on a customer as an example, then I am quite sure that what he means in by using classes instead of modules is to create a real class for a Customer. This is called object oriented programming, and there you have a big difference between a module and a standard class.
lojk.Net and Infrastructure Consultant

JamesB makes plenty of valid points - in my experience of about 15 years commercial software development using VB4/5/6/.NET and C#.Net you should write (and rewrite as neccesary) for the platform not the language.  

In other words, just because it was done in VB6 like this, VB.Net is VB for the .Net Platform and Modules were added for compatibility to previous versions to ease the transition. But you really should try and speak the language of .Net where possible.

The funny thing is no matter how 'VB' you think you are, you can never rule out that you'll end up in 'C# Land' sometime in the future. Trust me on that one ;-)
Top Expert 2015

lojk adds a very strong point.

Although I use VB 90% of the time because I prefer that language and finds that the editor makes me more productive, I had to learn C# at some point. Not that the language is better, the language does not really matter in .NET where the framework does the work, and specially since Microsoft has decided that the 2 languages would evolve in parallel.

But you can end up having to work with source code that is already written in C#. Or similar to your situation, a customer might insist that you provide an application or a dll written in C# because his team prefers to work in C# and will be doing the maintenance.

There is something I put forward very strongly in my training sessions: learn to program in .NET, not in VB or in another language. That way, the transision from one language to another is a very simple thing.

This is not only limited to static classes vs modules. Take the habit of using MessageBox.Show instead of MsgBox. Use the methods available on a date or string variable instead of using the commands available in Visual Basic. Not only will the transition to another language be easier, but .NET methods are usually easier to use and offer more possibilities than older Visual Basic commands. They also usually make the code easier to read. And just as modules ends up being compiled as static classes, those VB commands more often than not ends up being compiled as .NET methods. They also usually makes the code easier to read.

With such an approach, using static classes makes more sense than using modules.

A little trick, to apply on new projects. Go to the list of imports in the Reference tab of the Project's properties window and deactivate Microsoft.VisualBasic in the imports at the bottom of the screen. This will force you to learn the .NET way of calling objects methods instead of VB commands. In a pinch, you can always use the VB commands, but will have to specify the namespace, such as in Microsoft.VisualBasic.MsgBox("Hi you!").
Murray BrownASP.net/VBA/VSTO Developer


Thanks very much