The other two answers to this entry are correct, but they miss an important opportunity to explain how late binding of a COM object looks from the point of view of a system like .NET. When you call GetType
on a COM object, the return value is an internal type of __ComObject
, not the type of COM interface that you usually work with when writing interaction code. This can be seen in the debugger or with some code, for example Console.WriteLine(o.GetType().Name);
.
The __ComObject
type has no properties; why do you get an empty array when you call o.GetType().GetProperties()
. (At least some things in life make sense!)
If you decompile the InvokeMember
method, you will find that it has special handling for COM objects, delegating the call to an internal native method. For "normal" .NET objects, the method uses "regular" .NET reflection, retrieves the corresponding MemberInfo
for the requested element, and calls it.
You can use .NET reflection for an interface type. For example, if you know that the object is an Excel Worksheet
, you can use typeof(Worksheet).GetProperties()
and use the resulting PropertyInfo
instances with your object. However, if you do not know the type of the object at compile time, you need to call GetType()
, as in your code example. In this case, you are stuck with InvokeMember
.
phoog source share