When a client calls an MTS component, it is likely that the component
will be running on another machine on the network. However, the client must maintain
certain information about the component locally. For example, the name of the
computer where MTS and the component are running is stored in the local Registry.
That way, when a call is made to the component, the COM services know to forward
the call to the appropriate server.
An example of information stored locally, which is more relevant
to the developer, is the Components type library. As explained in previous chapters,
the type library contains details about the properties, methods, and events exposed
by the component’s interface. All the benefits associated with the type
library in local components also apply to an MTS component. If a component is
registered as a remote MTS component, for example, the VB developer can still
take advantage of syntax checking, auto-list members, and other features in VB
related to early binding. Also, having the type library local makes information
about the methods, properties, and events of component running on an MTS machine
readily available. Tools designed for viewing type library information, such as
the Object Browser in Visual Basic, work in the same manner for MTS objects as
they do for local objects.
The developer who wants to make calls to the MTS object is faced
with the problem of bringing all the previously described components to the local
developer machine. Luckily, MTS provides a simple way to configure the client
computer whenever an MTS package is exported. You will recall from the preceding
chapter that exporting a package is a simple process performed from the MTS Explorer.
In addition to exporting a PAK file that can be imported into another MTS machine,
the Package Export Wizard also creates a package to automate the configuration
of clients. The client package is a single executable program that does the following:
It adds all appropriate and necessary settings related to the component’s
class information to the client’s Registry.
The type library for each component in the package is copied to a local directory.
If the MTS computer is a not the same as the client, all the necessary Registry
information to call the components remotely will be added.
The steps to create the client package are exactly the same as
those to export an MTS package.
STEP BY STEP
16.1 Creating a Client Package
From the MTS Explorer, double-click the computer that contains the package
for which you want to create a client package.
Click on the MTS package.
From the Action menu, choose Export. Again, you can right-click on the package
while it is selected and then select Export if you want to. Either way will bring
you to the Export Package dialog box shown in Figure 16.1.
FIGURE 16.1 The Export wizard used to export an MTS package will also build
a client installation package.
Type in or browse to the destination path where you want the package file
to be copied.
With the desired path in the text box, click the Export button. If there are
no errors, the wizard will display a message box indicating that the export was
After these steps are complete, the client package is ready to go. If you want
to verify the work that was done, all you have to do is locate the PAK file that
was exported from the Windows Explorer. The client package will be found in a
subdirectory called Clients, which will be adjacent to the PAK file.