Using Namespaces in VB.NET

Using Namespaces in VB.NET The most common way VB.NET namespaces are used by most programmers is to tell the compiler which .NET Framework libraries are needed for a particular program. When you choose a template for your project (such as Windows Forms Application) one of the things that youre choosing is the specific set of namespaces that will be automatically referenced in your project. This makes the code in those namespaces available to your program. For example, some of the namespaces and the actual files they are in for a Windows Forms Application are: System in System.dllSystem.Data in System.Data.dllSystem.Deployment System.Deployment.dllSystem.Drawing System.Drawing.dllSystem.Windows.Forms System.Windows.Forms.dll You can see (and change) the namespaces and references for your project in the project properties under the References tab. This way of thinking about namespaces makes them seem to be just the same thing as code library but thats only part of the idea. The real benefit of namespaces is organization. Most of us wont get the chance to establish a new namespace hierarchy because its generally only done once in the beginning for a large and complicated code library. But, here, youll learn  how to interpret the namespaces that you will be asked to use in many organizations. What Namespaces Do Namespaces make it possible to organize the tens of thousands of .NET Framework objects and all the objects that VB programmers create in projects, too, so they dont clash. For example, if you search .NET for a Color object, you find two. There is a Color object in both: System.DrawingSystem.Windows.Media If you add an Imports statement for both namespaces (a reference may also be necessary for the project properties) ... Imports System.DrawingImports System.Windows.Media ... then a statement like ... Dim a As Color ... will be flagged as an error with the note, Color is ambiguous and .NET will point out that both namespaces contain an object with that name. This kind of error is called a name collision. This is the real reason for namespaces and its also the way namespaces are used in other technologies (such as XML). Namespaces make it possible to use the same object name, such as Color, when the name fits and still keep things organized. You could define a Color object in your own code and keep it distinct from the ones in .NET (or the code of other programmers). Namespace MyColorPublic Class ColorSub Color() Do somethingEnd SubEnd ClassEnd Namespace You can also use the Color object somewhere else in your program like this: Dim c As New MyColor.Colorc.Color() Before getting into some of the other features, be aware that every project is contained in a namespace. VB.NET uses the name of your project (WindowsApplication1 for a standard forms application if you dont change it) as the default namespace. To see this, create a new project (we used the name NSProj and check out the Object Browser tool): Click Here to display the illustrationClick the Back button on your browser to return The Object Browser shows your new project namespace (and the automatically defined objects in it) right along with the .NET Framework namespaces. This ability of VB.NET to make your objects equal to .NET objects is one of the keys to the power and flexibility. For example, this is why Intellisense will show your own objects as soon as you define them. To kick it up a notch, lets define a new project (We named ours NewNSProj in the same solution (use File Add New Project ...) and code a new namespace in that project. And just to make it more fun, lets put the new namespace in a new module (we named it NewNSMod). And since an object must be coded as a class, we also added a class block (named NewNSObj). Heres the code and Solution Explorer to show how it fits together: Click Here to display the illustrationClick the Back button on your browser to return Since your own code is just like Framework code, its necessary to add a reference to NewNSMod in NSProj to use the object in the namespace, even though theyre in the same solution. Once thats done, you can declare an object in NSProj based on the method in NewNSMod. You also need to build the project so an actual object exists to reference. Dim o As New NewNSProj.AVBNS.NewNSMod.NewNSObjo.AVBNSMethod() Thats quite a Dim statement though. We can shorten that by using an Imports statement with an alias. Imports NS NewNSProj.AVBNS.NewNSMod.NewNSObj...Dim o As New NSo.AVBNSMethod() Clicking the Run button displays the MsgBox from the AVBNS namespace, Hey! It worked! When and Why to Use Namespaces Everything so far has really just been syntax - the coding rules that you have to follow in using namespaces. But to really take advantage, you need two things: A requirement for namespace organization in the first place. You need more than just a Hello World project before the organization of namespaces starts to pay off.A plan to use them. In general, Microsoft recommends that you organize your organizations code using a combination of your company name with the product name. So, for example, if youre the Chief Software Architect for Dr. Nos Nose Knows Plastic Surgery, then you might want to organize your namespaces like ... DRNoConsultingReadTheirWatchNChargeEmTellEmNuthinSurgeryElephantManMyEyeLidsRGone This is similar to .NETs organization ... ObjectSystemCoreIOLinqDataOdbcSql The multilevel namespaces are achieved by simply nesting the namespace blocks. Namespace DRNoNamespace SurgeryNamespace MyEyeLidsRGone VB CodeEnd NamespaceEnd NamespaceEnd Namespace or Namespace DRNo.Surgery.MyEyeLidsRGone VB CodeEnd Namespace