Namespaces

Team-Fly

---

 

	Visual Basic .NET Unleashed By Paul Kimmel
	Table of Contents
	Chapter 2.  Out with the Old, In with the New

---

Namespaces

Another noticeable change is the use of namespaces. Chapter 6, "Reflections," provides thorough coverage of namespaces. For now, you can think of a namespace as a means of organizing classes.

As software becomes increasingly complex, we will need higher levels of abstraction to organize code. Types were defined to collect data. Procedures were defined to organize and manage lines of code. Classes were invented to organize procedures and data, and now we have namespaces to organize classes.

When you create a VB .NET project, a default namespace with the same name as your project is defined for you. In our vanilla Windows module example in Listing 2.1, I chose the default name. The project ended up with this name as the namespace; the default name is WindowsApplication1. The namespace for a project can be viewed on the General view of the project's Property Pages.

For practical purposes you can complete one of two tasks when trying to use classes, procedures, or objects defined in a namespace. Type the fully qualified namespace path of the entity or add an Imports statement to the Imports list, also in the Property Pages.

Note

When you look up information in the help file, part of the information provided is the namespace containing the entity you're inquiring about. For example, if you look up the Debug.Writeline method, you will get information about the System.Diagnostics namespace. To use the code in diagnostics, add an Imports statement at the top of the module or in the Property Pages.

Here is an example of an Imports statement for system.diagnostics:

 Imports System.Diagnostics 

In Chapter 1, you learned that several of the basic namespaces are added based on project type. For example, our Windows application imports the System.Windows.Forms. System.Windows.Forms is what is commonly referred to as WinForms.

---

Team-Fly

Top