VSTA generics questions

I changed my collection to base from a generic collection according to Tom's blog.  However, I am having some trouble getting it to work.

In my add-in, I simply do an assignment

MyNamespace.CollateralCollection col = this.Collaterals;

which in turn invokes the following code when executing --

public global::MyNamespace.CollateralCollection Collaterals {

get {

object[] _param = new object[0];

global::ASAP2.CollateralCollection retVal_param;

if ((this.@__vstaCacheCollaterals3 == null)) {

this.@__vstaCacheCollaterals3 = this.remoteType.GetProperty("Collaterals", (((global::System.Reflection.BindingFlags.Public | global::System.Reflection.BindingFlags.Instance)

| global::System.Reflection.BindingFlags.GetProperty)

| global::System.Reflection.BindingFlags.Default), null, typeof(global::ASAP2.CollateralCollection), new global::System.Type[0], null);

}   // <=== !!!! this call returns null  !!!!

retVal_param = ((global::ASAP2.CollateralCollection)(((global::System.Reflection.PropertyInfo)(this.@__vstaCacheCollaterals3)).GetValue(this, _param)));

return retVal_param;

}

}

I did add a proxyResolve handler typeInfrastructureManager_ProxyResolve to my proxy code. Although I've not observed it being called.

I also have a adapterResolve handler on my host side.

What is wrong here?  Could you provide any debugging tips?

Thanks.

 

 

Leighyu,

   The ProxyResolve and AdpaterResolve definitely need to get called.  Did you hookup the events in the AddTypesToMap method of the typeInfrastrucutureManager (on the host and proxy side) with a line like the following?

typeInfrastructureManager.ProxyResolve += new ProxyResolveHandler(typeInfrastructureManager_ProxyResolve);

As far as null being returned for the collection variable in the proxy, has the collection been created on the host side?  For instance, in the ShapeApp sample in the Application constructor, the drawings variable is set to a new DrawingCollection.  If you remove that instantiation then in the proxy the retVal_param will be null; however, the corresponding variable (in your @__vstaCacheCollaterals3) should not be.  Also, I noticed when the instantiation was removed neither the ProxyResolve nor AdapterResolve were hit.  This is probably because without this instantiation the this.collection is null, with the instantiation the this.collection has a valid collection which causes the collection to be passed between the host and the proxy, thus hitting the adapter and proxy resolves.

I believe the above should help; however, I do notice a namespace difference that may or may not be an issue with the @__vstaCacheCollaterals3 being null.  In the ShapeApp sample there is only one namespace used for the collections property in the proxy.  I notice you are using both MyNamespace.CollateralCollection and ASAP2.CollateralCollection.  If the above doesn't work, try putting everything in the same namespace and see if it works then. 

I hope this helps!  Thanks,

  -Melody

Thanks for the reply.  I have figured it out.  Everything else was working as you described.  The issue of returning null in "this.remoteType.GetProperty("MySimpleClassName", ...)", was caused by my unintentional change of the access level of the class from "public" to "internal".

While I was debugging the issue, it constantly deadlocks if I were slow moving through the program.  Error message --

"ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x1afff8 to COM context 0x1b0168 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations. "

I am wondering how to get this resolved?

Thanks.

Is this happening when you are debugging the host applicaiton or the add-in?  Are you using a message filter?

Yes, it happens when I debug.  No, I am not using a message filter.

I would suggest using the message filter from the ShapeApp Advanced sample.  It handles reject and pending calls that may be the source of the deadlock message.  Along with the message filter itself check out the main method in the Program.cs file which sets up the application to use the message filter. 

Here's Microsoft's explanation:  There are several threading issues in the IDE that can cause the STA to get hijacked while we're attempting to automate. By default, .Net does not provide a message filter, so blocked calls result in RPC_E_SERVER... exceptions. Since this is a timing issue, it would be very hard for the host to trap these exceptions and try again. The easiest solution, is to implement a message filter which tells the host to wait and try again when a call is rejected.

Thanks,

   -Melody

 

Too bad. Installing the message filter does not make the deadlock message ("The CLR has been unable to transition from COM context 0x1a0348 to COM context 0x1a04b8 for 60 seconds...") go away.  The message still pops up when I am taking my time to debug the application.

Some googling suggests I turn off the debug option of intercepting ContextSwitchBlock exception.  Is the message filter targeting this issue?  Or should I just turn off the debug option?

 

BTW, the three functions in IMessageFilter is not triggered before the DeadLock message box pops up.