I have the following code:
public void Test(IMyInterface iInterface)
{
iInterface.CallMethod ( );
}
Which works fine. However, if I change the code to be threaded:
private IMyInterface myInterface;
public void Test(IMyInterface iInterface)
{
myInterface = iInterface;
new Thread ( new ThreadStart ( CallInterfaceMethod) ).Start ( );
}
public void CallInterfaceMethod ( )
{
myInterface.CallMethod ( )
}
When i use the thread I receive the exception:
Unable to cast COM object of type 'System.__ComObject' to interface type 'IMyInterface'.
This operation failed because the QueryInterface call on the COM component for the interface with IID '{GUID}' failed due to the follow error: No such interface supported
But the interface should be supported just fine? Anyone have any thoughts on what is going on here?
This nasty, nasty exception arises because of a concept known as COM marshalling. The essence of the problem lies in the fact that in order to consume COM objects from any thread, the thread must have access to the type information that describes the COM object.
In your scenario described, the reason it fails on the second thread is because the second thread does not have type information for the interface.
You could try adding the following to your code:
[ComImport]
[Guid("23EB4AF8-BE9C-4b49-B3A4-24F4FF657B27")]
public interface IMyInterface
{
void CallMethod();
}
Basically the declaration above instructs the .NET framework COM loaded to load type information using traditional techniques from the registry and locate the associated type library and go from there.
You should also restrict the creation of the COM object to a single thread (to prevent thread marshalling) to help solve this issue.
To summarize, this error revolves around type information and thread marshalling. Make sure that each thread that wants to access the COM object has the relevant information to unmarshal the object from the source thread.
PS: This problem is solved in .NET 4.0 using a technique called "Type Equivalence"
I got an advice and it helped me!
Find in the main thread (Program.cs) the line [STAThread] and change it to [MTAThread].
I've been developing a C# application which uses 7-zip through COM interfaces. I ran into this funny thing where I was able to extract archives from a worker thread in one instance, but not another, getting this same exception.
I found that, so long as you initialize the offending COM object in the thread where it is used no exception is thrown. My solution was to dispose the objects which utilized COM interfaces and re-initialize them when passing them between threads.
Well, for one, you are making a cross-thread call to an object without locking it, this automatically will cause some issues. Your code should look more like:
private IMyInterface myInterface;
private static readonly object _myObjectLock = new object();
public void Test(IMyInterface iInterface)
{
myInterface = iInterface;
new Thread ( new ThreadStart ( CallInterfaceMethod) ).Start ( );
}
public void CallInterfaceMethod ( )
{
lock(_myObjectLock)
{
myInterface.CallMethod ( );
}
}
From what I understand, the error you listed can sometimes occur when the resource cannot be accessed, which, with a cross-thread operation like this, would most likely happen. Don't quote me on it though, I'm no COM expert.
Truthfully, I don't think I would approach calling this method in this fashion, way too many risks in doing so. Have you considered using a ParameterizedThreadStart and passing the object through that way? You'd still need to safely lock your objects for the cross-thread operations, but it would be safer.
Furthermore, check to make sure that your "myInterface" class can still call the "CallMethod()" method. Interfaces have no implementation, you may be running into problems when you set "myInterface = iInterface".