-1

I have a legacy COM object that is written in C++. I register the COM library via an installer and in a C# wrapper application I instantiate the COM object like this 

Type type = Type.GetTypeFromProgID("GrpSvr.GrpCall");
this.grouperServer = Activator.CreateInstance(type);
string strMsg = this.grouperServer.GroupInit(this.strCommandFilePath, true, true);

and I then use the COM object for various operations and these calls look like 

int index = 2;
string strFieldName = "AXR";
this.grouperSever.MakeRec(strFieldName, index);

and these work fine (at first). Then, out-of-the-blue the calls just stop returning the correct result. I can confirm that I am passing in the correct values to a given method and at some point and at random, the grouperServer object starts returning crap.

I cannot debug the library in the usual sense and have not used COM libraries before. The fact that I can pass one of the COM methods the same value in a loop and this method stops returning the correct result, suggest that this maybe an invocation problem with the Dynamic Language Runtime (DLR). My question then becomes

How can I find out what is wrong with/debug the COM object?

Thanks for your time.

MoonKnight
  • 23,214
  • 40
  • 145
  • 277
  • Your question needs a whole lot of clairvoyance to answer to the point. So, debug it and see for yourrself. Besides all the other things it could be for standard code, your "legacy" suggests the com object might have bugs the newer software-environment revealed. – Deduplicator Mar 25 '14 at 18:45
  • Thank you for your very helpful response. Unfortunately you cannot debug a COM object in the usual way [you would with native code], hence why I am asking 'how can I find out what is wrong with the COM object'. Unfortunately you have mistaken the word 'clairvoyance' with 'experience'. – MoonKnight Mar 25 '14 at 18:50
  • Nope. You did not supply your COM-object or some way to identify it, so anyone answering must either list everything which could ever be done wrong and might seem to work for some time or be a certified psychic. – Deduplicator Mar 25 '14 at 18:53
  • Dude, if you can't help, do one. I have clearly stated that I, myself do not have access to the COM library code, I want to know how I can go about finding the problem. There could be a number of issues, yes, however, someone (clearly not yourself) my have extensive experience in this area (using legacy COM libraries) and have come across this exact issue. If you can't help me why waste your own time commenting. Ps. that was rhetorical. – MoonKnight Mar 25 '14 at 18:58

1 Answers1

1

You didn't say anything about the execution environment or threading model of your application.

My guess: your COM object is marked as an STA object in the Registry (ThreadingModel=Apartment), but in your C# app you're not using it on an STA thread with a functional Windows message loop.

If you do though, then make sure this STA thread is the only thread which accesses the COM object. No other thread can call it directly, without marshaling.

A must-read: "INFO: Descriptions and Workings of OLE Threading Models".

This question may also be related: "StaTaskScheduler and STA thread message pumping".

Community
  • 1
  • 1
noseratio
  • 59,932
  • 34
  • 208
  • 486
  • 1
    Thanks so much for your reply. This is exactly the sort of lead I wanted. I am executing this code using `dynamic` and on the main [UI] thread and sometimes on a background thread-pool thread via .NET4.0 TPL (using `Task.Factory.StartNew(() => ...)`). I will read the links now... Thanks again for your time. – MoonKnight Mar 26 '14 at 09:21
  • 1
    @Killercam, no problem. Depending on your UI framework, use either `Control.Invoke` or `Dispatcher.Invoke` to access your COM object from any thread other than the UI thread. I think your question was down-voted unfairly. – noseratio Mar 26 '14 at 09:25