Compiling the Assembly

Now that you have created a class library with two classes (Patient and Physician), it is time to compile your assembly. In VB6, you would compile a COM component, but you aren't in VB6 anymore. Instead, you are writing for the .NET Framework, and that means you will be compiling an assembly. The assembly might have a .DLL extension, but it is not a traditional DLL in the Windows API sense, nor is it a COM DLL in the VB6 sense.

Building the assembly is fairly easy. The build option is no longer on the File menu, but is now a separate menu labeled Build. If you click on the Build menu, you will see several choices. Because you have a solution in this example, with a class library (Healthcare) and Windows application (HealthcareClient), you will see options to build or rebuild the solution. You also have an option to deploy the solution. In the next section of the Build menu, you have the option to build or rebuild one of the projects in the solution, depending on which project is highlighted in the solution explorer when you click the menu. Finally, there is a choice for a batch build and one for the Configuration Manager.

In .NET, you can compile your assemblies in either Debug or Release mode, or you can create your own custom modes. Debug mode compiles in symbolic debug information and does not use any compiler optimizations. Release mode does not compile in any of the symbolic debug information, and it applies code optimizations. Obviously, you will use Debug mode while developing and debugging your application. After you have the bugs worked out and are ready to deploy the application, you switch to Release mode and recompile your assembly. Realize that you can modify these modes or add your own. For example, you could add debug information into projects compiled under Release mode, if you choose to modify Release mode in that fashion.

You can see that the Debug option is set if you look at the toolbar. The Solutions Configuration drop-down list box allows you to choose Debug or Release, and to open the Configurations Manager. You can see this in Figure 4.4.

For now, just click on the Healthcare project one time in the Solution Explorer window. This will select it as the project to build if you choose not to build the entire solution. Now, click on the Build menu and choose Build Healthcare. The Output window at the bottom of the IDE should report when the build is done, and show how many projects succeeded, how many failed, and how many were skipped. In this case, the HealthcareClient is not counted as skipped, so you should see that one project succeeded, with no failures and no projects skipped.

The compilation process creates two files. The default location for the project is My DocumentsVisual Studio ProjectsHealthcare. If you look in that folder, you'll see a bin folder below it. Inside the bin folder are two files: Healthcare.dll and Healthcare.pdb. The .DLL is the assembly, and the .PDB is the debug file that goes along with the .DLL because you compiled it with the Debug configuration. .PDB stands for program database. The .PDB extension is a bit unfortunate for many users because .PDB is also used as a common format for files used by the Palm operating system. This means that .PDB files get associated with the Palm's Desktop application.

Reusing the Assembly in Other Applications

One of the other big differences from this and VB6 is that VB .NET assemblies do not use the registry. In fact, VB .NET does not put any information about the assembly in the registry. If you search through the registry, you won't find any mention of the Healthcare assembly. You will find information about the project and solution, but that's just so that Visual Studio .NET can show them in the recent files list.

Given that there is nothing about the assembly in the registry, how do you reuse it in another application? If you start a new Windows Application project in VB .NET and right-click on the References node in the Solution Explorer window, the Add Reference dialog box is shown. However, the Healthcare component is not listed. This shouldn't be too surprising; it showed up earlier because HealthcareClient was part of the same solution. Now, however, you have started a new project, which creates a new solution. This solution is in a different directory, and therefore has no knowledge of the Healthcare component.

To have the new project use the Healthcare component, make sure that you are on the .NET Framework tab of the Add Reference dialog box and click the Browse button. Navigate to the My DocumentsVisual Studio ProjectsHealthcarein folder and choose Healthcare.dll. The References node in the Solution Explorer window now shows the Healthcare component.

Your application can now use the Healthcare component. You can create objects by typing the following code:

Dim Patient As New Healthcare.Patient()

You can always use the Imports command to import the Healthcare namespace, so you could instantiate objects with just this code:

Dim Patient As New Patient()

How .NET Locates Assemblies

Think back to COM: When a program makes a call to a component, the Service Control Manager goes to the registry, looks up the component information, locates the object, creates it, and returns to the calling application a pointer to the newly created object. .NET doesn't use the registry, so it has to use a different mechanism for locating assemblies that are referenced in an application (or in another assembly). The full details are not critical to understanding how to develop components, but a basic understanding of the process is important for troubleshooting.

Step 1: Getting the Reference Information

Your application attempts to call a referenced assembly. The reference contains the following information about the assembly:

• Name

• Version

• Culture

• Public Key (for strongly named assemblies)

The runtime uses this information to try to locate the assembly, using the following steps.

Step 2: Looking at the Configuration File

The configuration file is a powerful concept. You can create a configuration file to handle any reference information that might change. For example, if you think you will need to update the particular version of an assembly used by your application, you can store that information in a configuration file. You can also force an application to bind to only the versions of components that were available when the application was built. This is called Safe Mode. The configuration file is an XML file.

Step 3: Using CodeBases or Probing

If you want to prevent probing, you can specify a CodeBase value in the configuration file. When the runtime loads the file pointed to by the CodeBase, it checks the version information to make sure it matches what is in the application's reference. By default, if the assembly pointed to by the CodeBase is the same version or higher, the binding will occur.

If there is no CodeBase, the probing process is initiated. Probing is simply the runtime looking for the assembly by following a search criteria. First, the runtime looks in the GAC if the assembly is strongly named. If the assembly is private, the search is performed only in the application's root directory, referred to as the AppBase. The runtime sees a reference to an assembly in the application, such as Healthcare, and looks for the assembly by first searching for Healthcare.DLL.

If the assembly is not found in the AppBase directory, the probing continues, and the runtime searches based on the path set up in the configuration file. This path is specified with the <AppDomain> tag, as such:

<probing privatePath="MyAssemblies"/>

The runtime automatically appends some other information to the search path. For example, if the assembly you are searching for is Healthcare, the runtime looks in AppBaseHealthcare. It also looks in the bin directory, so it searches AppBasein. Because you specified MyAssemblies in the <AppDomain> tag, the runtime searches AppBaseMyAssemblies.

Finally, the search includes any localization information. Therefore, if you are creating multilingual, or localized, applications, it appends the locale. If the locale is de, the search path will include AppBaseBinde, AppBaseHealthcarede, and AppBaseMyAssembliesde.

Step 4: The GAC

Recall that the Global Assembly Cache is a cache for assemblies to be used by multiple applications on the same machine. Even if an assembly is found through probing or CodeBases, the runtime looks for updated versions in the GAC, provided you have not turned off this functionality. If a higher version exists in the GAC, it is used.

If no assembly was found using a CodeBase or probing, the runtime searches the GAC for a match. If a matching assembly is found, it is used.

To add assemblies to, remove assemblies from, or view assemblies in the GAC, use the gacutil.exe console application, provided by the Framework. The GAC is also a directory, so you can add assemblies to the GAC merely by copying them into the directory.

Step 5: The Administrator Steps In

It is possible for the administrator to create a file that specifies a particular version of an assembly to be used. If an application is searching for version 2.1.4.0 of Healthcare, the Administration policy file can point the application to another version, forcing an upgrade or downgrade.