Using Late Bound COM Objects - Introductory Concepts
(Page 2 of 6 )
Late Binding Defined Binding associates a method with a pointer to the method's memory location. In early binding, the object's client is bound to the vtable locations of the object's methods at the time of compilation. Late binding, in contrast, identifies a method's location at runtime via human-readable names. To enable late binding, the target object must implement the IDispatch interface. The IDispatch::GetIDsOfNames and IDispach::Invoke methods allow object interrogation and method invocation at runtime. The OleView application (bundled with Visual Studio 6) can be used to determine whether the IDispatch interface is supported by your target component. Notice the IDispatch inherited interface for this component:
Assuming this object has a ProgID of "TestObject.TestClass" and is located on a server named "OurServer," the typical VB6 code for late binding would look like this:
Dim oMyObject As Object
Set oMyObject = CreateObject("TestObject.TestClass", "OurServer")
MsgBox oMyObject.Echo1("echo this back to me") In the example above, the variable is declared as a generic object. The CreateObject call uses the ProgID to locate the dll on the specified server. Note that the server parameter is not required if the target dll is located on the local box.
Why Use Late Binding As you probably know, Microsoft recommends early binding whenever possible. It provides the best performance because your application binds directly to the address of the required functions. As Microsoft's Knowledge Base article #Q245115 (
click here) states when talking about early binding, "in terms of overall execution speed, it is at least twice as fast as late binding". So why worry about how to late bind at all?
There are scenarios for which late binding is justified. You may not know the exact binary interface until runtime. The object may exist in multiple versions and have improperly adapted interfaces between the versions. You may be developing web applications on a shared host and be unable to get a RCW created for the COM object you want to invoke. Or, the object may have been compiled in VB with improper version compatibility settings, resulting in constantly changing GUIDs even when the version hasn't changed. In these scenarios, a defensive programmer needs to remove his or her code a bit from the object's binary signature. The tradeoff is one of flexibility versus performance and should be weighed carefully.
.NET to COM Interop Review The .NET runtime supports the creation of a managed wrapper for COM objects to handle translations between .NET and COM. This Runtime Callable Wrapper (RCW) acts as a bridge between .NET and COM. If you add a reference to a COM component in your Visual Studio .NET project, a RCW will automatically be generated for you (note that Visual Studio .NET asks you first if a wrapper should be generated, rather than just automatically creating it for you). Alternatively, you can use the tlbimp utility that installs with the .NET Framework Software Development Kit to create the wrapper manually. Manual generation of the RCW allows for better control of the process. Command-line switches allow specification of namespace, output file, strong name information, and references, among others. More details are found in the .NET Framework SDK documentation.
With the ability to create an RCW, early bound COM interoperability is quite straightforward. Having now laid some groundwork, let's look at how to accomplish COM late binding in .NET.
Next: Late Binding in .NET: The Basic Invocation >>
More C# Articles
More By Wrox Team
