A while back I've built a bunch of generic Reflection routines that simplify
the process of access properties/fields and methods a bit easier by creating
wrappers around Property/Field/Method info members.
For example:
public const BindingFlags MemberAccess =
BindingFlags.Public | BindingFlags.NonPublic |
BindingFlags.Static | BindingFlags.Instance | BindingFlags.IgnoreCase;
public static object GetProperty(object Object,string Property)
{
return Object.GetType().GetProperty(Property,wwUtils.MemberAccess |
BindingFlags.GetProperty).GetValue(Object,null);
}
There are versions for Get/Set and fields and properties as well as versions
that can nest references. All works fine with .Net types.
Today I tried to use this same code with a COM object and promptly it fell
flat. In the above example, GetProperty() fails to find the property.
However, the following works:
return Object.GetType().InvokeMember(Property,wwUtils.MemberAccess |
BindingFlags.GetProperty,null,Object,null);
So now I'm wondering what is InvokeMember doing that is different here? I
seem to remember a discussion here that InvokeMember is a bit less
efficient, so if possible I'd like to avoid this.
Any ideas if it's possible to get the code to run with GetProperty et al.?
+++ Rick ---

Signature
Rick Strahl
West Wind Technologies
http://www.west-wind.com/
http://www.west-wind.com/weblog/
----------------------------------
Making waves on the Web
Mattias Sj?gren - 16 Jul 2004 21:52 GMT
Rick,
>So now I'm wondering what is InvokeMember doing that is different here?
For COM objects it calls the property or method using IDispatch
(GetIDsOfNames followed by Invoke).
However, GetProperty and all the other reflection methods only
understand managed metadata, so you need an interop assembly
describing the COM API for them to work as expected.
Mattias

Signature
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.