CODEWITHSUNDEEP
c#reflectioncomoleview
Morepork
Morepork

Reputation: 11

C# Reflection inconsistency with COM objects

Having spent the last few days reading everything I can find about C# reflection on COM objects, trying many experiments in code, and analyzing sample code to try and improve my understanding, I am now forced to admit that I just don't know enough, so I am requesting help from the Community.

I need to be able to access and update the properties of a late bound COM object that is wrapped as System._COM Object.

I tried all the standard refection stuff without success and I looked through using IDispatch, but I'm not comfortable with using the pointers involved, so I'm hoping I have missed something pretty simple in the normal interface. I found papers on MSDN that DO show how to do what I need, but all the examples are in C++ and it is over my head.

It would be really helpful if someone could explain why the following simple C# code just doesn't work as expected:

            try
        {
            // late binding:
            // localCB is a COM object (System._COMObject) created by Activator.CreateInstance() from 
            // the ProgID of a registered COM .DLL. 
            // 
            // The original .DLL has a string PROPERTY called 
            // "TESTEXTERNAL1". localCB has an IDispatch Interface.  The original COM .DLL has a separate Typelib,
            // and, although I did not register the typelib separately, I can see from OLEView on the COM object
            // that  the GUID for the typelib is included in it.

            // Here's the code that is puzzling me...
             var vv = localCB.GetType().InvokeMember("TESTEXTERNAL1", BindingFlags.GetProperty, 
                  null, localCB, null);
            string rt = vv.ToString();
            // works exactly as expected and returns the value of TESTEXTERNAL1 -  OK.

            // now try and update the SAME PROPERTY, on the SAME COM object...
            Parameters = new Object[1];
            Parameters[0] = "Hello, World!";
            localCB.GetType().InvokeMember("TESTEXTERNAL1", BindingFlags.SetProperty, 
                  null, localCB, Parameters);
            // throws an (inner) exception: HRESULT 0x8002003 DISP_E_MEMBERNOTFOUND !!!

        }
        catch (Exception xa)
        {
            string xam = xa.Message;
        }

Is it unreasonable to expect an object that has already found and provided a property, to be able to update the same property? Is there some "alternative update" strategy that I am not aware of?

Many thanks for any help,

Pete.

UPDATE:

in response to Jon's request, here are snippets of the OleView: (I had to use images because Oleview would not let me cut & paste, sorry...)

OleView of the COM .DLL

OLEView typelib view

Jon, I think you have correctly identified that the problem is with a setter method. The DLL is written in Fujitsu COBOL and provides an "under the covers" GET and SET for fields identified as PROPERTY. Accessing the COM component from C# or COBOL, it works fine, but, as you can see, it doesn't work when I try and access it for SET with reflection. Because I am unfamiliar with using reflection I was doubtful whether I had the syntax right, so I tried to make the SET as close as possible to the GET. I think I will need to generate my own SET methods (for each PROPERTY) into the COBOL and then change my "BindingFlags.SetProperty" to be "BindingFlags.InvokeMember". (I did the homework on BindingFlags and found that if you specify "SetProperty" it automatically implies the other 2 flags you mentioned.)

I think the key to it all is in recognizing that the problem is with the Fujitsu *COM Class SET, and it took your experienced eye to see that. Many thanks. If you have any other comments after seeing the OLEView, or can suggest any alternative approach in order to get the properties set, I'd be very interested. (I'm not looking forward to having to generate SETter methods for every property; it smacks of brute force... :-))

Thanks again,

Pete.

Upvotes: 0

Views: 198

Answers (1)

Morepork
Morepork

Reputation: 11

Hans was correct. The problem was with the setter method. I have written code to generate a setter for each of the properties, back in the original COBOL COM component. It wasn't as tedious or ugly as I thought it would be (about 7 lines of COBOL for each PROPERTY) and it is all working very well now. Many thanks to the community and particularly Hans Passant for support.

Upvotes: 0

Related Questions