Build a Robust DCOM Client-Server App with Visual Basic: A Practical Guide

Table of Contents

This article provides a comprehensive guide on developing, packaging, and deploying a Distributed Component Object Model (DCOM) client/server application utilizing Visual Basic. DCOM allows components to interact across network boundaries, enabling distributed computing architectures. To successfully build such an application, it is essential to have the Enterprise Edition of Visual Basic, which includes the necessary tools for creating and distributing remote components. This guide assumes a basic understanding of creating conventional client-server applications that operate within a single machine environment.

Understanding DCOM and Visual Basic¶

DCOM extends the Component Object Model (COM) to support objects across networks. It handles the details of network protocols and object location transparently to the developer, allowing a client application on one computer to instantiate and interact with a COM object residing on a different computer. The process involves registering the server component on both the server and client machines, although the client only needs specific registration details, not the server executable itself. Packaging and deployment are key steps that differ significantly from local COM applications, primarily concerning how the client locates and connects to the remote server.

Unlike traditional client-server models using sockets or other explicit network protocols, DCOM abstracts the communication layer. The client code appears almost identical whether the server is local or remote; the distinction is handled by the operating system’s DCOM services and the server’s registration information. Security configurations are paramount in a DCOM environment to control which users and machines can access and launch remote components. The Dcomcnfg utility is the primary tool used for managing these security settings post-installation.

Setting Up the Project Folders¶

To maintain organization during development and packaging, it is recommended to create separate directories for the server and client projects. For this demonstration, we will name the server project DCOMDemo_Svr and the client project DCOMDemo_Cli. Create a parent directory, for instance, c:\DCOMDemo, and within it, create two subdirectories: Server and Client. These folders will store the respective project files and their compiled outputs. This separation simplifies the packaging process later on, ensuring that server-specific files are not accidentally included in the client package and vice versa.

Maintaining distinct project directories also facilitates version control and collaboration if multiple developers are involved. It makes it clear which set of files belongs to the server component and which belongs to the client consumer. This practice is standard in component-based development, especially when dealing with distributed systems where deployment units are separate. Consistent file organization prevents confusion and potential errors during the complex steps of packaging and registration.

Creating the DCOM Server Component¶

The server component will be an ActiveX EXE project that exposes an object with a method the client can call remotely.
1. Begin by launching Visual Basic and selecting ActiveX EXE from the New Project dialog box. Click Open. Visual Basic automatically creates a default class module named Class1.
2. Add the following code within the Class1 module. This simple function will return the current time from the server’s perspective, demonstrating a remote method call.

```vbnet
Public Function ServerTime() As String
    ServerTime = Time
End Function
```
This function is a straightforward example to illustrate how a method exposed by the server object can be invoked by a client. It provides a concrete result (the server's time) that can be easily verified by the client.

3. Configure the server project’s properties. Go to the Project menu, select Project Properties, and then navigate to the General tab.
4. In the Project Name field, enter DCOMDemo_Svr. This name is crucial as it will be used in the server’s component registration.
5. In the Project Description field, provide a descriptive name like DCOMDemo_Svr - Server. Check the Unattended Execution option. Checking Unattended Execution is critical for servers that run without a user interface. It prevents the application from displaying message boxes or other interactive elements that would halt execution when running under an identity other than the interactive desktop user, which is common for DCOM servers.
6. Switch to the Component tab within the Project Properties. Check the Remote Server Files option. Selecting Remote Server Files instructs the Visual Basic compiler to generate the necessary .VBR (Visual Basic Remote) and .TLB (Type Library) files when the project is compiled. These files contain the registration information and type library details required for the client setup package, enabling the client to understand the server’s interfaces and register the necessary proxy/stub information.
7. Close the Project Properties dialog box to save the changes.
8. Save the server project files. On the File menu, select Save As, and save the project and its modules into the c:\DCOMDemo\Server folder. This ensures all server-side development files are stored together.
9. Compile the server executable. On the File menu, select Make DCOMDemo_Svr.exe. This action creates the server’s executable file and, because the Remote Server Files option was checked, also generates the .VBR and .TLB files in the project directory.
10. Set up Binary Compatibility for future development. Return to Project Properties, select the Component tab. Choose Version Compatibility and select the Binary Compatibility option. Browse and select the compiled server executable, DCOMDemo_Svr.exe. Setting binary compatibility is vital for maintaining compatibility between different versions of your server component. It ensures that the globally unique identifiers (GUIDs) for classes, interfaces, and type library remain consistent even if you modify and recompile the server code, preventing client applications from breaking when the server is updated.

Completing these steps establishes the server component, making it ready for local testing and subsequent packaging for distribution. The compiled executable contains the COM object, and the generated .TLB and .VBR files hold the information necessary for client-side registration and remote access.

Creating the DCOM Client Application¶

The client application will be a standard executable that instantiates and uses the remote server object.
1. Start a new project in Visual Basic. On the File menu, select New Project, choose Standard EXE, and click OK. A default form, Form1, is created.
2. Configure the client project’s properties. Go to the Project menu, select Project Properties, and then navigate to the General tab.
3. In the Project Name field, enter DCOMDemo_Cli.
4. In the Project Description field, provide a description, for example, DCOMDemo_Cli Project - Client.
5. Establish a reference to the server’s type library. On the Project menu, select References. In the list of available references, locate and select DCOMDemo_Svr - Server. This step makes the server’s classes and types known to the client project, allowing you to declare variables using the server’s class names (e.g., DCOMDemo_Svr.Class1). If the server project was compiled correctly with the Remote Server Files option, its type library should appear in this list.
6. Design the user interface. Place a Command Button on Form1. Change the button’s Caption property to Run. This button will trigger the code that instantiates the remote object and calls its method.
7. Add the client logic to the button’s click event. Double-click the Command Button to open the code editor and add the following code:

```vbnet
Dim MyObj As DCOMDemo_Svr.Class1

On Error GoTo err1

' Attempt to create the object. DCOM handles remote instantiation.
Set MyObj = CreateObject("DCOMDemo_Svr.Class1")

' Call the remote method and display results
MsgBox "Server Time=" & MyObj.ServerTime & " Client Time=" & Time

Exit Sub
err1:
' Display an error message if connection fails
MsgBox "Connection failed: Error " & Err.Number & " - " & Err.Description
```
This code attempts to create an instance of `DCOMDemo_Svr.Class1`. The `CreateObject` function, when used in a DCOM context, can leverage the registry information installed by the client setup to locate and instantiate the object on the remote server machine specified during installation or configuration. The `On Error GoTo` block provides basic error handling in case the remote connection or object creation fails.

8. Save the client project. On the File menu, select Save As, and save the project and its forms into the c:\DCOMDemo\Client folder.
9. Test the application locally in the IDE. Press the F5 key to run the client project. If the server project is also registered locally (which Visual Basic does automatically upon compilation), the client should successfully instantiate the server object and display the message box with both server and client times. This confirms the basic logic works before attempting remote deployment.
10. Compile the client executable. On the File menu, select Make DCOMDemo_Cli.exe to compile the client application. Close Visual Basic.

With both the server and client projects developed and compiled, the next phase involves packaging them for distribution and deployment on separate machines. The packaging process for the client is particularly critical for DCOM applications.

Packaging the DCOM Server Component¶

The server component needs to be packaged for installation on the machine where it will run. Use the Visual Basic Package and Deployment Wizard for this task.
1. Start the Package and Deployment Wizard. Select the server project file (DCOMDemo_Svr.vbp).
2. Click the Package button. Choose Standard Setup Package as the package type and click Next.
3. Specify the package folder where the setup files will be created. For example, create a folder c:\DCOMDemo\Server\Package and select it. Click Next.
4. The wizard may prompt about missing dependency information for your server; this is expected. Click OK.
5. Proceed through the remaining steps of the wizard, accepting defaults or customizing as needed for typical server installation. When prompted if the server will be used as a Remote Automation server and if you want to include support files for this purpose, click No. Remote Automation is an older technology superseded by DCOM.
6. Finish the wizard. The output will be a standard setup package (Setup.exe) for installing the server on a target machine.

The key difference in packaging a DCOM server compared to a local COM server is minor; the main considerations for DCOM are handled during the client packaging and post-installation configuration. The server package primarily ensures the executable is placed on the server machine and registered correctly in the Windows Registry.

Packaging the DCOM Client Application¶

Packaging the client for DCOM involves specific steps to ensure it can locate and interact with the remote server, rather than expecting the server executable to be present locally.
1. Start the Package and Deployment Wizard. Select the client project file (DCOMDemo_Cli.vbp).
2. Click the Package button. Select Standard Setup Package and click Next.
3. Specify the package folder for the client setup, e.g., c:\DCOMDemo\Client\Package. Click Next.
4. You will reach the Included Files dialog box. This is where the crucial modification for DCOM occurs. By default, the wizard includes the server executable (DCOMDemo_Svr.exe) because the client project has a reference to it. You must deselect DCOMDemo_Svr.exe as the server will not run on the client machine.
5. Click the Add button.
6. Change the Files of Type dropdown to Remote Server Files (*.vbr).
7. Navigate to the server project folder (c:\DCOMDemo\Server) and select the generated remote server file, DCOMDemo_Svr.VBR. Click Open. The Add File dialog box will close.
8. Observe the Included Files list again. It should now include DCOMDemo_Svr.VBR and DCOMDemo_Svr.TLB. These files contain the necessary registry information and type library definitions for the client to understand and interact with the remote server. Click Next.
9. You will see the Remote Servers dialog box. This dialog allows you to pre-define the network address (computer name or IP address) of the server. If you know the server’s location in advance, you can enter it here. However, it is common practice to leave this field blank, as the server location might not be known at packaging time or could change. If left blank, the client setup program will prompt the user for the server location during installation. For this example, leave the field blank.
10. Click Next to proceed. Continue through the rest of the wizard steps, defining typical setup options as needed.
11. Finish the wizard. The resulting package in the specified folder is now ready for distribution and installation on client machines. This package installs the client executable and registers the remote server information.

The client package is significantly different from a local COM package because it includes the .VBR and .TLB files instead of the server executable. These files are used by the setup program to write specific registry entries on the client machine that direct the CreateObject call (or New if using early binding) to the remote server defined during installation or configuration.

Installing the DCOM Applications¶

Deployment involves running the setup packages created in the previous steps on the respective machines.
1. Install the Server: Transfer the server package (Setup.exe from c:\DCOMDemo\Server\Package) to the computer designated to run the server component. Execute Setup.exe and follow the on-screen instructions. This process installs the DCOMDemo_Svr.exe file and registers it as a COM server on that machine. If you are using your development machine as the server, compiling the server project in Visual Basic already registers it, so a separate installation using the package is not strictly necessary unless you need to install it to a different location or ensure all package actions are performed.
2. Install the Client: Transfer the client package (Setup.exe from c:\DCOMDemo\Client\Package) to the computer where the client application will run. Execute Setup.exe. During the installation process, because you left the Remote Servers field blank in the Package and Deployment Wizard, the setup program will display a dialog box asking for the network address (computer name or IP address) of the server machine. Enter the name of the computer where you installed the DCOMDemo_Svr.exe. This information is written to the client’s registry, telling DCOM where to find the server component when the client application attempts to instantiate it. Complete the installation process.

Once both installations are complete, the client application is installed on its machine, and the server component is installed and registered on its machine. The client’s registry now contains information pointing to the remote server’s location. However, for DCOM to function correctly, security settings on the server machine must permit the remote client to access and launch the server component.

Configuring Server Security with Dcomcnfg¶

Security is a critical aspect of DCOM deployment, particularly on Windows NT and Windows 2000 systems (and subsequent Windows versions, although the interface and location of settings may vary slightly). You must configure permissions on the server machine to allow remote access and launch. The Dcomcnfg.exe utility is used for this purpose. These steps outline a permissive configuration for testing purposes; for production environments, tighter security settings are recommended. This example assumes the client user is logged into a domain that the server computer trusts.
1. On the server computer, open the Run dialog box (Start > Run). Type Dcomcnfg and press Enter or click OK. You must have Administrator privileges on the server machine to run Dcomcnfg and modify settings.
2. Navigate to the Default Properties tab. Ensure the Enable Distributed COM on this computer checkbox is selected. This globally enables DCOM functionality on the server machine.
3. Set the Default Authentication Level to Connect and the Default Impersonation Level to Identify. Authentication verifies the client’s identity, and impersonation determines the level of access the server process has when performing actions on behalf of the client. Identify means the server can check the client’s identity but cannot use that identity to access resources.
4. Switch to the Default Security tab. This tab allows setting default permissions for Access, Launch, and Configuration for all COM objects on the machine that don’t have specific custom settings.
5. In the Default Access Permissions panel, click Edit Default. Verify that the Everyone and System groups (or relevant user/group for production) are included in the list with Allow Access rights. If not, use the Add button to grant them access. Click OK. This determines who can connect to running instances of COM objects.
6. In the Default Launch Permissions panel, click Edit Default. Verify that Everyone and System (or relevant user/group) are included with Allow Launch permissions. Add them if necessary. Click OK. This determines who can start (launch) a COM server process if it’s not already running when a client requests an object.
7. Go to the Applications tab. Find and select your server application, DCOMDemo_Svr.Class1, from the list. Click the Properties button for the selected application.
8. In the application’s properties window, select the General tab. Set the Authentication Level dropdown to Default. This means the application will use the default authentication level set globally (Connect).
9. Select the Location tab. Verify that only the option Run application on this computer is checked. This confirms that this specific server should run locally on this machine when requested.
10. Select the Security tab for the application. Ensure that Use default access permissions and Use default launch permissions are checked. This means your server application will inherit the default permissions configured earlier, granting broad access for testing.
11. Select the Identity tab. Choose the The launching user option. This setting dictates which user account the server process runs under when it is started by a client request. The launching user means it runs under the identity of the user who triggered the launch (the remote client user, in this case). Click OK to close the server’s properties and then click OK again to close the Dcomcnfg utility.

These Dcomcnfg settings allow remote clients to launch and access the DCOMDemo_Svr.Class1 object. Using default permissions simplifies configuration for testing but is less secure than defining custom permissions for specific users or groups. In a production scenario, you would typically create specific Windows user accounts or groups and grant them granular access and launch permissions instead of using the broad Everyone group.

Testing the DCOM Application¶

After installing the server on the server machine and the client on the client machine, and configuring the security settings on the server using Dcomcnfg, you can test the DCOM application.
1. Go to the client computer.
2. Run the client application (DCOMDemo_Cli.exe).
3. Click the Run button on the client form.
4. The client application will attempt to instantiate the DCOMDemo_Svr.Class1 object on the remote server machine using DCOM. If successful, it will call the ServerTime() method on the remote object.
5. A message box should appear on the client computer displaying the time retrieved from the server (Server Time=...) alongside the client’s local time (Client Time=...).
6. If a connection error occurs, the error handling code will display a message box with the error number and description, which can help diagnose connection or configuration issues (e.g., DCOM not enabled, firewall blocking, incorrect server name during client install, or insufficient security permissions).

Successful execution of the client application and retrieval of the server’s time confirms that the DCOM connection is established, the server object is launched (if not already running), the method call is transmitted and executed remotely, and the result is returned to the client. This validates the entire build, package, deploy, and configure process for your first Visual Basic DCOM application.

Building and deploying DCOM applications involves careful attention to packaging, particularly for the client, and meticulous configuration of security settings on the server. Visual Basic’s tools, combined with Dcomcnfg, provide the necessary capabilities to achieve this. While DCOM has been around for many years, understanding its principles remains valuable for maintaining legacy systems or comprehending fundamental distributed computing concepts.

Have you built DCOM applications before, or are you facing specific challenges with DCOM deployment or configuration? Share your experiences or questions in the comments below!