A Few Musts and Shoulds

[Previous] [Next]

Finally, there are a few mandatory things to do to have your components run well inside MTS. There are other things you don't have to do but ought to do. Here they are, beginning with the musts:

• You must compile your Visual Basic/MTS components as DLLs.
• You must set the threading model to Apartment Threaded—not Single Threaded.
• In the Project Properties dialog box, you must set Unattended Execution before compiling. This prevents the component from displaying error messages. Instead, it will send such messages to the Event Log.
• Directly after compiling the component for the first time, you must select the Binary Compatibility option located on the Component tab of the Project Properties dialog box for the compiled project. As soon as you have done that, your components will keep the same class and interface GUIDs, which makes development easier for you and eventually makes using the component easier for your users.

We'll finish this chapter by listing the shoulds:

• If you're running Service Pack 4 or later for Windows NT 4.0, you should set the MTSTransactionMode property of the class in Visual Basic 6.0's IDE. If you do, the property value you have chosen will be carried over to the MTS Explorer when you install the component. Furthermore, when you debug the component in Visual Basic's IDE, Visual Basic makes the proper calls to MTS, even though the component isn't running in an MTS process but in Visual Basic's own.
• You should make sure that the code that executes in the Initialize and Terminate methods of the class doesn't depend on the context object being available. When the Initialize event happens, the context object isn't yet created; when the Terminate event happens, the context object is already dead. Move such code to the Activate and Deactivate methods of the IObjectControl interface instead.
• You should select Retained In Memory in the Project Properties dialog box. Hugh Teegan, COM+/IIS Group Program Manager, confirms this. Here's what he also says:

This option was introduced specifically for MTS (and works for COM+ too) to stop VB from physically releasing its "project space" when there are no active classes, which results in unnecessary physical memory deallocations (pessimistic teardown) and reallocations. The implications of not having this option on are relatively minor on single processor systems but catastrophic on multiprocessor systems.

Please notice Hugh's statement regarding the "catastrophic [implications] on multiprocessor systems" of not setting this option. But even if you don't set this property, you might get away scot-free. A Microsoft training kit for distributed applications written in Visual Basic claims that Service Pack 1 of MTS⁵ automatically enables this feature at run time, even if you don't select it at design time. We always select it, though. Better safe than sorry!

• You should probably have your compiler optimize for small code rather than fast code because smaller components takes less space in memory. When memory is filled up, Windows NT starts swapping components and data to and from disk. This happens earlier if you compile for fast code. Thus, small code might in practice run faster than fast code.
• In most cases, you should compile to favor Pentium Pro. Only if you plan to run your components on a server with an earlier processor should you not select this option.