After you have your application working on one machine, you should test it in a distributed environment before you turn it over to a system administrator for deployment. Your test environment should resemble the target environment as much as possible—in particular, it should reproduce any multiple-network protocols, COM transports, domains, or firewalls to restrict access to particular machines. In general, MTS applications should not require any special coding to work in these scenarios, but setting up your own test environment is a great way to test package settings and deployment instructions before you hand over your applications to the system administrator. Start with a simple deployment and build up to more complex deployments. For example, verify that your application works without a firewall in place before you test it with the firewall.
In addition to testing with a single client, you should test your application with multiple concurrent clients. You can do this with multiple client machines or by using a test harness that simulates multiple clients. The MTS Performance toolkit, which we will discuss in Chapter 13, includes a sample multiple-client test harness.
The techniques described for testing applications locally also apply to testing applications in a distributed environment. Most administrative tools available on Windows NT let administrators operate on remote machines as well as local machines. For example, you can view the event logs for multiple machines from a single workstation. A few additional techniques apply specifically to the distributed environment. If your application works locally but you are unable to create objects remotely, verify that you have network connectivity between the machines and that DCOM is enabled. Also, check the event log for security problems that might prevent object creation or access.
The exact mechanism you use to test network connectivity depends on the network protocols available between your machines. Usually, TCP/IP or UDP/IP is used for DCOM communication. In this case, you can use the Ping utility to determine whether you can reach a particular machine. Pinging successfully does not guarantee that you will be able to communicate via DCOM, but at least you know that the machine can be reached.
You can use the DCOM Configuration utility, DCOMCNFG.EXE, to determine whether DCOM is enabled on a particular machine. This test is particularly important on Microsoft Windows 95 and Windows 98 clients, where DCOM is not enabled by default. Launch DCOMCNFG, select the Default Properties tab, and verify that the Enable Distributed COM On This Computer check box is checked.
If you are having trouble with basic COM or MTS functionality in your application, consider using one of the sample applications to verify that your machines are in good working order. The DCOM Simple sample, included in the Platform SDK, is a good way to test basic DCOM functionality. You can use the MTS Sample Bank, which is installed with MTS, to verify that your MTS installation is working correctly.
Be sure to consider all the system services involved in your application if you have a particularly bizarre error. For example, if your machines are having trouble contacting the domain controller or if a trust relationship between two domains disappears, DCOM's authentication goes haywire.