Do you guys use modules?

[liptonIcedTea]

Is this like a new thing or have I actually been coding for this long and not have come across it???

Maybe cause I've come over from a C# background - and therefore just only ever used the Shared keyword.

I'm just wondering, is there any benefit in using this over just making shared functions?

what is your opinion?

 

[JuggaloBrotha]

Modules have exists in vb since the beginning and in .Net they're not really modules because the compiler turns them into global shared classes behind the scenes which is exactly what you're already doing in c#.

There are some who are against using modules, but I don't see a reason why they should be avoided, I don't use them all the time and only ever have 1 module per project, but when I do use one it makes things much easier, especially when I need 1 or 2 random global variables.

 

[JohnH]

Console applications define a main module as default, this because the shared Sub Main is called directly for this project type (as entry point for the process module), and probably a bit of nostalgia... Except for that I haven't found any need for a Module in VB.Net, I do occationally write shared utility methods, and only very rarely store common objects as shared. One exception I can think of is custom Extension methods, they must be defined in a Module.

Module Statement help topic lists the technical differences at design time.

 

[jmcilhinney]

As JB alluded to, a module is compiled the same way as a static class in C#. A static class is one that you cannot instantiate and EVERY member must be static. There are two main differences in the usage of VB modules and C# static classes:

1. In C# you must explicitly declare a class static and you must declare each member static, while in VB you don't declare a module Shared and all its members are implicitly Shared. As a side note, you cannot declare a class Shared in VB.

2. In C#, static classes follow the same naming rules as any other type. In VB, module members can be accessed without qualification, for compatibility with the same convention in VB6. For instance, if your project's root namespace is MyApp and it contains a module named MyModule and that contains a method named MyMethod, you can refer to MyMethod is any of the following ways:

MyMethod()
MyModule.MyMethod()
MyApp.MyMethod()
MyApp.MyModule.MyMethod()

The most common use for VB modules and C# static classes these days is for declaring extension methods, which cannot be declared anywhere else.

Another example is My.Resources. When you add a resource named MyResource to your project on the Resources tab of the project properties, you would usually access it in code using My.Resources.MyResource. In this case My.Resources is actually a namespace though. In it is declared a module named Resources that exposes a property for each resource. What you're actually accessing is My.Resources.Resources.MyResource but, in accordance with point 2 above, you are allowed to omit the module name any pretty much everyone does, although most don't even realise it.

EDIT: Just noticed JohnH mentioned extension methods already but at least My.Resources was news.