Skip navigation

Developer .NET UPDATE, September 24, 2002

Developer .NET UPDATE—brought to you by the Windows & .NET Magazine Network


Microsoft ASP.NET Connections

Windows & .NET Magazine LIVE!


More Sessions, Top Quality, Unbeatable Value

DevConnections Conferences provide more sessions at a lower cost than other events focused on Microsoft technologies.

Register today for either Microsoft ASP.NET Connections, VS.NET Connections, or SQL Server Magazine LIVE! and you'll get access to over 160 sessions and save $2,990—but only if you act right now as the Early Bird Discount expires October 4.

This deal gets even better: Stay for the week and save $4,985 when you also register for either XML Web Services Connections or Windows & .NET Magazine LIVE!. Register for the entire week and you'll get access to five conferences and 240 sessions! Click now before this offer expires:

September 24, 2002—In this issue:


  • Namespaces in Visual Studio .NET


  • Planning on Getting Certified? Make Sure to Pick Up Our New eBook!
  • Real-World Tips and Solutions Here for You


  • Featured Thread: The .NET Framework and SQL Server


  • Analyze Your .NET Code


  • See this section for a list of ways to contact us.

(contributed by Bill Sheldon, [email protected])


  • Namespaces in Visual Studio .NET are a powerful replacement to the programmatic identifiers (ProgIDs) that are common in COM. ProgIDs consist of two parts: a project name followed by a class name. In a Microsoft .NET namespace, the project name still proceeds the class name, but the namespace can contain a multilevel hierarchy. As a result, you can create truly custom identifiers for your class libraries.

    The differences between ProgIDs and .NET namespaces go beyond the naming hierarchy. Unlike a ProgID, a .NET namespace doesn't define the assembly or executable that contains these classes. Instead, a .NET namespace defines a group of related classes, which lets you split a namespace across several different project assemblies or combine several namespaces within one assembly. This type of flexibility helps you create enterprise-quality class libraries.

    Let's take a look at the creation of namespaces. Both Visual Basic .NET and Visual C# .NET define a default Namespace property as part of a project's properties. The Namespace property is accessible by right-clicking the project name and selecting Properties.

    When you create a Visual C# .NET project, Visual Studio .NET uses the name of the project as the default namespace. At the top of the class, Visual Studio .NET automatically uses the "namespace" keyword to declare the default namespace in code such as

    namespace CSharpLibrarySample
       public class Person

    This namespace structure wraps your Visual C# .NET class definition and applies the project's default namespace to your class. When you reference your assembly from another project, you reference the class as CSharpLibrarySample.Person. You can also use the "namespace" keyword to create a custom namespace.

    Like Visual C# .NET, Visual Basic .NET creates a namespace. However, when you create a Visual Basic .NET class, Visual Studio .NET doesn't explicitly declare the namespace in the class source file. Thus, you need to reference the class by the project's default namespace, which, as I mentioned, appears in the Properties page. As an alternative, you can use the Namespace statement to declare a custom namespace for a class in the class source file, with code such as

    Namespace VBLibrarySample
       Public Class Person
    End Namespace

    When you declare a custom namespace in a Visual Basic .NET source file, Visual Studio .NET always adds the custom namespace to this default namespace. So, for example, if you use the declaration just given for a Visual Basic .NET project called VBLibrarySample, the result is that you must fully reference the class as VBLibrarySample.VBLibrarySample.Person. This reference might not be what you'd expect. You can, however, modify or even remove the default namespace in a Visual Basic .NET project property definition (more on this topic shortly).

    No matter which .NET language you use, the customization of a namespace can become quite detailed. You can combine and even nest values. Take, for example, the following Visual C# .NET code:

    namespace WinMag.CSharpLibrarySample
       public class Person
       namespace HREntities
         public class Employee : Person

    The result of this namespace structure is two classes that are available by referencing either WinMag.CSharpLibrarySample.Person or WinMag.CSharpLibrarySample.HREntities.Employee. This example illustrates how you can inherit across namespace boundaries and even use a single namespace declaration to define a multipart namespace. The key is that when you reference this assembly, these full paths become available.

    In Visual C# .NET, the default Namespace property is a design-time property. In other words, when you create a class, the default Namespace property's value populates the namespace declaration within the source file for that class. However, the value doesn't play a role in the final definition of a class namespace created at compilation. Let me stress that Visual Basic .NET's default behavior differs from that of Visual C# .NET. In Visual Basic .NET, the defined default namespace applies, by default, to all class files at compilation.

    No matter whether you use Visual C# .NET or Visual Basic .NET, you can remove the default namespace associated with a compiled class. When you remove a default namespace, you don't have to replace it. However, Visual C# .NET lets you change the default namespace on a class by class basis, but in Visual Basic .NET, changing the default namespace associated with a class requires a change to the project and affects every class in the project. The difference in behavior makes it seem like the Visual C# .NET development team had a better understanding of the power of .NET namespaces than did the Visual Basic .NET development team.

    When you reference a class library assembly from your project, you gain access to all the classes defined in that assembly. By default, this access is based on the classes' namespace. What happens, then, if you remove the default namespace for a class but don't specify a replacement namespace? When you remove the namespace from a class, the class appears in the top-level default list of classes that you see whenever you reference a variable type. Having all of your library's classes at the top level increases the likelihood that your class will conflict with another similarly named class, which is why you should avoid the practice of defining classes that aren't grouped under a namespace.

    If you are concerned about typing a long namespace every time you want to reference a class, the Imports statement is the solution. With the imports statement, you can create a shortcut to classes within a given namespace. For example, you can obtain direct access to the VBSampleLibrary.Person class by including the following statement in your Visual Basic .NET code:

    Imports VBSampleLibrary

    The format is the same in Visual C# .NET, although you use the "using" keyword rather than the Imports statement. Both the "using" keyword and the Imports statement prioritize the classes associated with the specified namespace. Instead of these elements requiring a full reference, you'll find that you can reference them by their class name only. You can also import elements that make up a namespace across various levels. Thus, if you want to reference the objects defined above without prefacing them with their full namespace, you can use code such as

    using WinMag.CSharpLibrarySample;
    using WinMag.CSharpLibrarySample.HREntities;

    When you're importing a namespace keep the following in mind: If you have a naming conflict between a referenced class and an imported class, the imported class wins. However, you can avoid naming conflicts by using "aliasing." Aliasing lets you assign an alternative name to long namespaces or namespaces with similar names. For example, you can rename the System.IO namespace as FSO by using the following import statement in Visual Basic .NET:

    Imports FSO = System.IO

    In Visual #C .NET, this code looks like

    using FSO = System.IO;

    With this statement in place, you can reference the classes the System.IO namespace by specifying FSO in the current source code. You haven't changed anything in the class library or in any other code in my project.

    The .NET Framework lets you create powerful custom class libraries with self-describing names. Being able to then shorten these descriptive names with short, locally meaningful aliases lets you avoid naming conflicts and be more productive. For good examples of how to work with namespaces, check out these Web pages:


    Real-World Tips and Solutions Here for You
    Register now for Windows & .NET Magazine LIVE! and attend concurrently run XML Web Services Connections sessions for FREE. You'll save $1,595, but only if you register now before this offer expires October 4. This conference is chock full of "been there, done that" information from people who use these technologies in the real world. Immediately increase your productivity with shortcuts, tips, and tricks you'll learn. Solve those tough interoperability issues, enhance systems administration with new tools, learn how .NET will impact your job, and find out how to make Web services payoff for you and your career. Benefit from our mix of speakers representing magazine authors, Microsoft architects, and third-party gurus. This must-attend event is loaded with practical information you can use right away to help keep your skills sharp.

    Find out how to save almost $5,000 by extending your stay to include Microsoft ASP.NET Connections, VS.NET Connections, and SQL Server Magazine LIVE!. Hurry before this offer expires, go to:

    (brought to you by Windows & .NET Magazine and its partners)


  • "The Insider's Guide to IT Certification" eBook is hot off the presses and contains everything you need to know to help you save time and money while preparing for certification exams from Microsoft, Cisco Systems, and CompTIA and have a successful career in IT. Get your copy of the Insider's Guide today!


  • Register online for Windows & .NET Magazine LIVE!. Network with the finest gathering of Windows gurus on the planet. This event is chock full of "been there, done that" knowledge from people who use Microsoft products in the real world. Early-bird discount expires soon. Register now and you'll also receive access to sessions of concurrently run XML and Web Services Connections.



  • A forum member wants to know whether the Microsoft .NET Framework works on machines running Microsoft SQL Server 2000 or SQL Server 7.0. If you know, go to

    (contributed by Sue Cooper, [email protected])


  • FMS announced the preview of Total .NET Analyzer, software that performs detailed code analysis on Visual C# .NET and Visual Basic .NET code. Designed exclusively for and completely integrated into Visual Studio .NET, Total .NET Analyzer performs realtime impact analysis to identify bugs, performance problems, or standards violations in your applications. Problems detected include unused code, use of legacy Visual Basic (VB) code that should be converted to Visual Basic .NET, incomplete error handling, and form property difficulties. Anticipated to be available in early October, Total .NET Analyzer is licensed per developer starting at $499 per license, with volume discounts available. Contact FMS at 866-367-7801, 703-356-4700, or [email protected]

    Here's how to reach us with your comments and questions:

    (please mention the newsletter name in the subject line)

    This weekly email newsletter is brought to you by Windows & .NET Magazine, the leading publication for Windows professionals who want to learn more and perform better. Subscribe today.

    Receive the latest information about the Windows and .NET topics of your choice. Subscribe to our other FREE email newsletters.

    Thank you for reading Developer .NET UPDATE.

    Hide comments


    • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

    Plain text

    • No HTML tags allowed.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Lines and paragraphs break automatically.