The clearest signal that things have changed is that the file extensions in Visual Basic .NET have been changed.
Visual Basic Group Files Are Solutions
File extensions changed in Visual Basic .NET to accommodate the way in which files are managed in the unified Visual Studio IDE. The concept of a whole system is referred to as a solution. In Visual Basic 6 when you add a second, third, or more projects, a Visual Basic Group, or .VBG, file is created.
The same convenience of working with multiple projects exists in Visual Basic .NET. The VBG equivalent is the solution, or .SLN, file.
Source Files Have a New Extension
A second big change is that no distinction is made between files containing classes, forms, or just code. All Visual Basic source code is written in files having a .VB extension, including user controls, components , forms, classes, modules, assemblies, and source for Web Forms.
Several additional new file extensions, however, are related to other kinds of files. For example, model files have an .MDX extension.
Visual Basic .NET supports the class idiom and the module idiom. Think of a module as a special class where all members of the module are sharedsometimes called static or class members in other languages.
Shared members exist at the metaclass level, that is, you don't need an instance of an object to access shared methods . The Module idiom is supported to make Visual Basic .NET seem a little less foreign.
The new .VB file extension is indicative of the source file being a container for code in general. New syntactical idioms were defined to make the distinction between kinds of entities, such as classes and modules, allowing for multiple entities being defined in a single file (see Listing 2.1).
Listing 2.1 Multiple modules defined in a single file
Module Module1 Sub Test() MsgBox("Module1") End Sub End Module Module Module2 Sub Test() MsgBox("Module2") End Sub End Module
The code in Listing 2.1 is defined in a single file named Module1.vb. You might expect that only Module1 would exist in the Module1.vb file. There is no enforced correlation between the filename and the module name in VB .NET. A new convention you can adopt is to name the module file the same as the dominantthe most importantmodule in the file; this will help you find your code handily.
As you can see from Listing 2.1, two methods have identical names : Test. The Module statement defines a separate entity. We could say that Module1 and Module2 encapsulate a method Test. If you are unfamiliar with the idea of encapsulation, see Chapter 7, "Creating Classes," for greater detail on this subject.
Back to our understanding of modules: Modules are classes with all shared members. The Shared idiom is covered in Chapter 11, "Shared Members," but for now you can just remember that prefixing the Module name and a period to the member will indicate which module and member you're referring to.
If you wrote the following line
a message box with the text "Module1" would be displayed, and the next line
would display the text "Module2." Because Test is defined in two modules, calling Test without the module name would result in an ambiguous declaration error at compile time. Generally you don't have to specify a module when accessing members of the module. You can simply think of module code as global code, but if you get an ambiguous declaration error, the cause is probably related to code similar to that in Listing 2.1.
A vanilla Windows application containing forms would also include an options file with a .suo extension and a .vbproj file for each project in the solution. Run the application and you might find resource files for your forms with a .resx extension. There are several other file types, but we can defer the discussion of those file types until we talk about those aspects of Visual Studio.