I've managed to find a solution. Thanks to Mike & Mark for their postings
though, they helped me to start looking in the right directions.
The source of the problem turned out to be that the object used to
implement the COM interface was being prematurely garbage collected. The
garbage collection was being triggered by the heap filling up after a fixed
number of calls to 'OnAdviseMessage', hence the mysterious number 17.
I've included a description of the code below in case anyone else comes
across this problem and finds this thread.
The code before looked like this:
public class CrossWrap
{
public CrossWrap()
{
///Create a connection to the COM Interface
string strClientId = "TestAdviseMessage";
KrcServiceFactoryClass itfKrcServiceFactory = new
KrcServiceFactoryClass();
ICKAdviseMessage itfAdviseMessage = itfKrcServiceFactory.GetService
("WBC_KrcLib.AdviseMessage", strClientId) as ICKAdviseMessage;
clsConsumeMessage itfConsumeMessage = new clsConsumeMessage(this,1);
itfAdviseMessage.Advise(itfConsumeMessage,(int)
(EKMessageType.eMessageTypeEvent|EKMessageType.eMessageTypeState|EKMessageTy
pe.eMessageTypeQuitt));
}
}
to fix the problem I had to shift the variable declarations up to the class
level so that a pointer was maintained on the COM connection objects as
long as the parent object of type CrossWrap was kept alive. In the above
code the pointers to itfKrcServiceFactory, itfAdviseMessage, and
itfConsumeMessage are finished with as soon as it reaches the end of the
CrossWap method, leaving them ripe for garbage collection.
Ned.
