Highlighting their importance to every project, references (including namespaces) are no longer hidden from view, available only after opening a dialog box as they were in VB6. As shown in the Solution Explorer window in Figure 7-4, every new project includes a set of referenced namespaces. (If you do not see the references listed in the Solution Explorer, click the Show All Files button from the Solution Explorer menu.)

The list of default references varies depending on the type of project. The example in Figure 7-4 shows the default references for a Windows Forms project in Visual Studio 2008. If the project type were an ASP.NET Web Application, the list of references would change accordingly — the reference to the System.Windows.Forms namespace assembly would be replaced by a reference to System.Web. If the project type were an ASP.NET Web service (not shown), then the System.Windows.Forms namespace would be replaced by references to the System.Web and System.Web.Services namespaces.

Figure 7.4. Figure 7-4

In addition to making the namespaces available, references play a second important role in your project. One of the advantages of .NET is using services and components built on the common language runtime (CLR), which enables you to avoid DLL conflicts. The various problems that can occur related to DLL versioning, commonly referred to as "DLL hell," involve two types of conflict.

The first situation occurs when you have a component that requires a minimum DLL version, and an older version of the same DLL causes your product to break. The alternative situation is when you require an older version of a DLL, and a new version is incompatible. In either case, the result is that a shared file, outside of your control, creates a systemwide dependency that affects your software. With .NET, it is possible, but not required, to indicate that a DLL should be shipped as part of your project to avoid an external dependency.

To indicate that a referenced component should be included locally, you can select the reference in the Solution Explorer and then examine the properties associated with that reference. One editable property is called Copy Local. You will see this property and its value in the Properties window within Visual Studio 2008. For those assemblies that are part of a Visual Studio 2008 installation, this value defaults to False, as shown in Figure 7-5 . However, for custom references, this property defaults to True to indicate that the referenced DLL should be included as part of the assembly. Changing this property to True changes the path associated with the assembly. Instead of using the path to the referenced file's location on the system, the project creates a subdirectory based on the reference name and places the files required for the implementation of the reference in this subdirectory.

The benefit of this is that even when another version of the DLL is later placed on the system, your project's assembly will continue to function. However, this protection from a conflicting version comes at a price: Future updates to the namespace assembly to fix flaws will be in the system version but not in the private version that is part of your project's assembly.

To resolve this, Microsoft's solution is to place new versions in directories based on their version information. If you examine the path information for all of the Visual Studio 2008 references, you will see that it includes a version number. As new versions of these DLLs are released, they are installed in a separate directory. This method allows for an escape from DLL hell, by keeping new versions from stomping on old versions, and it enables old versions to be easily located for maintenance updates. Therefore, it is often better to leave alone the default behavior of Visual Studio 2008, which is set to copy only locally custom components, until your organization implements a directory structure with version information similar to that of Microsoft.

Figure 7.5. Figure 7-5

The Visual Basic 2008 compiler will not allow you to add a reference to your assembly if the targeted implementation includes a reference that is not also referenced in your assembly. The good news is that the compiler will help. If, after adding a reference, that reference does not appear in the IntelliSense list generated by Visual Studio 2008, then go ahead and type the reference to a class from that reference. The compiler will flag it with underlining, similar to the Microsoft Word spelling or grammar error underlines. When you click the underlined text, the compiler will tell you which other assemblies need to be referenced in the project in order to use the class in question.

The generated list of references shown in the Solution Explorer for the newly created Namespace_Sampler project includes most, but not all, of the namespaces that are part of your Windows Application project. For example, one namespace not displayed as a reference is Microsoft.VisualBasic, and the accompanying Microsoft.VisualBasic.dll. Every Visual Basic 2008 project includes the namespace Microsoft.VisualBasic. This namespace is part of the Visual Studio project templates for Visual Basic 2008 and is, in short, what makes Visual Basic 2008 different from C# or any other .NET language. The implicit inclusion of this namespace is the reason why you can call IsDBNull and other methods of Visual Basic 2008 directly. The only difference in the default namespaces included with Visual Basic 2008 and C# Windows Application projects is that the former use Microsoft.VisualBasic and the latter use Microsoft.CSharp.

To see all of the namespaces that are imported automatically, such as the Microsoft.VisualBasic namespace, right-click the project name in the Solution Explorer and select Properties from the context menu. This opens the project's Properties window in Visual Studio. Select the References tab from the left pane and you will see the reference Microsoft.VisualBasic at the top of the list (see Figure 7-6).

Figure 7.6. Figure 7-6

When looking at the project's global list of imports in the text area at the bottom of the page, you can see that in addition to the Microsoft.VisualBasic namespace, the System.Collections and System.Diagnostics namespaces are also imported into the project. This is signified by the check marks next to the namespace. Unlike the other namespaces in the list, these namespaces are not listed as references in the text area directly above this. That's because implementation of the System.Collections and System.Diagnostics namespaces is part of the referenced System.dll. Similarly to Microsoft.VisualBasic, importing these namespaces allows references to the associated classes, such that a fully qualified path is not required. Because these namespaces contain commonly used classes, it is worthwhile to always include them at the project level.

The following list briefly summarizes some of the namespaces commonly used in Visual Basic 2008 projects:

Of course, to really make use of the classes and other objects in this list, you need more detailed information. In addition to resources such as Visual Studio 2008's help files, the best source of information is the Object Browser, available directly in the Visual Studio 2008 IDE. You can find it by selecting View

The Object Browser displays each of the referenced assemblies and enables you to drill down into the various namespaces. Figure 7-7 illustrates how the System.dll implements a number of namespaces, including some that are part of the System namespace. By drilling down into a namespace, you can see some of the classes available. By further selecting a class, the browser shows not only the methods and properties associated with the selected class, but also a brief outline of what that class does.

Using the Object Browser is an excellent way to gain insight into which classes and interfaces are available via the different assemblies included in your project, and how they work. Clearly, the ability to actually see which classes are available and know how to use them is fundamental to being able to work efficiently. Working effectively in the .NET CLR environment requires finding the right class for the task.

Figure 7.7. Figure 7-7

The development environment and compiler need a way to prioritize the order in which namespaces should be checked when a class is referenced. It is always possible to unequivocally specify a class by stating its complete namespace path. This is referred to as fully qualifying your declaration. The following example fully qualifies a StringBuilder object:

Dim sb As New System.Text.StringBuilder

However, if every reference to every class needed its full namespace declaration, then Visual Basic 2008 and every other .NET language would be very difficult to program in. After all, who wants to type System.Collections.ArrayList each time an instance of the ArrayList class is wanted? If you review the global references, you will see the System.Collections namespace. Thus, you can just type ArrayList whenever you need an instance of this class, as the reference to the larger System.Collections namespace has already been made by the application.

In theory, another way to reference the StringBuilder class is to use Text.StringBuilder, but with all namespaces imported globally, there is a problem with this, caused by what is known as namespace crowding. Because there is a second namespace, System.Drawing, that has a child called Text, the compiler does not have a clear location for the Text namespace and, therefore, cannot resolve the StringBuilder class. The solution to this problem is to ensure that only a single version of the Text child namespace is found locally. That way, the compiler will use this namespace regardless of the global availability of the System.Drawing.Text namespace.

Imports statements specify to the compiler those namespaces that the code will use:

Imports Microsoft.Win32
Imports System
Imports SysDraw = System.Drawing

Once they are imported into the file, you are not required to fully qualify your object declarations in your code. For instance, if you imported the System.Data.SqlClient namespace into your file, then you would be able to create a SqlConnection object in the following manner:

Dim conn As New SqlConnection

Each of the preceding Imports statements illustrates a different facet of importing namespaces. The first namespace, Imports Microsoft.Win32, is not imported at the global level. Looking at the reference list, you may not see the Microsoft assembly referenced directly. However, opening the Object Browser reveals that this namespace is actually included as part of the System.dll.

As noted earlier, the StringBuilder references become ambiguous because both System.Text and System.Drawing.Text are valid namespaces at the global level. As a result, the compiler has no way to determine which Text child namespace is being referenced. Without any clear indication, the compiler flags Text.StringBuilder declarations in the command handler. However, using the Imports System declaration in the module tells the compiler that before checking namespaces imported at the global level, it should attempt to match incomplete references at the module level. Because the System namespace is declared at this level, if System.Drawing is not, then there is no ambiguity regarding which child namespace Text.StringBuilder belongs to.

This sequence demonstrates how the compiler looks at each possible declaration:

While the preceding logical progression of moving from a full declaration through module- to global-level imports resolves the majority of issues, it does not handle all possibilities. Specifically, if you import System.Drawing at the module level, the namespace collision would return. This is where the third import statement becomes important — this import statement uses an alias.

Aliasing has two benefits in .NET. First, aliasing enables a long namespace such as System.EnterpriseServices to be replaced with a shorthand name such as COMPlus. Second, it adds a way to prevent ambiguity among child namespaces at the module level.

As noted earlier, the System and System.Drawing namespaces both contain a child namespace of Text. Because you will be using a number of classes from the System.Drawing namespace, it follows that this namespace should be imported into the form's module. However, were this namespace imported along with the System namespace, the compiler would again find references to the Text child namespace ambiguous. By aliasing the System.Drawing namespace to SysDraw, the compiler knows that it should only check the System.Drawing namespace when a declaration begins with that alias. The result is that although multiple namespaces with the same child namespace are now available at the module level, the compiler knows that one (or more) of them should only be checked at this level when they are explicitly referenced.

Aliasing as defined here is done in the following fashion:

Imports SysDraw = System.Drawing

Making a reference to a namespace in ASP.NET is quite similar to working with Windows Forms, but you have to take some simple, additional steps. From your ASP.NET solution, first make a reference to the assemblies from the References folder, just as you do with Windows Forms. Once there, import these namespaces at the top of the page file in order to avoid having to fully qualify the reference every time on that particular page.

For example, instead of using System.Collections.Generic for each instance of use, use the < %# Import % > page directive at the top of the ASP.NET page (if the page is constructed using the inline coding style) or use the Imports keyword at the top of the ASP.NET page's code-behind file (just as you would with Windows Forms applications). The following example shows how to perform this task when using inline coding for ASP.NET pages:

<%# Import Namespace="System.Collections.Generic" %>

Now that this reference is in place on the page, you can access everything this namespace contains without having to fully qualify the object you are accessing. Note that the Import keyword in the inline example is not missing an "s" at the end. When importing in this manner, it is Import (without the "s") instead of Imports — as it is in the ASP.NET code-behind model and Windows Forms.

In ASP.NET 1.0/1.1, if you used a particular namespace on each page of your application, you need the Import statement on each and every page where that namespace was needed. ASP.NET 3.5 includes the capability to use the web.config file to make a global reference so that you don't need to make further references on the pages themselves, as shown in the following example:

<pages>
   <namespaces>
      <add namespace="System.Drawing" />
      <add namespace="Wrox.Books" />
   </namespaces>
</pages>

In this example, using the <namespaces> element in the web.config file, references are made to the System.Drawing namespace and the Wrox.Books namespace. Because these references are now contained within the web.config file, there is no need to again reference them on any of the ASP.NET pages contained within this solution.

The My.Application namespace gives you quick access to specific settings and points that deal with your overall application. The following table details the properties and methods of the My.Application namespace:

While much can be accomplished using the My.Application namespace, for an example of its use, let's focus on the Info property. This property provides access to the information stored in the application's AssemblyInfo.vb file, as well as other details about the class file. In one of your applications, you can create a message box that is displayed using the following code:

MessageBox.Show("Company Name: " & My.Application.Info.CompanyName & _
   vbCrLf & _
   "Description: " & My.Application.Info.Description & vbCrLf & _
   "Directory Path: " & My.Application.Info.DirectoryPath & vbCrLf & _
   "Copyright: " & My.Application.Info.Copyright & vbCrLf & _
   "Trademark: " & My.Application.Info.Trademark & vbCrLf & _
   "Name: " & My.Application.Info.AssemblyName & vbCrLf & _
   "Product Name: " & My.Application.Info.ProductName & vbCrLf & _
   "Title: " & My.Application.Info.Title & vbCrLf & _
   "Version: " & My.Application.Info.Version.ToString())

From this example, it is clear that you can get at quite a bit of information concerning the assembly of the running application. Running this code produces a message box similar to the one shown in Figure 7-10.

Figure 7.10. Figure 7-10

Another interesting property to look at from the My.Application namespace is the Log property. This property enables you to work with the log files for your application. For instance, you can easily write to the system's Application Event Log by first changing the application's app.config file to include the following:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.diagnostics>
        <sources>
            <source name="DefaultSource" switchName="DefaultSwitch">

<listeners>
                    <add name="EventLog"/>
                </listeners>
            </source>
        </sources>
        <switches>
            <add name="DefaultSwitch" value="Information" />
        </switches>
        <sharedListeners>
            <add name="EventLog"
             type="System.Diagnostics.EventLogTraceListener"
             initializeData="EvjenEventWriter" />
        </sharedListeners>
    </system.diagnostics>
</configuration>

Once the configuration file is in place, you can record entries to the Application Event Log, as shown in the following simple example:

Private Sub Form1_Load(ByVal sender As System.Object, _
   ByVal e As System.EventArgs) Handles MyBase.Load

    My.Application.Log.WriteEntry("Entered Form1_Load", _
       TraceEventType.Information, 1)

End Sub

You could also just as easily use the WriteExceptionEntry method in addition to the WriteEntry method. After running this application and looking in the Event Viewer, you will see the event shown in Figure 7-11.

Figure 7.11. Figure 7-11

The previous example shows how to write to the Application Event Log when working with the objects that write to the event logs. In addition to the Application Event Log, there is also a Security Event Log and a System Event Log. Note that when using these objects, it is impossible to write to the Security Event Log, and it is only possible to write to the System Event Log if the application does it under either the Local System or the Administrator accounts.

In addition to writing to the Application Event Log, you can just as easily write to a text file. As with writing to the Application Event Log, writing to a text file also means that you need to make changes to the app.config file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.diagnostics>
        <sources>
            <source name="DefaultSource" switchName="DefaultSwitch">
                <listeners>
                    <add name="EventLog"/>
                    <add name="FileLog" />
                </listeners>
            </source>
        </sources>
        <switches>
            <add name="DefaultSwitch" value="Information" />
        </switches>
        <sharedListeners>
            <add name="EventLog"
             type="System.Diagnostics.EventLogTraceListener"
             initializeData="EvjenEventWriter" />
            <add name="FileLog"
             type="Microsoft.VisualBasic.Logging.FileLogTraceListener,
             Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral,
             PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
             initializeData="FileLogWriter"/>
        </sharedListeners>
    </system.diagnostics>
</configuration>

Now with this app.config file in place, you simply need to run the same WriteEntry method as before. This time, however, in addition to writing to the Application Event Log, the information is also written to a new text file. You can find the text file at C:Documents and Settings[username]Application Data[AssemblyCompany][AssemblyProduct][Version]. For instance, in my example, the log file was found at C:Documents and SettingsAdministratorApplication DataWroxLog Writer1.2.0.0. In the .log file found, you will see a line such as the following:

DefaultSource     Information     1     Entered Form1_Load

By default, it is separated by tabs, but you can change the delimiter yourself by adding a delimiter attribute to the FileLog section in the app.config file:

<add name="FileLog"
 type="Microsoft.VisualBasic.Logging.FileLogTraceListener,
 Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral,
 PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
 initializeData="FileLogWriter" delimiter=";" />

In addition to writing to Event Logs and text files, you can also write to XML files, console applications, and more.

The My.Computer namespace can be used to work with the parameters and details of the computer in which the application is running. The following table details the objects contained in this namespace:

There is a lot to the My.Computer namespace, and it is impossible to cover all or even most of it. For an example that uses this namespace, we'll take a look at the FileSystem property. The FileSystem property enables you to easily and logically access drives, directories, and files on the computer.

To illustrate the use of this property, first create a Windows Form with a DataGridView with a single column and a Button control. It should appear as shown in Figure 7-12.

Figure 7.12. Figure 7-12

This little application will look in the user's My Music folder and list all of the .mp3 files found therein. Once listed, the user of the application will be able to select one of the listed files; and after pressing the Play button, the file will be launched and played inside Microsoft's Windows Media Player.

The first step after getting the controls on the form in place is to make a reference to the Windows Media Player DLL. You can find this on the COM tab, and the location of the DLL is C:WINDOWSSystem32wmp.dll. This provides you with an object called WMPLib in the References folder of your solution.

You might be wondering why you would make a reference to a COM object in order to play a .wma file from your application, instead of using the My.Computer.Audio namespace that is provided to you. The Audio property only allows for the playing of .wav files, because to play .wma, .mp3, and similar files, users must have the proper codecs on their machine. These codecs are not part of the Windows OS, but are part of Windows Media Player.

Now that the reference to the wmp.dll is in place, let's put some code in the Form1_Load event:

Private Sub Form1_Load(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles MyBase.Load

For Each MusicFile As String _

In My.Computer.FileSystem.GetFiles _
           (My.Computer.FileSystem.SpecialDirectories.MyMusic, _
           FileIO.SearchOption.SearchAllSubDirectories, "*.wma*")
             Dim MusicFileInfo As System.IO.FileInfo = _
                My.Computer.FileSystem.GetFileInfo(MusicFile.ToString())
             Me.DataGridView1.Rows.Add(MusicFileInfo.Directory.Parent.Name & _
                "" & MusicFileInfo.Directory.Name & "" & MusicFileInfo.Name)
        Next
End Sub

In this example, the My.Computer.FileSystem.GetFiles method points to the My Music folder through the use of the SpecialDirectories property. This property enables logical and easy access to folders such as Desktop, My Documents, My Pictures, Programs, and more. Though it is possible to use just this first parameter with the GetFiles method, this example makes further definitions. The second parameter defines the recurse value — which specifies whether the subfolders should be perused as well. In this case, the SearchOption enumeration is set to SearchAllSubDirectories. The last parameter defines the wildcard that should be used in searching for elements. In this case, the value of the wildcard is *.wma, which instructs the GetFile method to get only the files that are of type .wma. You could just as easily set it to *.mp3 or even just *.* to get anything contained within the folders. After it is retrieved with the GetFile method, the file is then placed inside the DataGridView control, again using the My.Computer.FileSystem namespace to define the value of the item placed within the row.

After the Form1_Load event is in place, the last event to construct is the Button1_Click event:

Private Sub Button1_Click(ByVal sender As System.Object, _
   ByVal e As System.EventArgs) Handles Button1.Click
      Dim MediaPlayer As New WMPLib.WindowsMediaPlayer
      MediaPlayer.openPlayer(My.Computer.FileSystem.SpecialDirectories.MyMusic & _
         "" & DataGridView1.SelectedCells.Item(0).Value)
End Sub

From this example, you can see that it is pretty simple to play one of the provided .wma files. It is as simple as creating an instance of the WMPLib.WindowsMediaPlayer object and using the openPlayer method, which takes as a parameter the location of the file to play. In this case, you are again using the SpecialDirectories property. The nice thing about using this property is that whereas it could be more difficult to find the user's My Music folder due to the username changing the actual location of the files that the application is looking for, using the My namespace enables it to figure out the exact location of the items. When built and run, the application provides a list of available music files, enabling you to easily select one for playing in the Media Player. This is illustrated in Figure 7-13.

Though it would be really cool if it were possible to play these types of files using the Audio property from the My.Computer namespace, it is still possible to use the My.Computer.Audio namespace for playing .wav files and system sounds.

To play a system sound, use the following construct:

My.Computer.Audio.PlaySystemSound(SystemSounds.Beep)

The system sounds in the SystemSounds enumeration include Asterisk, Beep, Exclamation, Hand, and Question.

Figure 7.13. Figure 7-13

The My.Forms namespace provides a quick and logical way to access the properties and methods of the forms contained within your solution. For instance, to get at the first form in your solution (assuming that it's named Form1), use the following namespace construct:

My.Form.Form1

To get at other forms, you simply change the namespace so that the name of the form you are trying to access follows the Form keyword in the namespace construction.

The My.Resources namespace is a very easy way to get at the resources stored in your application. If you open the MyResources.resx file from the My Projects folder in your solution, you can easily create as many resources as you wish. For example, you could create a single String resource titled MyResourceString and give it a value of St. Louis Rams.

To access the resources that you create, use the simple reference shown here:

My.Resources.MyResourceString.ToString()

Using IntelliSense, all of your created resources will appear after you type the period after the My.Resources string.

The My.User namespace enables you to work with the IPrincipal interface. You can use the My.User namespace to determine whether the user is authenticated or not, the user's name, and more. For instance, if you have a login form in your application, you could allow access to a particular form with code similar to the following:

If (Not My.User.IsInRole("Administrators")) Then
   ' Code here
End If

You can also just as easily get the user's name with the following:

My.User.Name

In addition, you can check whether the user is authenticated:

If My.User.IsAuthenticated Then
   ' Code here
End If

When not using the My.WebServices namespace, you access your Web services references in a lengthier manner. The first step in either case is to make a Web reference to some remote XML Web Service in your solution. These references will then appear in the Web References folder in the Solution Explorer in Visual Studio 2008. Before the introduction of the My namespace, you would have accessed the values that the Web reference exposed in the following manner:

Dim ws As New ReutersStocks.GetStockDetails
Label1.Text = ws.GetLatestPrice.ToString()

This works, but now with the My namespace, you can use the following construct:

Label1.Text = My.WebServices.GetStockDetails.GetLatestPrice.ToString()