IDC资讯中心
using late bound com objects
abstract
in this article, beth breidenbach describes how to late bind to com objects in .net. interoperability with com objects has been well–integrated into the .net runtime. but judging by the postings in the .net newsgroups there appears to be some lingering confusion about how to bind to com objects at runtime. this article will discuss the different methods available for invoking com objects at runtime. after a brief review of late binding (and why it should sometimes be avoided), we will walk through three different invocation scenarios and explore the appropriate c# syntax to use. we end with a brief look at the relative performance of each method.
article
this article will describe how to late bind to com objects in .net. interoperability with com objects has been well-integrated into the .net runtime. indeed, early binding is quite straightforward and has already been covered quite well in kaushal sanghavis articles on com(+) interoperability (see reference list at the end of this article). judging by the postings in the .net newsgroups, however, there appears to be some lingering confusion about how to bind to com objects at runtime. this article will discuss the different methods available for invoking com objects at runtime. after a brief review of late binding (and why it should sometimes be avoided) we will walk through three different invocation scenarios and explore the appropriate c# syntax to use. we will end with a brief look at the relative performance of each method.
prerequisites
our discussion assumes you understand the basic concepts of com interoperability in .net. if you are just getting up to speed on the topic, see the list of references at the end of this article. in particular, you should understand what a runtime callable wrapper is and how one is generated.
introductory concepts
late binding defined
binding associates a method with a pointer to the methods memory location. in early binding, the objects client is bound to the vtable locations of the objects methods at the time of compilation. late binding, in contrast, identifies a methods 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 microsofts knowledge base article #q245115 (http://support.microsoft.com/default.aspx?scid=kb;en-us;q245115) 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 hasnt changed. in these scenarios, a defensive programmer needs to remove his or her code a bit from the objects binary signature. the tradeoff is one of flexibility versus performance and should be weighed carefully.
